8.3 Slf4j调用过程源码分析，加入slf4j-api-version.jar，与Logback组件

Slf4j作为门面采用Logback作为实现或者采用其它上面提到过的组件作为实现类似，这里只分析采用Logback组件作为实现

8.3.1 示例代码

https://github.com/chlsmile/slf4j-logback-demo

8.3.2 pom核心配置如下

 1<dependencies>
 2    <dependency>
 3      <groupId>org.slf4j</groupId>
 4      <artifactId>slf4j-api</artifactId>
 5      <version>1.7.13</version>
 6    </dependency>
 7    <!--logback-classic依赖logback-core，会自动级联引入-->
 8    <dependency>
 9      <groupId>ch.qos.logback</groupId>
10      <artifactId>logback-classic</artifactId>
11      <version>1.2.3</version>
12    </dependency>
13  </dependencies>

8.3.3 程序入口类同上

8.3.4 源码追踪分析

1）、2）、3）、4）同上

5）调用LoggerFactory的

findPossibleStaticLoggerBinderPathSet()方法获取StaticLoggerBinderPath集合

6）调用LoggerFactory的bind()方法的staticLoggerBinderPathSet集合对象赋值

7）在LoggerFactory的bind()方法中调用loback包下的StaticLoggerBinder创建单例对象

8）在LoggerFactory的bind()方法中调用reportActualBinding()记录日志加载信息

9）LoggerFactory中INITIALIZATION_STATE的值为SUCCESSFUL_INITIALIZATION，调用StaticLoggerBinder的单例对象获取ILoggerFactory

10）此时LoggerFactory中的getLogger()方法中获取到的ILoggerFactory实际上是logback jar下的LoggerContext

11）此时LoggerFactory调用getLogger()方法获取到的Logger实际上是logback jar下的Logger

8.4 Slf4j调用过程源码分析，加入slf4j-api-version.jar，同时加入多种日志实现组件

在项目中如果用slf4j-api作为日志门面，有多个日志实现组件同时存在，例如同时存在Logback，slf4j-log4j12，slf4j-jdk14，slf4j-jcl四种实现，则在项目实际运行中，Slf4j的绑定选择绑定方式将有Jvm确定，并且是随机的，这样会和预期不符，实际使用过程中需要避免这种情况。

8.4.1 示例代码

https://github.com/chlsmile/slf4j-logback-log4j-demo

8.4.2 pom核心配置如下

 1 <dependencies>
 2    <dependency>
 3      <groupId>junit</groupId>
 4      <artifactId>junit</artifactId>
 5      <version>4.11</version>
 6    </dependency>
 7    <dependency>
 8      <groupId>org.slf4j</groupId>
 9      <artifactId>slf4j-log4j12</artifactId>
10      <version>1.7.25</version>
11    </dependency>
12    <dependency>
13      <groupId>ch.qos.logback</groupId>
14      <artifactId>logback-classic</artifactId>
15      <version>1.2.3</version>
16    </dependency>
17    <dependency>
18      <groupId>org.slf4j</groupId>
19      <artifactId>slf4j-jdk14</artifactId>
20      <version>1.7.25</version>
21    </dependency>
22    <dependency>
23      <groupId>org.slf4j</groupId>
24      <artifactId>slf4j-jcl</artifactId>
25      <version>1.7.25</version>
26    </dependency>
27  </dependencies>

8.4.3 程序入口类同上

8.4.4源码追踪分析

基本步骤同上，这里只追踪主要不同点

1）追踪LoggerFactory的bind()方法内部调用findPossibleStaticLoggerBinderPathSet()方法后，从classpath下4个jar包内找到StaticLoggerBinder

2）此时LoggerFactory的bind()方法内部调用reportMultipleBindingAmbiguity()方法，给出警告信息classpath下同时存在多个StaticLoggerBinder,JVM会随机选择一个StaticLoggerBinder

9桥接遗留的api

在实际环境中我们经常会遇到不同的组件使用的日志框架不同的情况，例如Spring Framework使用的是日志组件是Commons Logging，XSocket依赖的则是Java Util Logging。当我们在同一项目中使用不同的组件时应该如果解决不同组件依赖的日志组件不一致的情况呢？现在我们需要统一日志方案，统一使用Slf4j，把他们的日志输出重定向到Slf4j，然后Slf4j又会根据绑定器把日志交给具体的日志实现工具。Slf4j带有几个桥接模块，可以重定向Log4j，JCL和java.util.logging中的Api到Slf4j。

9.1 遗留的api桥接方案

9.2 桥接方式参见下图

9.3 使用Slf4j桥接要注意事项

在使用Slf4j桥接时要注意避免形成死循环，在项目依赖的jar包中不要存在以下情况。

9.4 遗留api桥接死循环源码分析源码

这里以项目中集成log4j-over-slf4j与slf4j-log4j12为例，其它组合形成死循环原理相类似。

9.4.1 示例代码

https://github.com/chlsmile/slf4j-Infinite-loop-demo

9.4.2 程序入口类同上

9.4.3 源码追踪分析

基本步骤同上，调用链路LoggerFactory.getLogger()>LoggerFactory.getILoggerFactory()> LoggerFactory.performInitialization()>LoggerFactory.bind()

1）LoggerFactory.bind()方法内部调用StaticLoggerBinder.getSingleton()获取StaticLoggerBinder实例

2）StaticLoggerBinder调用构造方法内部调用Log4jLoggerFactory构造方法创建ILoggerFactory

3）Log4jLoggerFactory加载内部static代码块，校验出classpath下存在org.apache.log4j.Log4jLoggerFactory，抛出异常

10排除第三方日志依赖

在实际使用过程中，项目会根据需要引入一些第三方组件，例如常用的Spring，而Spring本身的日志实现使用了Commons Logging，我们又想使用Slf4j+Loback组合，这时候需要在项目中将Commons Logging排除掉，通常会用到以下3种方案，3种方案各有利弊，可以根据项目的实际情况选择最适合自己项目的解决方案。

10.1 方案一采用maven的exclusion方案

 1<dependency>
 2    <groupId>org.springframework</groupId>
 3    <artifactId>spring-core</artifactId>
 4    <exclusions>
 5        <exclusion>
 6            <groupId>commons-logging</groupId>
 7            <artifactId>commons-logging</artifactId>
 8        </exclusion>
 9    </exclusions>
10    <version>${springframework.version}</version>
11</dependency>

这种方案优点是exclusion是maven原生提供的，不足之处是如果有多个组件都依赖了commons-logging，则需要在很多处增加，使用起来不太方便。

10.2 方案二在maven声明commons-logging的scope为provided

 1<dependency>
 2  <groupId>commons-logging</groupId>
 3  <artifactId>commons-logging</artifactId>
 4  <version>1.1.1</version>
 5  <scope>provided</scope>
 6</dependency>
 7<dependency>
 8  <groupId>org.slf4j</groupId>
 9  <artifactId>jcl-over-slf4j</artifactId>
10  <version>1.8.0-beta2</version>
11</dependency>

这种方案在调试代码时还是有可能导致IDE将commons-logging放置在classpath下，从而导致程序运行时出现异常。

10.3 方案三在maven私服中增加类似于99.0-does-not-exist这种虚拟的版本号

 1<dependency>    
 2    <groupId>commons-logging</groupId>    
 3    <artifactId>commons-logging</artifactId>    
 4    <version>99.0-does-not-exist</version>    
 5</dependency> 
 6<dependency>
 7  <groupId>org.slf4j</groupId>
 8  <artifactId>jcl-over-slf4j</artifactId>
 9  <version>1.8.0-beta2</version>
10</dependency>

这种方案好处是声明方式比较简单，用IDE调试代码时也不会出现问题，不足之处是99.0-does-not-exist这种版本是maven中央仓库中是不存在的，需要发布到自己的maven私服中。

11总结

由于历史原因JDK自身提供的Log组件出现的较晚，导致Jdk提供Log组件时第三方社区的日志组件已经比较稳定成熟。经过多年的发展Slf4j+Logback与组合，Commons Logging与Log4j组合两大阵营已经基本成为了Java项目开发的标准，建议在新的项目开发中从这两种方案中选择适合自己项目的组合方案。

作者介绍：
圣卡西（企业代号名），目前负责贝壳找房java后台开发工作。

本文转载自公众号贝壳产品技术（ID：gh_9afeb423f390）。

原文链接：

https://mp.weixin.qq.com/s/FWnh71eN5jxiu7aBOiUHaA

创作场景

Java 常用日志框架介绍（下）