引言
咱们在应用 mybatis 时，如果呈现 sql 问题，个别会把 mybatis 配置文件中的 logging.level 参数改成 debug，这样就能在日志中看到某个mapper 最终执行 sql、入参和影响数据行数。咱们拿到 sql 和入参，手动拼接成残缺的 sql，而后将该 sql 在数据库中执行一下，就根本能定位到问题起因。mybatis的日志性能应用起来还是十分不便的，大家有没有想过它是如何设计的呢？
从 logging 目录开始
咱们先看一下 mybatis 的logging目录，该目录的性能决定了 mybatis 应用什么日志工具打印日志。
logging目录构造如下：
它外面除了 jdbc 目录，还蕴含了 7 个子目录，每一个子目录代表一种日志打印工具，目前反对 6 种日志打印工具和 1 种非日志打印工具。咱们用一张图来总结一下
除了下面的 8 种日志工具之外，它还形象出一个 Log 接口，所有的日志打印工具必须实现该接口，前面能够面向接口编程。定义了 LogException 异样，该异样是日志性能的专属异样，如果你有看过 mybatis 其余源码的话，不难发现，其余性能也定义专属异样，比方：DataSourceException等，这是 mybatis 的惯用手法，次要是为了将异样细粒度的划分，以便更快定位问题。此外，它还定义了 LogFactory 日志工厂，以便于屏蔽日志工具实例的创立细节，让用户应用起来更简略。
如果是你该如何设计这个性能？
咱们依照下面目录构造的介绍其实曾经有一些思路：
- 定义一个
Log接口，以便于对立形象日志性能，这 8 种日志性能都实现Log接口，并且重写日志打印办法。 - 定义一个
LogFactory日志工厂，它会依据咱们我的项目中引入的某个日志打印工具 jar 包，创立一个具体的日志打印工具实例。
看起来，不错。然而，再认真想想，LogFactory中如何判断我的项目中引入了某个日志打印工具 jar 包才创立相应的实例呢？咱们第一个想到的可能是用 if...else 判断不就行了，再想想感觉用 if...else 不好，7 种条件判断太多了，并非优雅的编程。这时候，你会想一些防止太长 if...else 判断的办法，然而 mybatis 却用了一个新的方法。
mybatis 是如何设计这个性能的？
- 从
Log接口开始
它外面形象了日志打印的 5 种办法和 2 种判断办法。
- 再剖析
LogFactory的代码
它外面定义了一个动态的结构器 logConstructor，没有用if...else 判断，在 static 代码块中调用了 6 个 tryImplementation 办法，该办法会启动一个执行工作去调用了 useXXXLogging 办法，创立日志打印工具实例。
当然 tryImplementation 办法在执行前会判断结构器 logConstructor 为空才容许执行工作中的 run 办法。下一步看看 useXXXLogging 办法：
看到这里，聪慧的你可能会有这样的疑难，从上图能够看出 mybatis 定义了 8 种 useXXXLogging 办法，然而在后面的 static 动态代码块中却只调用了 6 种，这是为什么？
比照后发现：useCustomLogging 和 useStdOutLogging 后面是没调用的。useStdOutLogging它外面应用了 StdOutImpl 类
该类其实就是通过 JDK 自带的 System 类的办法打印日志的，无需引入额定的 jar 包，所以不参加 static 代码块中的判断。
而 useCustomLogging 办法须要传入一个实现了 Log 接口的类，如果 mybatis 默认提供的 6 种日志打印工具不满足要求，以便于用户本人扩大。
而这个办法是在 Configuration 类中调用的，如果用户有自定义 logImpl 参数的话。
具体是在 XMLConfigBuilder 类的 settingsElement 办法中调用
再回到后面 LogFactory 的setImplementation办法
它会先找到实现了 Log 接口的类的结构器，返回将该结构器赋值给全局的logConstructor。
这样一来，就能够通过 getLog 办法获取到 Log 实例。
而后在业务代码中通过上面这种形式获取 Log 对象，调用它的办法打印日志了。
梳理一下 LogFactory 的流程：
- 在 static 代码块中依据一一引入日志打印工具 jar 包中的日志类，先判断如果全局变量 logConstructor 为空，则加载并获取相应的结构器，如果能够获取到则赋值给全局变量 logConstructor。
- 如果全局变量 logConstructor 不为空，则不持续获取结构器。
- 依据 getLog 办法获取 Log 实例
- 通过 Log 实例的具体日志办法打印日志
在这里还分享一个知识点，如果某个工具类外面都是静态方法，那么要把该工具类的构造方法定义成 private 的，避免被疑难调用，LogFactory就是这么做的。
- 适配器模式
日志模块除了应用 工厂模式 之外，还是有了 适配器模式。
适配器模式会将所须要适配的类转换成调用者可能应用的指标接口
波及以下几个角色：
- 指标接口（Target）
- 须要适配的类（Adaptee）
- 适配器（Adapter)
mybatis 是怎么用适配器模式的?
上图中标红的类对应的是 Adapter 角色，Log是 Target 角色。
而 LogFactory 就是 Adaptee，它外面的getLog 办法外面蕴含是须要适配的对象。
sql 执行日志打印原理
从下面曾经可能确定应用哪种日志打印工具，但在 sql 执行的过程中是如何打印日志的呢？这就须要进一步剖析 logging 目录下的 jdbc 目录了。
看看这几个类的关系图：
ConnectionLogger、PreparedStatementLogger、ResultSetLogger和 StatementLogger 都继承了 BaseJdbcLogger 类，并且实现了 InvocationHandler 接口。从类名十分直观的看出，这 4 品种对应的数据库 jdbc 性能。
类名
对应性能
ConnectionLogger
Connection
PreparedStatementLogger
PreparedStatement
ResultSetLogger
ResultSet
StatementLogger
Statement
它们实现了 InvocationHandler 接口意味着它用到了动静代理，真正起作用的是 invoke 办法，咱们以 ConnectionLogger 为例：
如果调用了 prepareStatement 办法，则会打印 debug 日志。
上图中传入的 original 参数外面蕴含了 nt 等分隔符，须要将分隔符替换成空格，拼接成一行sql。
最终会在日志中打印 sql、入参和影响行数：
上图中的 sql 语句是在 ConnectionLogger 类中打印的
那么入参和影响行数呢？
入参在 PreparedStatementLogger 类中打印的
影响行数在 ResultSetLogger 类中打印的
大家须要留神的一个中央是：sql、入参和影响行数只打印了 debug 级别的日志，其余级别并没打印。所以须要在 mybatis 配置文件中的 logging.level 参数配置成debug，能力打印日志。
彩蛋
不晓得大家有没有发现这样一个问题：
在 LogFactory 的代码中定义了很多匿名的工作执行器
然而在理论调用时，却没有在线程中执行，而是间接调用的，这是为什么？
答案是为了保障程序执行，如果所有的日志工具 jar 包都有，加载优先级是：slf4j》commonsLog》log4j2》log4j》jdkLog》NoLog
还有个问题，程序执行就能够了，为什么要把匿名外部类定义成 Runnable 的呢？
这里十分有迷惑性，因为它没创立 Thread 类，并不会多线程执行。我集体认为，这里是 mybatis 的开发者的一种偷懒，不然须要定义一个新类代替这种执行工作的含意，还不如就用已有的。
原文：https://mp.weixin.qq.com/s/HV…
举荐浏览
全网找不出第二份能把 Mybatis 解说这么具体且图文并茂的 PDF，凋谢分享
50W 年薪程序员须要的技术栈剖析
对于【暴力递归算法】你所不晓得的思路
看完三件事❤️
如果你感觉这篇内容对你还蛮有帮忙，我想邀请你帮我三个小忙：
点赞，转发，有你们的『点赞和评论』，才是我发明的能源。
关注公众号『Java 斗帝』，不定期分享原创常识。
同时能够期待后续文章 ing????