前言
日志，在我们开发中是一个非常重要的话题，良好的日志打印可以帮助我们快速的定位问题，可能现在我们开发用到最多的日志框架就是slf4j了，但是日志还有其他很多优秀的框架，比如：apache common log，log4j，java.util.logging等。mybatis作为一款优秀的orm框架，定义了一套统一的日志接口供应用层调用，而底层却利用适配器模式兼容了我们上面所列出来的常用日志框架。
mybatis日志分类
在介绍mybatis的全局配置文件的时候，我们提到setting内有一个属性logimpl，可以配置的选项有：slf4j，log4j，log4j2，jdk_logging，commons_logging，stdout_logging，no_logging。
这就说明mybatis支持六种日志类型(no_logging是不打印日志)。我们看一下mybatis的日志模块也可以很明显的看出六种日志类型：
它们的对应关系为：
| 日志属性 | 对应日志模块包名 | 实现方式 |
|---|---|---|
| slf4j | slf4j | 使用slf4j日志框架实现 |
| log4j | log4j | 使用log4j日志框架实现(1.x版本) |
| log4j2 | log4j2 | 使用log4j日志框架实现(2.x版本) |
| jdk_logging | jdk14 | 使用java.util.logging实现 |
| commons_logging | commons | 使用apache commons logging实现 |
| stdout_logging | stdout | 使用system类实现 |
| no_logging | nologging | 不打印日志 |
ps:需要注意的是，slf4j并不是一个具体的日志框架，也就是我们不能单独只配置slf4j而不引入其他任何具体的日志框架。
简单谈谈slf4j
slf4j：简单日记门面。(英文全称为simple logging facade for java)，这个是用来为各种日志框架提供一个简单的统一的接口，这样使得我们在切换日志框架的时候可以直接替换jar包就可以了，而无需修改源代码。
logback我想大家都用过，logback是一个实现了具体日志打印的框架，但是mybatis上面列出来的分类并没有支持logback，它又为什么能够打印呢？这就是slf4j的作用了，因为logback也实现了slf4j提供的接口，所以我们需要将logback和slf4j结合配置使用才行。而后面的介绍中也可以看到，mybatis中如果我们不指定日志种类的时候，优先选择的就是slf4j，这正是因为slf4j可以和其他许多日志框架一起结合来使用。
那么假如我们指定了日志类型为slf4j，但是不引入其他任何实现呢？
答案就是mybatis不会打印任何日志出来，下图就是只配置了slf4j而没有引入其他任何实现的警告信息：
可以看到这里提示我们slf4j没有任何实现，而后面的sql语句和参数这些信息也没有打印出来。
mybatis日志实现原理
日志的解析
老规矩，我们还是先找到加载mybatis-config配置文件中的解析日志的源码：
这里首先会根据我们配置的属性作为别名去typealiasregistry类中查找对应的类，如果不存在这个别名，那就会把我们配置的属性直接通过class.forname去查找日志类，所以看到这里就明白我们可以自定义日志类，只要实现log接口就行，然后配置我们自己的类名就行了。虽然别名都存在typealiasregistry类里面，但是我们前面介绍mybatis配置文件的时候，列出了typealiasregistry类中默认初始化的别名，并没有看到日志相关类的别名，那么日志的别名又是在哪里配置的呢？我们打开configuration类：
可以看到configuration的构造方法里面也初始化了一些别名注册到typealiasregistry类了。
接下来我们看看读取到日志类之后调用了setlogimpl做了什么事情：
调用了logfactory类的方法。
logfactory
logfactory工厂是负责创建日志对象对应的适配器。
logfactory的静态代码块内按顺序初始化了所有内置的日志
再看一下tryimplementation方法，如果logconstructor不为空，说明当前还没有加载到日志适配器，那就继续执行run()方法，也就是继续执行usexxxlogging方法，而所有的usexxxlogging方法都是调用了setimplementation方法。
下面这里如果加载成功之后就会对logconstructor进行赋值，那么后续的方法就不会再执行run()方法， 而如果抛出异常，因为已经被捕获了，所以就会继续往后执行静态代码块内的方法。
从上面的logfactory中我们可以看到，初始化的时候就会默认初始化一个日志适配器，所以如果我们引用了相关日志所需要的类，那么就会按照static代码块内的顺序进行选择一个合适的日志适配器。
继续回到上面的configuration里面，这里拿到我们配置的日志信息之后，会直接调用usecustomlogging方法，也就是绕过了上面的logconstructor == null这个判断，而直接调用了setimplementation方法，所以假如我们配置了日志信息，那么会覆盖初始化的日志适配器。
ps：假如我们配置了一个不存在的日志类，那么因为它是直接调用setimplementation方法，所以异常就会被抛出来，不抛异常的方法是tryimplementation而不是setimplementation。
jdbc log
mybatis的日志包下面还有一个包时jdbc，这个我们还没有介绍，那么jdbc包下面的类又有什么用呢？我们先看一下类图关系：
很明显，mybatis将日志拆分成了connectionlogger，preparedstatementlogger，resultsetlogger，statementlogger四种类型分开处理，它们都继承了basejdbclogger类，而且实现了invocationhandler接口，也很明显，这里用到了jdk动态代理。
任意点开connectionlogger可以发现，它是用来代理connection对象的：
其他三个那很明显，分别是用来代理preparedstatement，resultset，statement这三个对象的。也就是说mybatis中日志最终的打印是通过jdk动态代理来实现的，而且不同的执行过程分成了四个对象来分别负责对应的日志打印。
我们继续看一下connectionlogger的invoke方法，可以看到，这里就是打印了一句日志：
上面日志打印出来的效果就是我们下面红框中的日志：
等等，差点被忽悠了，这代码里面并没有打印“==>”，打印出来的这个符号又是怎么来的呢？
那就需要进入debug方法里面继续看一看，这个debug方法是在抽象类basejdbclogger里面实现的，所以我们还需要看看basejdbclogger类的debug方法。
可以看到这里打印的时候拼接了一个前缀：
ps：querystack是查询层数，如果没有嵌套查询则querystack=1
总结
本文主要分析了mybatis日志的加载原理，并对logfactory作为适配器对象工厂是如何选择日志适配器对象进行了分析。最后分析了mybatis是如何通过动态代理将不同日志类型分为不同对象来实现日志打印功能的。
到此这篇关于详解mybatis日志如何做到兼容所有常用的日志框架的文章就介绍到这了,更多相关mybatis兼容所有日志框架内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
