Mybatis技术内幕：基础支持层——日志模块

MyBatis基础支持层位于 Mybatis 整体架构的最底层，支撑着 Mybatis 的核心处理层，是整个框架的基石。基础支持层中封装了多个较为通用的、独立的模块，不仅仅为 Mybatis 提供基础支撑，也可以在合适的场景中直接复用。

整体架构

这篇文章介绍MyBatis的日志模块

在 Java 开发中常用的日志框架有 Log4j、Log4j2、Apache Commons Log、java.util.logging、 slf4j等，这些工具对外的接口不尽相同。

为了统一这些工具的接口，MyBatis定义了一套统一的日志接口供上层使用，并为上述常用的日志框架提供了相应的适配器。

适配器模式

先简单介绍一下设计模式中的六大原则

单一职责原则

不要存在多于一个导致类变更的原因，简单来说，一个类只负责唯一项职责。
里氏替换原则

如果对每一个类型为 T1的对象tl，都有类型为 T2的对象使得以 T1定义的所有程序P在所有的对象tl都代换成t2时，程序P 的行为没有发生变化，那么类型T2是类型T1的子类型。遵守里氏替换原则，可以帮助我们设计出更为合理的继承体系。
依赖倒置原则

系统的高层模块不应该依赖低层模块的具体实现，二者都应该依赖其抽象类或接口，抽象接口不应该依赖具体实现类，而具体实现类应该于依赖抽象。简单来说，我们要面向接口编程。当需求发生变化时对外接口不变，只要提供新的实现类即可。
接口隔离原则

一个类对另一个类的依赖应该建立在最小的接口上。简单来说，我们在设计接口时，不要设计出庞大臃肿的接口，因为实现这种接口时需要实现很多不必要的方法。我们要尽量设计出功能单一的接口，这样也能保证实现类的职责单一。
迪米特法则

一个对象应该对其他对象保持最少的了解。简单来说，就是要求我们减低类间耦合。
开放-封闭原则

程序要对扩展开放，对修改关闭。简单来说，当需求发生变化时，我们可以通过添加新的模块满足新需求，而不是通过修改原来的实现代码来满足新需求。

在这六条原则中，开放-封闭原则是最基础的原则，也是其他原则以及后文介绍的所有设计模式的最终目标。

适配器模式的主要目的是解决由于接口不能兼容而导致类无法使用的问题，适配器模式会将需要适配的类转换成调用者能够使用的目标接口。这里先介绍适配器模式中涉及的几个角色，如下所述。

目标接口

用者能够直接使用的接口。
需要适配的类（Adaptee）

—般情况下，Adaptee类中有真正的业务逻辑，但是其接口不能被调用者直接使用。
适配器（Adapter）

Adapter 实现了 Target 接口，并包装了一个 Adaptee 对象。Adapter 在实现 Target接口中的方法时，会将调用委托给 Adaptee对象的相关方法，由Adaptee 完成具体的业务。

适配器模式类图：

使用适配器模式的好处就是复用现有组件。

应用程序需要复用现有的类，但接口不能被该应用程序兼容，则无法直接使用。

这种场景下就适合使用适配器模式实现接口的适配，从而完成组件的复用。

很明显，适配器模式通过提供Adapter的方式完成接口适配，实现了程序复用 Adaptee的需求，避免了修改Adaptee实现接口，这符合“开放-封闭 ”原则。

当有新的Adaptee 需要被复用时，只要添加新的Adapter即可，这也是符合“开放-封闭 ”原则的。

在 MyBatis的日志模块中，就使用了适配器模式。

MyBatis内部调用其日志模块时，使用了其内部接口(也就是后面要介绍的org.apache.ibatis.loggingLog 接口)。但是 Log4j、Log4j2 等第三方日志组件对外提供的接口各不相同，MyBatis为了集成和复用这些第三方日志组件，

在其日志模块中提供了多种 Adapter, 将这些第三方日志组件对外的接口适配成了 org.apache.ibatis.logging.Log 接口，这样 MyBatis 内部就可以统一通过 org.apache.ibatis.logging.Log接口调用第三方日志组件的功能了。

日志适配器

MyBatis 统一提供了 trace、debug、 warn、error四个级别用于对应上诉的各种第三方日志组件的级别，这基本与主流日志框架的曰志级别类似，可以满足绝大多数场景的日志需求。

MyBatis的日志模块位于org.apache.ibatis.logging包中，该模块中通过 Log接口定义了日志模块的功能，当然日志适配器也会实现此接口。LogFactory工厂类负责创建对应的日志组件适配器。

在LogFactory类加载时会执行其静态代码块，其逻辑是按序加载并实例化对应日志组件的适配器，然后使用LogFactory. logConstructor这个静态字段，记录当前使用的第三方日志组件的适配器，具体代码如下所示。

private static Constructor<? extends Log> logConstructor;

static {
  tryImplementation(new Runnable() {
    @Override
    public void run() {
      useSlf4jLogging();
    }
  });
  tryImplementation(new Runnable() {
    @Override
    public void run() {
      useCommonsLogging();
    }
  });
  tryImplementation(new Runnable() {
    @Override
    public void run() {
      useLog4J2Logging();
    }
  });
  tryImplementation(new Runnable() {
    @Override
    public void run() {
      useLog4JLogging();
    }
  });
  tryImplementation(new Runnable() {
    @Override
    public void run() {
      useJdkLogging();
    }
  });
  tryImplementation(new Runnable() {
    @Override
    public void run() {
      useNoLogging();
    }
  });
}

LogFactory.tryImplementation()方法首先会检测 logConstructor字段，若为空则调用 Runnable.run()方法(注意，不是***start()***方法)，如上述代码所示，其中会调用use*Logging()方法。这里以useJdkLogging()为例进行介绍，具体代码如下:

public static synchronized void useJdkLogging() {
  setImplementation(org.apache.ibatis.logging.jdk14.Jdk14LoggingImpl.class);
}

private static void setImplementation(Class<? extends Log> implClass) {
  try {
    // 获取指定适配器的构造方法
    Constructor<? extends Log> candidate = implClass.getConstructor(String.class);
    Log log = candidate.newInstance(LogFactory.class.getName());
    if (log.isDebugEnabled()) {
      log.debug("Logging initialized using '" + implClass + "' adapter.");
    }
    // 初始化logConstructor字段
    logConstructor = candidate;
  } catch (Throwable t) {
    throw new LogException("Error setting Log implementation.  Cause: " + t, t);
  }
}

相应的实现类都在org.apache.ibatis.logging的子包下。且都实现了 org.apache.ibatis.logging.Log 接口，并封装了 java.util.logging. Logger 对象，org.apache.ibatis.logging.Log 接口的功能全部通过调用 java.util.logging.Logger 对象实现，这与前面介绍的适配器模式完全一致。