约 716 字大约 2 分钟
问题
笔者最近创建一个模块引入mongoDB相关依赖，启动时出现下面这个问题，很明显是项目中某些依赖的log4j和slf4j依赖冲突了，所以我们必须定位到导致冲突的依赖并将这些依赖排除。
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/E:/repository/org/apache/logging/log4j/log4j-slf4j-impl/2.11.2/log4j-slf4j-impl-2.11.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/E:/repository/ch/qos/logback/logback-classic/1.2.3/logback-classic-1.2.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.apache.logging.slf4j.Log4jLoggerFactory]
Exception in thread "main" java.lang.StackOverflowError
at org.apache.logging.log4j.util.StackLocator.getCallerClass(StackLocator.java:108)
at org.apache.logging.log4j.util.StackLocator.getCallerClass(StackLocator.java:121)
at org.apache.logging.log4j.util.StackLocatorUtil.getCallerClass(StackLocatorUtil.java:55)
at org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:42)
at org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
at org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:358)
解决思路
下载安装Maven Helper
查阅网上资料大部分答案都推荐下载Maven Helper，所以笔者也下载了这个插件，通过这个插件定位到冲突的日志依赖。
如下图所示，完成下载后重启一下IDEA，就可以使用了。
查找冲突依赖
打开pom文件就会text右边多了一个依赖分析的tab栏。我们点入查看详情
如下图，考虑到是存在不同的日志依赖导致冲突，所以笔者在搜索栏搜索log，可以看到一大块蓝绿的部分，他们分别是mongoDB自带的日志依赖和我们自己引入了log4j依赖都存在系统的log4j-api，所以我们必须手动的将mongoDB中蓝绿部分的依赖移除。
排除冲突的依赖
如下所示，根据上文蓝绿色定位到的冲突的依赖，选择一个将其移除即可
<!--mongodb依赖-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-mongodb-reactive</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
启动查看是否解决问题
可以看到项目正常启动，我们的依赖移除步骤是正确的。
小结
本次问题解决过程中一开始是基于网上答案，通过Maven Helper搜索logback并移除其中一个logback，移除后发现还是没有解决问题，猜测可能是项目中还存在冲突的日志依赖，所以笔者索性直接搜索log，果然定位到更加根源的问题(log4j冲突)。 所以我们日常排错过程中，找到思路时尝试解决问题却没有完全解决时，建议根据现象进一步推测是否我们定位到的问题并没有完全解决。就以本次冲突解决为例，我们根据网上答案排除的依赖却还是报错，原因大概率是依赖冲突还是存在，我们不妨增加搜索面去定位问题。