一 . 前言
这一篇讨论一点简单得东西 , 主要来了解一下什么叫日志门户 , 他又是怎么集成的 .
二 . 日志门户
阿里出版的 Java开发手册里面有这样一个强制规约 :
应用中不可直接使用日志系统（Log4j、Logback）中的API，而应依赖使用日志框架 （SLF4J、JCL--Jakarta Commons Logging）中的API，使用门面模式的日志框架，有利于维护和各个类的日志处理方式统一。
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
private static final Logger logger = LoggerFactory.getLogger(Test.class);
那么为什么要这么用 ?
什么叫日志门户 ?
Simple Logging Facade for Java（SLF4J）作为各种日志框架（例如Java.util.Logging、logback、log4j）的简单门面或抽象，允许最终用户在部署时插入所需的日志框架。
简单点说 , 门户的目的是为了解耦 , SLF4J 就像一个抽象类一样 , 不关注具体的实现 . 在使用的时候 , 也可以灵活的使用 .
三 . 集成方式
类关系图
可以看到 , 核心前置处理就是初始化阶段 , 用来将对应的插件加载进入 , 分析起来还是以 Spring 为例 :
3.1 初始化阶段
// S1 : 初始化的发起
// Log 的加载同样是在 LogFactory 环节进行的
C- SpringApplication
private static final Log logger = LogFactory.getLog(SpringApplication.class);
// S2 : LogFactory 发起处理流程 , 加载 Adapter 适配器
getLog -> LogAdapter.createLog(name);
// S3 : LogAdapter 中加载具体的处理类
public static Log createLog(String name) {
switch(logApi) {
// 代码很简单 , 也很关键 , 按照类型去创建
// 这里也可以看到 , 使用日志框架就会有耦合 , 所以使用门户更合理
case LOG4J:
return LogAdapter.Log4jAdapter.createLog(name);
case SLF4J_LAL:
return LogAdapter.Slf4jAdapter.createLocationAwareLog(name);
case SLF4J:
return LogAdapter.Slf4jAdapter.createLog(name);
default:
return LogAdapter.JavaUtilAdapter.createLog(name);
}
}
// S4 : 调用具体的实现类(以 Slf4j 为例)
C- org.slf4j.LoggerFactory # getILoggerFactory
1- performInitialization () : 获取 LoggerFactoru -> S5
- bind() : 扫描类
- StaticLoggerBinder.getSingleton().getLoggerFactory() : 返回最终对象
2- iLoggerFactory.getLogger(name) : 通过 Factory 获取 Logger 对象
// S5 : Binder绑定具体的实现类
C- org.slf4j.LoggerFactory # bind()
?- 整个过程中主要分为以下几个步骤
1- 获取实现类
|- Set<URL> staticLoggerBinderPathSet = findPossibleStaticLoggerBinderPathSet();
2- 多绑定校验 : 这也是如果有多个版本不同或者类型不同的log框架时会提醒的原因
|- reportMultipleBindingAmbiguity
3- 打印实际绑定类型 (可以看到最终的实现类)
|- reportActualBinding(staticLoggerBinderPathSet);
// S5-1 : 具体执行类的加载
// STATIC_LOGGER_BINDER_PATH -> org/slf4j/impl/StaticLoggerBinder.class
Set<URL> staticLoggerBinderPathSet = loggerFactoryClassLoader.getResources(STATIC_LOGGER_BINDER_PATH);
?- 这里是通过扫描包的方式去加载不同实现框架对其的实现
补充 : 兼容方式
既然时为了解耦 , 就不能在其中引入实际的处理类 , 那么它是怎么去集成的呢 ?
在logback 中可以看到这样一个额外的引入 :
jar:file:/D:/java/resource/repo/ch/qos/logback/logback-classic/1.2.3/logback-classic-1.2.3.jar!/org/slf4j/impl/StaticLoggerBinder.class
这里就可以看出来 , 实际上这种集成方式需要第三方去兼容.例如 log4j 的
jar:file:/D:/java/resource/repo/org/slf4j/slf4j-log4j12/1.7.30/slf4j-log4j12-1.7.30.jar!/org/slf4j/impl/StaticLoggerBinder.class
3.2 实际调用阶段
实际调用中, 我们通过 LoggerFactory.getLogger(Test.class); 发起时 , 会按照上述流程获取最终的实现 Factory 类 , 再通过其 iLoggerFactory.getLogger(name) 获取具体的 Logger 对象 ,此时的对象就已经是实现类了
总结
- 真正解耦的方式是通过 LogFactory 实现的
- 当使用 Logger 时 实际上使用的已经是实现类了
四 . Mybatis 类比
当然直接调用很容易理解 , 那么如果是一个框架 , 该如何使用这种特性呢 ?
以 Mybatis 为例 , 看一下如何使用 slf4j + logback 实现 SQL 的输出
之前写过一篇文档 ,从 Log 看 Mybatis 流程 , 我们只需要很简单的两步就实现了 log 输出日志 :
// S1 : 配置Mybatis log 方式
mybatis-plus:
configuration:
log-impl: org.apache.ibatis.logging.slf4j.Slf4jImpl
// S2 : 配置 Logback
<logger name="com.apache.ibatis" level="debug"/>
<logger name="java.sql.Connection" level="debug"/>
<logger name="java.sql.Statement" level="debug"/>
<logger name="java.sql.PreparedStatement" level="debug"/>
<logger name="com.gang.test.dao.mapper" level="debug"/>
这里选择的 log impl 为 Slf4jImpl , 由他来实现具体的 log 实现类转发 , 这里面又是哪里实现的?
我们知道 Mybatis Log 的核心处理类为 BaseJdbcLogger , 其中提供了多种不同的 Log 实现类 : StdOutImpl / Slf4jImpl 等
如果我们选择 StdOutImpl , 只能实现简单打印到控制台 , 所以我们通常会使用 Slf4jImpl 或者 Log4jImpl , 以实现打印到日志中并且进行日志抓取.
// 核心 : BaseJdbcLogger 对 Logger 进行处理 , 但是这里能看到 , 实际上 Log 是外部传进来的
public BaseJdbcLogger(Log log, int queryStack)
// 那么传入的地方是哪里 ?
在构建 MappedStatement 的时候 , Mybatis 会通过 LogFactory 对 Log 进行构建
// S1 : 加载 Log 实现类
private static void setImplementation(Class<? extends Log> implClass) {
// 通过构造器反射获取实际的 Log 处理类
Constructor<? extends Log> candidate = implClass.getConstructor(String.class);
Log log = candidate.newInstance(LogFactory.class.getName());
logConstructor = candidate;
}
// S2 : LogFactory # getLog
public static Log getLog(String logger) {
return logConstructor.newInstance(logger);
}
Mybatis 的适配方式
不同于业务系统具有明确的目的性 , 可以一开始选择使用 slf4j , 如 Mybatis 这类框架无法一开始就明确使用的框架 , 所以 Mybatis 内部的方式为 :都尝试处理 , 如果有处理成功的 , 就不处理后面的了
C- LogFactory : 依次尝试加载不同的日志框架
static {
tryImplementation(LogFactory::useSlf4jLogging);
tryImplementation(LogFactory::useCommonsLogging);
tryImplementation(LogFactory::useLog4J2Logging);
tryImplementation(LogFactory::useLog4JLogging);
tryImplementation(LogFactory::useJdkLogging);
tryImplementation(LogFactory::useNoLogging);
}
注意 , 这里和之前配置的 log-impl 并没有直接联系 , log-impl 在以下环节进行处理
// S1 : 属性加载
C- org.apache.ibatis.session.Configuration
public void setLogImpl(Class<? extends Log> logImpl) {
if (logImpl != null) {
this.logImpl = logImpl;
LogFactory.useCustomLogging(this.logImpl);
}
}
// S2 : 覆盖为自定义处理类
public static synchronized void useCustomLogging(Class<? extends Log> clazz) {
setImplementation(clazz);
}
这里也可以看出来 , Mybatis 的处理其实分成了2个步骤 :
- 按照顺序依次 全量 加载 log 处理实现类
- 如果自定义 log 实现类 ,通过 覆写 logConstructor 实现自定义处理
总结
不同于主观反射拿到实现类 , 或者多个框架共同实现一个更抽象的接口 , Slf4j 需要日志框架进行主动的适配 , 去实现它的 StaticLoggerBinder 类 , 然后再通过扫包的方式去使用具体的框架类
而通过分析 Mybatis 也看到了不同日志框架带来的影响 , 需要在代码中进行类的耦合 , 以适配不同的日志框架.
如果只是内部业务系统 , 选择 Slf4j 可以带来很多的优势, 如果是写开源框架 , 采用 Mybatis 这种先全量 , 再定制的方式进行使用也是不错的选择
作者：AntBlack
链接：https://juejin.cn/post/7071626946626453534
