引言
咱们在应用mybatis时，如果呈现sql问题，个别会把mybatis配置文件中的logging.level参数改成debug，这样就能在日志中看到某个mapper最终执行sql、入参和影响数据行数。咱们拿到sql和入参，手动拼接成残缺的sql，而后将该sql在数据库中执行一下，就根本能定位到问题起因。
mybatis的日志性能应用起来还是十分不便的，大家有没有想过它是如何设计的呢？
从logging目录开始
咱们先看一下mybatis的logging目录，该目录的性能决定了mybatis应用什么日志工具打印日志。
logging目录构造如下：
它外面除了jdbc目录，还蕴含了7个子目录，每一个子目录代表一种日志打印工具，目前反对6种日志打印工具和1种非日志打印工具。咱们用一张图来总结一下
除了下面的7种日志工具之外，它还形象出一个Log接口，所有的日志打印工具必须实现该接口，前面能够面向接口编程。
定义了LogException异样，该异样是日志性能的专属异样，如果你有看过mybatis其余源码的话，不难发现，其余性能也定义专属异样，比方：DataSourceException等，这是mybatis的惯用手法，次要是为了将异样细粒度的划分，以便更快定位问题。
此外，它还定义了LogFactory日志工厂，以便于屏蔽日志工具实例的创立细节，让用户应用起来更简略。
如果是你该如何设计这个性能？
咱们依照下面目录构造的介绍其实曾经有一些思路：
- 定义一个Log接口，以便于对立形象日志性能，这7种日志性能都实现Log接口，并且重写日志打印办法。
- 定义一个LogFactory日志工厂，它会依据咱们我的项目中引入的某个日志打印工具jar包，创立一个具体的日志打印工具实例。
看起来，不错。然而，再认真想想，LogFactory中如何判断我的项目中引入了某个日志打印工具jar包才创立相应的实例呢？咱们第一个想到的可能是用if...else判断不就行了，再想想感觉用if...else不好，7种条件判断太多了，并非优雅的编程。这时候，你会想一些防止太长if...else判断的办法，当然如果你看过我之前写的文章《实战|如何打消又臭又长的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性能。
它们实现了InvocationHandler接口意味着它用到了动静代理，真正起作用的是invoke办法，咱们以ConnectionLogger为例：
如果调用了prepareStatement办法，则会打印debug日志。
上图中传入的original参数外面蕴含了\n\t等分隔符，须要将分隔符替换成空格，拼接成一行sql。
最终会在日志中打印sql、入参和影响行数：
上图中的sql语句是在ConnectionLogger类中打印的
那么入参和影响行数呢？
入参在PreparedStatementLogger类中打印的
影响行数在ResultSetLogger类中打印的
大家须要留神的一个中央是：sql、入参和影响行数只打印了debug级别的日志，其余级别并没打印。所以须要在mybatis配置文件中的logging.level参数配置成debug，能力打印日志。
彩蛋
不晓得大家有没有发现这样一个问题：
在LogFactory的代码中定义了很多匿名的工作执行器
然而在理论调用时，却没有在线程中执行，而是间接调用的，这是为什么？
答案是为了保障程序执行，如果所有的日志工具jar包都有，加载优先级是：slf4j 》commonsLog 》log4j2 》log4j 》jdkLog 》NoLog
还有个问题，程序执行就能够了，为什么要把匿名外部类定义成Runnable的呢？
这里十分有迷惑性，因为它没创立Thread类，并不会多线程执行。我集体认为，这里是mybatis的开发者的一种偷懒，不然须要定义一个新类代替这种执行工作的含意，还不如就用已有的。
最初说一句（求关注，别白嫖我）
求关注，如果这篇文章对您有所帮忙，或者有所启发的话，帮忙扫描下发二维码关注一下，保持原创不易，您的反对是我保持下来最大的能源。
求一键三连：点赞、转发、在看。在公众号中回复：面试、代码神器、开发手册、工夫治理有超赞的粉丝福利，另外回复：加群，能够跟很多BAT大厂的前辈交换和学习。
本文由博客群发一文多发等经营工具平台 OpenWrite 公布