目录
- 1 设计模式门面模式
- 2 slf4j源码解析
1 设计模式门面模式
设计模式之门面模式与装饰器模式详解和应用：https://blog.csdn.net/ZGL_cyy/article/details/129073521
slf4j是门面模式的典型应用，因此在讲slf4j前，我们先简单回顾一下门面模式，
门面模式，其核心为外部与一个子系统的通信必须通过一个统一的外观对象进行，使得子系统更易于使用。
用一张图来表示门面模式的结构为：
门面模式的核心为Facade即门面对象，门面对象核心为几个点：
- 知道所有子角色的功能和责任
- 将客户端发来的请求委派到子系统中，没有实际业务逻辑
- 不参与子系统内业务逻辑的实现
大致上来看，对门面模式的回顾到这里就可以了，开始接下来对SLF4J的学习。
2 slf4j源码解析
我们为什么要使用slf4j，举个例子：
我们自己的系统中使用了logback这个日志系统
我们的系统使用了A.jar，A.jar中使用的日志系统为log4j
我们的系统又使用了B.jar，B.jar中使用的日志系统为slf4j-simple
这样，我们的系统就不得不同时支持并维护logback、log4j、slf4j-simple三种日志框架，非常不便。
解决这个问题的方式就是引入一个适配层，由适配层决定使用哪一种日志系统，而调用端只需要做的事情就是打印日志而不需要关心如何打印日志，slf4j或者commons-logging就是这种适配层，slf4j是本文研究的对象。
从上面的描述，我们必须清楚地知道一点：slf4j只是一个日志标准，并不是日志系统的具体实现。理解这句话非常重要，slf4j只做两件事情：
- 提供日志接口
- 提供获取具体日志对象的方法
slf4j-simple、logback都是slf4j的具体实现，log4j并不直接实现slf4j，但是有专门的一层桥接slf4j-log4j12来实现slf4j。
为了更理解slf4j，我们先看例子，再读源码，相信读者朋友会对slf4j有更深刻的认识。
slf4j应用举例
上面讲了，我们先定义一个pom.xml，引入相关jar包：
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.2.3</version>
<scope>compile</scope>
</dependency>
...
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jul-to-slf4j</artifactId>
<version>1.7.30</version>
<scope>compile</scope>
</dependency>
研究的便是slf4j及其实现logback的关系。
而我们的slf4j便是相当于一个Facade层，所用的日志打印都是通过slf4j来转发，但是具体的功能实现是由logback来实现，当然也可以由别的依赖来实现，比如slf4j-simple。
首先我们看springboot框架默认实现：
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class TestLogger {
private static final Logger log = LoggerFactory.getLogger(TestLogger.class);
public static void main(String[] args) {
log.info("test---------->>>>>>>>>>>><<<<<<<");
}
}
归根结底，所有的用法都只是片面，我们要理解原理，还是要从源码入手。进入getLogger方法：
public static Logger getLogger(Class<?> clazz) {
Logger logger = getLogger(clazz.getName());
if (DETECT_LOGGER_NAME_MISMATCH) {
Class<?> autoComputedCallingClass = Util.getCallingClass();
if (autoComputedCallingClass != null && nonMatchingClasses(clazz, autoComputedCallingClass)) {
Util.report(String.format("Detected logger name mismatch. Given name: \"%s\"; computed name: \"%s\".", logger.getName(), autoComputedCallingClass.getName()));
Util.report("See http://www.slf4j.org/codes.html#loggerNameMismatch for an explanation");
}
}
return logger;
}
重点关注
getLogger(clazz.getName())
继续点击：
public static Logger getLogger(String name) {
ILoggerFactory iLoggerFactory = getILoggerFactory();
return iLoggerFactory.getLogger(name);
}
日志打印的具体实现便在
public static ILoggerFactory getILoggerFactory() {
if (INITIALIZATION_STATE == 0) {
Class var0 = LoggerFactory.class;
synchronized(LoggerFactory.class) {
if (INITIALIZATION_STATE == 0) {
INITIALIZATION_STATE = 1;
performInitialization();
}
}
}
switch(INITIALIZATION_STATE) {
case 1:
return SUBST_FACTORY;
case 2:
throw new IllegalStateException("org.slf4j.LoggerFactory in failed state. Original exception was thrown EARLIER. See also http://www.slf4j.org/codes.html#unsuccessfulInit");
case 3:
return StaticLoggerBinder.getSingleton().getLoggerFactory();
case 4:
return NOP_FALLBACK_FACTORY;
default:
throw new IllegalStateException("Unreachable code");
}
}
日志打印的重点便在于返回
StaticLoggerBinder.getSingleton().getLoggerFactory()
这个对象来实现具体的日志打印工作，那StaticLoggerBinder这个类又是从哪里来，是要干什么的呢？
我们通过实际代码执行可以知道，StaticLoggerBinder便是logback这个jar包提供对slf4j日志接口LoggerFactoryBinder的具体实现，也就是说实际的日志打印slf4j不能执行，只能通过接口的实现类StaticLoggerBinder来进行执行。
这样的好处便在于slf4j相当于只是提供一个接口或者说标准，但是具体的执行可以由其实现类来执行，这样只要是实现了slf4j标准接口的任意日志框架便都可以来执行日志打印。
通过这种方式slf4j可以同时支持多种日志框架，且无需任何配置，只需要引入特定的jar包让其拥有指定全类名的StaticLoggerBinder类即可。
那么这样也会导致另一个问题，如果系统引入了多个同时实现slf4j接口的类，那么系统怎么办，是否会报错？
这种特殊情况，slf4j也有做处理，其处理方式便是通过打印所有的引入实现类，然后由JVM虚拟机选择一个合适的实现类来执行日志打印。
这样既不会影响系统日志执行，也能使程序员通过日志，清楚的看出系统中存在哪些日志的实现类。
其具体代码在上
private static final void performInitialization() {
bind();
if (INITIALIZATION_STATE == 3) {
versionSanityCheck();
}
}
在bind执行：
private static final void bind() {
try {
String msg;
try {
Set<URL> staticLoggerBinderPathSet = null;
if (!isAndroid()) {
staticLoggerBinderPathSet = findPossibleStaticLoggerBinderPathSet();
reportMultipleBindingAmbiguity(staticLoggerBinderPathSet);
}
StaticLoggerBinder.getSingleton();
INITIALIZATION_STATE = 3;
reportActualBinding(staticLoggerBinderPathSet);
} catch (NoClassDefFoundError var7) {
......
重点便在于
findPossibleStaticLoggerBinderPathSet();//找到潜在的slf4j实现类
reportMultipleBindingAmbiguity(staticLoggerBinderPathSet);//打印所有的实现类全类名
reportActualBinding(staticLoggerBinderPathSet);//打印实际的实现类全类名
详细方法如下：
static Set<URL> findPossibleStaticLoggerBinderPathSet() {
LinkedHashSet staticLoggerBinderPathSet = new LinkedHashSet();
try {
ClassLoader loggerFactoryClassLoader = LoggerFactory.class.getClassLoader();
Enumeration paths;
if (loggerFactoryClassLoader == null) {
paths = ClassLoader.getSystemResources(STATIC_LOGGER_BINDER_PATH);
} else {
paths = loggerFactoryClassLoader.getResources(STATIC_LOGGER_BINDER_PATH);
}
while(paths.hasMoreElements()) {
URL path = (URL)paths.nextElement();
staticLoggerBinderPathSet.add(path);
}
} catch (IOException var4) {
Util.report("Error getting resources from path", var4);
}
return staticLoggerBinderPathSet;
}
可以看到，其是通过
STATIC_LOGGER_BINDER_PATH
即，
private static String STATIC_LOGGER_BINDER_PATH = "org/slf4j/impl/StaticLoggerBinder.class
也就是指定的全限定类名来进行加载的。
这样就涉及到一个问题， 不同的jar包依赖是可以创建同样的全限定类名的，这样会导致
paths = loggerFactoryClassLoader.getResources(STATIC_LOGGER_BINDER_PATH);
出现多个具有同样全限定类名的类被重复找到。
那么在slf4j有多个实现的时候，如何保证其加载指定的实现呢？
实测：如果有多个日志实现的话，默认使用先导入的实现
