Slf4j 包老冲突,每次排查半天,是什么原因?怎么解决?

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 一、前言在进行 Java 开发时,通常我们会选择 Slf4j 作为日志门面,但日志实现却不尽相同。如果系统运行中同时存在多个日志实现,就会出现类似下图的 Warning。

一、前言

在进行 Java 开发时,通常我们会选择 Slf4j 作为日志门面,但日志实现却不尽相同。如果系统运行中同时存在多个日志实现,就会出现类似下图的 Warning。

image.png图片

二、问题原因

我们知道 SpringBoot 默认使用的日志实现是 Logback,因此我们尝试在项目中引入 Log4j 的依赖时,就复现了上图的报错。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-log4j2</artifactId>
</dependency>

上图报错告知我们存在多个 SLF4J bingdings,分别位于 logback 和 log4j 包中,有两个 StaticLoggerBinder。

我们知道使用 Slf4j ,需要 LoggerFactory.getLogger() 方法获取实例。

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
private final Logger logs = LoggerFactory.getLogger(xxx.class);

我们就可以通过这个作为入口,去看看源码的实现。如下图所示,我标注了需要关注的核心代码。

  • (1)调用 getILoggerFactory() 方法得到 LoggerFactory。
  • (2)对于首次调用,INITIALIZATION_STATE 应该是 UNINITIALIZED,所以进入初始化的逻辑,调用方法 performInitialization()。
  • (3)调用 bind() 方法。
  • (4)如果不是 isAndroid(),调用 findPossibleStaticLoggerBinderPathSet() 方法,故名思意,查找可能的 staticLoggerBinder,注意这里返回的类型是 SET,即可能是多个。
  • (5)在findPossibleStaticLoggerBinderPathSet() 这个方法内,首先通过 classLoader 加载了 org/slf4j/impl/StaticLoggerBinder.class 这个类的 path,它可能存在多个,因此使用了 while 获取了所有的 path,并最终返回。

image.png图片

  • (6)reportActualBinding() 方法会校验 SET 的 size,如果大于 1,就会打印出一开始我们看见的 Warning 了。

image.png图片

三、问题解决

解决思路就是将你不想要的日志实现从依赖包中排除掉即可,通过 IDEA 提供的 Diagrams 能够非常方便的查看项目中的依赖关系。

打开项目的 POM 文件,右键选择 Diagrams -> Show Dependencies

image.png

假设我们想要排除 logback 依赖,使用 log4j。Ctrl + F 搜索 logback,可以找到引用该依赖的树形结构。

image.png

点击窗口左上角的下图中的这个图标,可以只看当前选中的这个依赖的关系。

image.png图片

选中后效果如下:

image.png图片

如上图所示,logback 由 spring-boot-starter-logging 引入,最顶层是由 spring-boot-starter-web 和 spring-boot-starter-test 引入。

我们尝试在 spring-boot-starter-web 中排除该依赖,应该就可以了。如果排出后重新搜索仍然存在 logback 依赖,则重复执行排除的操作。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-logging</artifactId>
        </exclusion>
    </exclusions>
</dependency>

四、总结

日志框架冲突特别对于新手来说处理起来比较头疼,因为涉及到了日志接口和日志实现。

我们推崇的应该是面向接口编程,因此我们大到开源项目,小到公司的公共 jar 包,应当合理利用 Maven 的传递机制。具体的日志实现不应该传递出去,避免影响到调用的下游方。

<optional>true</optional>
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
1月前
|
编解码 网络协议
Kitex踩坑记录,Kitex超时控制问题
Kitex踩坑记录,Kitex超时控制问题
Kitex踩坑记录,Kitex超时控制问题
|
10月前
I2C误码了怎么处理
I2C误码了怎么处理
|
11月前
|
微服务
什么是服务雪崩,怎么解决这个问题?
什么是服务雪崩,怎么解决这个问题?
157 0
|
Java 应用服务中间件 Maven
Jar 包依赖冲突排查思路和解决方法
Jar 包依赖冲突排查思路和解决方法
909 0
|
测试技术
R问题|代码报错如何解决?
R问题|代码报错如何解决?
242 0
|
编译器
rpath失效是怎么回事
rpath失效是怎么回事
98 0
|
Java 应用服务中间件 Docker
同事嫌我改Bug慢,原来是没掌握这些代码Debug技巧
代码Debug调试是研发工程师日常工作中必不可少的重要组成部分。进行代码Debug调试的目的无非就两个,一个是自我检查代码逻辑是否有问题,便于自己将Bug消灭在测试介入之前;另一个是进行线上问题排查定位,找到实际在跑业务的过程中出现的Bug。
同事嫌我改Bug慢,原来是没掌握这些代码Debug技巧
【吐血🤮】一次生产环境NPE崩溃的排查记录(下)
直接说引起NPE的根本原因: rx订阅没有取消,回调时Fragment已经被回收,引用view调更新方法,自然NPE。
127 0
|
测试技术 Kotlin
【吐血🤮】一次生产环境NPE崩溃的排查记录(上)
直接说引起NPE的根本原因: rx订阅没有取消,回调时Fragment已经被回收,引用view调更新方法,自然NPE。
241 0
|
存储 Java Android开发
【吐血🤮】一次生产环境NPE崩溃的排查记录(中)
直接说引起NPE的根本原因: rx订阅没有取消,回调时Fragment已经被回收,引用view调更新方法,自然NPE。
130 0