slf4j-源码简析

//org.slf4j.LoggerFactory的getLogger(Class)
public static Logger getLogger(Class<?> clazz) {
    //调用了getLogger(String name)
  Logger logger = getLogger(clazz.getName());
  return logger;
}

//org.slf4j.LoggerFactory的getLogger(String)
public static Logger getLogger(String name) {
    //找到真正的LoggerFactory是关键，厂商（比如logback）会实现org.slf4j.ILoggerFactory接口
  ILoggerFactory iLoggerFactory = getILoggerFactory();
  return iLoggerFactory.getLogger(name);
}

//org.slf4j.LoggerFactory的getILoggerFactory
public static ILoggerFactory getILoggerFactory() {
    //双重检查，检查是否已经绑定了相关实现
  if (INITIALIZATION_STATE == UNINITIALIZED) {
    synchronized (LoggerFactory.class) {
      if (INITIALIZATION_STATE == UNINITIALIZED) {
        INITIALIZATION_STATE = ONGOING_INITIALIZATION;
        //bind
        performInitialization();
      }
    }
  }
  switch (INITIALIZATION_STATE) {
      case SUCCESSFUL_INITIALIZATION:
          //具体的StaticLoggerBinder需要与具体的厂商适配（StaticLoggerBinder不是接口，是一个具体的类），
          //StaticLoggerBinder会实现org.slf4j.spi.LoggerFactoryBinder接口，该接口就提供了getLoggerFactory方法，
          //getLoggerFactory会返回org.slf4j.ILoggerFactory，调用org.slf4j.ILoggerFactory的getLogger就可以得到org.slf4j.Logger。
          //这里getLoggerFactory得到的LoggerFactory
        return StaticLoggerBinder.getSingleton().getLoggerFactory();
      case ......
  }
  throw new IllegalStateException("Unreachable code");
}

下面就来看slf4j是如何找到厂商实现的，即performInitialization是如何初始化的，初始化的逻辑主要就是找到StaticLoggerBinder，所谓找到StaticLoggerBinder就是由jvm类加载器加载StaticLoggerBinder。

//org.slf4j.LoggerFactory的performInitialization的核心逻辑在bind方法
private final static void bind() {
  try {
    Set<URL> staticLoggerBinderPathSet = null;
    if (!isAndroid()) {
        //findPossibleStaticLoggerBinderPathSet会寻找到所有的"org/slf4j/impl/StaticLoggerBinder.class"，
      staticLoggerBinderPathSet = findPossibleStaticLoggerBinderPathSet();
      //如果找到了多个binder则打印这些候选者
      reportMultipleBindingAmbiguity(staticLoggerBinderPathSet);
    }
    //这里进行了真正的bind，slf api中并没有StaticLoggerBinder的具体类，
    //具体的StaticLoggerBinder需要与具体的厂商适配（logback本身就实现了StaticLoggerBinder，不需要slf4j适配，log4j就需要引入slf4j-log4j12依赖来实现适配，slf4j-log4j12中就有StaticLoggerBinder），
    //StaticLoggerBinder会有一个getSingleton静态方法，通过该方法得到一个StaticLoggerBinder实例（单例）。
    //StaticLoggerBinder会实现org.slf4j.spi.LoggerFactoryBinder接口，该接口提供了getLoggerFactory方法，
    //从而可以通过StaticLoggerBinder.getSingleton().getLoggerFactory()得到org.slf4j.ILoggerFactory。
    //可能会有多个StaticLoggerBinder，选择哪一个由jvm的类加载决定。
    StaticLoggerBinder.getSingleton();
    INITIALIZATION_STATE = SUCCESSFUL_INITIALIZATION;
    reportActualBinding(staticLoggerBinderPathSet);
    fixSubstituteLoggers();
    replayEvents();
    // release all resources in SUBST_FACTORY
    SUBST_FACTORY.clear();
  } catch (NoClassDefFoundError ncde) {
    //......
  }
}

这里有一个不太容易接受的地方就是需要适配slf4j的getSingleton静态方法（其他都是通过抽象类、接口进行适配的，很正常），但试想还有其他什么方式可以实现这种适配的目的的，其中一种就是spi机制，个人感觉spi要好一些，起码它不需要getSingleton这种无厘头的硬编码。slf4j与jdk的spi不同的是，slf4j是自己提供StaticLoggerBinder（logback除外），而spi是由各大厂商去适配，所以slf4j的这种方式也是可以接受的。

这也是所谓的门面模式（外观模式），可以隐藏子系统的具体差异，对外提供统一的接口（slf4j为了提供统一的接口，在无法让厂商提供支持的情况，就会自己适配）。jdbc也有类似的思想，不同数据库的连接实现肯定是不一样的，而我们只需要面对统一的jdbc接口。从jdbc4开始不再需要Class.forName显示加载java.sql.Driver实现了，而是通过spi自动加载具体实现。

参考：https://www.slf4j.org/manual.html