Mybatis日志功能是如何设计的？

引言

咱们在使用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日志工厂，以便于屏蔽日志工具实例的建立细节，让用户使用起来更简单。

若是是你该如何设计这个功能？

咱们按照上面目录结构的介绍其实已经有一些思路：

1. 定义一个Log接口，以便于统一抽象日志功能，这8种日志功能都实现Log接口，而且重写日志打印方法。
2. 定义一个LogFactory日志工厂，它会根据咱们项目中引入的某个日志打印工具jar包，建立一个具体的日志打印工具实例。

看起来，不错。可是，再仔细想一想，LogFactory中如何判断项目中引入了某个日志打印工具jar包才建立相应的实例呢？咱们第一个想到的多是用if...else判断不就好了，再想一想感受用if...else很差，7种条件判断太多了，并不是优雅的编程。这时候，你会想一些避免太长if...else判断的方法，可是mybatis却用了一个新的办法。

mybatis是如何设计这个功能的？

1. 从Log接口开始

​

它里面抽象了日志打印的5种方法和2种判断方法。

1. 再分析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就是这么作的。

​

1. 适配器模式

日志模块除了使用工厂模式以外，仍是有了适配器模式。

适配器模式会将所须要适配的类转换成调用者可以使用的目标接口

涉及如下几个角色：

• 目标接口（ 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🚀