在项目配置的初期,我们经常可以看到这样的错误:
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/Users/liyi/.m2/repository/ch/qos/logback/logback-classic/1.2.3/logback-classic-1.2.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/Users/liyi/.m2/repository/org/apache/logging/log4j/log4j-slf4j-impl/2.10.0/log4j-slf4j-impl-2.10.0.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 [ch.qos.logback.classic.util.ContextSelectorStaticBinder]
大部分的人就网上把答案一搜索,排除一下不想要的依赖关系就完事儿。但这究竟是怎么发生的,却很少有人去了解。本文就是想要通过源码的角度去剖析这个错误发生的原因。
通过上篇文章我们了解到,其实SLF4J是可以对接多套日志实现的,上面错误发生的原因就是因为项目classpath中有多个日志的实现,导致SLF4J报错.
从上面的错误日志中,我们可以看到SLF4J选择了Logback, 这一点从上面的日志中可以看到:
SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder]
需要注意的是,这个选择其实是由JVM决定, 官方的说法你可以简单的认为是随机的,因此在实际生产中应当避免这个问题。以下是官方的原话:
The way SLF4J picks a binding is determined by the JVM and for all practical purposes should be considered random.
代码版本2.10.0
SLF4J的实现类被称为provider,被需要继承SLF4JServiceProvider接口,所以寻找实现类的过程也就是寻找这个provier实现类的过程。
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class HelloWorld {
public static void main(String[] args) {
Logger logger = LoggerFactory.getLogger(HelloWorld.class);
logger.info("Hello World");
}
}
public static Logger getLogger(Class<?> clazz) {
Logger logger = getLogger(clazz.getName());
//省略非关键部分代码...
}
public static Logger getLogger(String name) {
ILoggerFactory iLoggerFactory = getILoggerFactory();
return iLoggerFactory.getLogger(name);
}
static SLF4JServiceProvider getProvider() {
//开始是未初始化状态(UNINITIALIZED), 然后执行初始化操作
//这里用了一个双检锁的单例模式来初始化provider变量
if (INITIALIZATION_STATE == UNINITIALIZED) {
synchronized (LoggerFactory.class) {
if (INITIALIZATION_STATE == UNINITIALIZED) {
INITIALIZATION_STATE = ONGOING_INITIALIZATION;
performInitialization();
}
}
}
//下面是对初始化过程的一个判断
switch (INITIALIZATION_STATE) {
case SUCCESSFUL_INITIALIZATION:
return PROVIDER;
//没有找到实现,就会使用NOP(no operation的模式)
case NOP_FALLBACK_INITIALIZATION:
return NOP_FALLBACK_FACTORY;
//初始化过程中报错
case FAILED_INITIALIZATION:
throw new IllegalStateException(UNSUCCESSFUL_INIT_MSG);
//这个是针对logback实现做的一个修复,暂且可以不管
case ONGOING_INITIALIZATION:
// support re-entrant behavior.
// See also http://jira.qos.ch/browse/SLF4J-97
return SUBST_PROVIDER;
}
throw new IllegalStateException("Unreachable code");
}
上面的流程就是这样的:
异常对于logback实现继续处理没有有未初始化执行初始化抛出异常继续处理是否找到实现返回NOP实现结束返回找到的实现
上面提到的NOP实现其实就是字面意思,什么都不做,把日志打到/dev/null。错误如下:
SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#noProviders for further details.
private final static void bind() {
try {
//这里就是寻找provider的方法
List<SLF4JServiceProvider> providersList = findServiceProviders();
//这就是开篇提到的报错的检查点,上面的list.size()大于1就报错
reportMultipleBindingAmbiguity(providersList);
if (providersList != null && !providersList.isEmpty()) {
PROVIDER = providersList.get(0);
PROVIDER.initialize();
INITIALIZATION_STATE = SUCCESSFUL_INITIALIZATION;
//打印日志,告诉程序猿实际使用的日志实现
reportActualBinding(providersList);
//省略处理logback实现bug的代码...
} else {
INITIALIZATION_STATE = NOP_FALLBACK_INITIALIZATION;
//省略打印信息的代码...
}
} catch (Exception e) {
failedBinding(e);
throw new IllegalStateException("Unexpected initialization failure", e);
}
}
private static List<SLF4JServiceProvider> findServiceProviders() {
ServiceLoader<SLF4JServiceProvider> serviceLoader = ServiceLoader.load(SLF4JServiceProvider.class);
List<SLF4JServiceProvider> providerList = new ArrayList<SLF4JServiceProvider>();
for (SLF4JServiceProvider provider : serviceLoader) {
providerList.add(provider);
}
return providerList;
}
对错误追根问底,其实并没有那么难,而且往往还能有更多的收获。譬如:有段时间经常在面试题中见到的双检锁单例模式,这里就有实践的例子。
版权说明 : 本文为转载文章, 版权归原作者所有 版权申明
原文链接 : https://blog.csdn.net/sweetyi/article/details/104633321
内容来源于网络,如有侵权,请联系作者删除!