SLF4j 居然不是编译时绑定?日志又该如何正确的分文件输出?——原理与总结篇

各位新年快乐,过了个新年,休(hua)息(shui)了三周,不过我又回来更新了,经过前面四篇想必小伙伴已经了解日志的使用以及最佳实践了,这个系列的文章也差不多要结束了,今天我们来总结一下。

概览

这篇文章我们讨论一下 SLF4j 的设计,以及 SLF4j 好在哪,之后进行一些答疑与前系列文章勘误,最最后我们来了解一下如何正确的分文件输出日志。

分析设计

SLF4j 并没有使用网上所谓的编译时绑定,实际上是采用了约定俗成的方式,如何做的?很简单,就是直接加载org/slf4j/impl/StaticLoggerBinder.class,找到一个直接使用,没找到或者找到多个报警告,,分析一下源码:

我们一起来看一个个 Logger 实例是如何创建的:

  1. org.slf4j.LoggerFactory#getLogger(java.lang.String),获取 logger 实例的真正入口
  2. ch.qos.logback.classic.LoggerContext#getLogger(java.lang.String),调用了 logback 的LoggerContext(实现 LoggerFactory),具体如何调用到这里下面解析)
  3. 可以看到childLogger = logger.createChildByName(childName);创建了 loggger实例,继续跟进
  4. ch.qos.logback.classic.Logger#createChildByName方法中可以看到childLogger = new Logger(childName, this, this.loggerContext);,至此我们目的也达到了,logger 是 new 出来的并不是所谓的编译时绑定。

我们继续来跟踪如何调用到 logback 的 LoggerContext(LogggerFactory),并且来验证一下是否真的是所谓的编译时绑定:

  1. 还是org.slf4j.LoggerFactory#getLogger(java.lang.String)方法,这次我们跟进到org.slf4j.LoggerFactory#getILoggerFactory方法中发现调用了performInitialization,跟进去发现调用了bind,继续跟进发现调用了findPossibleStaticLoggerBinderPathSet方法在当前ClassPath下查询了所有名为org/slf4j/impl/StaticLoggerBinder.class类路径返回
  2. 真正代码如下,注释写的很明确:

    Set staticLoggerBinderPathSet = null;
    // skip check under android, see also
    // http://jira.qos.ch/browse/SLF4J-328
    if (!isAndroid()) {
      staticLoggerBinderPathSet = findPossibleStaticLoggerBinderPathSet();
      reportMultipleBindingAmbiguity(staticLoggerBinderPathSet);
    }
    // the next line does the binding
    StaticLoggerBinder.getSingleton();

    StaticLoggerBinder这个类就是绑定的关键,点进去发现根本不是 SLF4j 的类,而是来自于 Logback,也就是说,SLF4j 使用了第三方(Logback、Log4j 等)提供的中介类,(Spring Boot 自动配置也部分使用了这种思想,以后的全栈系列文章将会有详细解析,欢迎关注),如果出出现NoClassDefFoundError则提示一下使用者,然后不再处理日志。

    SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
    SLF4J: Defaulting to no-operation (NOP) logger implementation
    SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

结论:

给出结论之前我们先来明确一下 Java 的绑定(Binding)的概念,Java 本身只支持静态(static)绑定与运行时(runtime)绑定,直到与 JDK 1.6 版本一起发布的 JSR269 才能进行编译时绑定,员外理解的编译时绑定类似于 lomok 在编译过程中修改字节码。SFL4j 的 logger 实例是 new 出来的,绑定 LogContextStaticLoggerBinder(中介类) 是写死的,编译时并没有处理任何逻辑,也谈不上什么编译时绑定,员外翻遍了 SLF4j 文档也没有找到任何有关编译时绑定的材料,官方只提到了 “static binding”, 所以回到文章标题,网上流传的编译时绑定根本就是错的,SLF4j使用的是 Convention over Configuration(CoC)– 惯例优于配置原则,我不管你是什么日志框架,我只加载org.slf4j.impl.StaticLoggerBinder。这完美契合了软件设计的 KISS(Keep It Simple, Stupid)原则,而 Commons-logging 魔法(magic)一样的动态加载虽然设计很高大上,在应用领域却直接被打脸,低效率、与 OSGi 共同使用所导致的 ClassLoader 问题更是火上浇油,所以员外与大家共勉,写代码切勿炫技。

以上是本文核心,略过的读者劳烦再读一次。

为什么SLF4j 更好

先了解一下为什么说 SLF4j 更好,下面两段话来自于Spring 4.x 官方文档:

https://docs.spring.io/spring...

Not Using Commons Logging

Unfortunately, the runtime discovery algorithm in commons-logging, while convenient for the end-user, is problematic. If we could turn back the clock and start Spring now as a new project it would use a different logging dependency. The first choice would probably be the Simple Logging Facade for Java ( SLF4J), which is also used by a lot of other tools that people use with Spring inside their applications.

不幸的是, commons-logging的运行时发现算法虽然对用户很方便,但却有问题。 如果我们有后悔药能够将 Spring 作为一个新项目重新启动,首选可能是 Simple Logging Facade for Java(SLF4J),Spring 所依赖的其他工具也能使用它。

That might seem like a lot of dependencies just to get some logging. Well it is, but it is optional, and it should behave better than the vanilla commons-logging with respect to classloader issues, notably if you are in a strict container like an OSGi platform. Allegedly there is also a performance benefit because the bindings are at compile-time not runtime.

这看起来好像仅仅为了日志就需要很多依赖。但这些依赖都是可选的,在类加载器问题方面,它应该比普通的 Commons-logging 表现得更好,特别是如果您在 OSGi 平台这样的严格容器中。据说性能还有优势,因为绑定是在编译时而不是运行时。

这两段文字可谓是肺腑之言,公平公正,员外也没有到处去验证,所谓性能优势我认为作为static final级别变量,性能优势也不会太大。员外认为 SLF4j 本质上更好的原因在于其提供市面上所有日志框架的兼容解决方案。

勘误

第一篇文章「Java日志体系居然这么复杂?——架构篇」其中 Spring Boot的使用依赖,我写到“Spring已经写好了一个log4j2-starter但缺少桥接包”是不对的,员外出于好奇验证一下,之所以 Spring 没有依赖 jcl-over-slf4j 是因为 Spring Boot 2.x 版本以后依赖了其自己实现的 Spring-jcl 桥接,而 1.x 版本则带有 jcl-over-slf4j 依赖,所以抱歉,我的文章这里写错了,望各位周知。

第二篇文章「五年Java经验,面试还是说不出日志该怎么写更好?——日志规范与最佳实践篇」其中 Log4j2配置文件那一段有误,缺了一个名为 STDOUT 的控制台Appender,代码如下:


  

第四篇文章「这么香的日志动态级别与输出,你确定不进来看看?——生产环境动态输入日志级别、文件

这篇文章也是有一个配置文件粘贴错位置了,不过源码是正确的,请各位下载github源码,以源码为准。

答疑

第一个答疑是读者的一个小要求,问我能不能写一个YAML格式的 Log4j2 配置文件,当然可以了,下面是手写的,请测试一下再进入生产使用:

Configuration:
  status: debug
  name: YAMLConfig
  properties:
    property:
      name: baseDir
      value: logs
  appenders:
    RollingFile:
      - name: RollingFile
        fileName: ${baseDir}/log.log
        filePattern: "${baseDir}/$${date:yyyy-MM}/log-%d{yyyy-MM-dd-HH}-%i.log.gz"
        PatternLayout:
          pattern: "%d{yyyy-MM-dd HH:mm:ss.SSS} %5p %pid --- [%t] %-40.40c{1.} : %m%n${sys:LOG_EXCEPTION_CONVERSION_WORD}"
        Policies:
          - TimeBasedTriggeringPolicy: true
            SizeBasedTriggeringPolicy:
              size: 250 MB
        DefaultRollOverStrategy:
          max: 100
          Delete:
            basePath: ${baseDir}
            maxDepth: 2
            IfFileName:
              glob: "*/app-*.log.gz"
              IfLastModified:
                age: 30d
                IfAny:
                  IfAccumulatedFileSize:
                    exceeds: 100 GB
                  IfAccumulatedFileCount:
                    exceeds: 10

    Console:
      name: STDOUT
      PatternLayout:
        Pattern: "[%-5level] %d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %c{1} - %msg%n"
      Filters:
        ThresholdFilter:
          level: debug

  Loggers:
    logger:
      - name: org.apache.logging.log4j.test2
        level: debug
        additivity: false
        AppenderRef:
          ref: RollingFile
    Root:
      level: trace
      AppenderRef:
        ref: STDOUT

另外一个小伙伴在我的文章下提出了几个问题:

每个日志文件大小,如何分割?日期分割?一天一个? 是一天一个目录还是一天一个文件? 还是一周一个目录? 区不区分error和info日志在不同文件?打不打印其他级别日志? 能不能动态修改日志级别不停机?是否需要异步日志,你们的访问量到了默认同步日志扛不住的地步了么?怎么异步日志?

虽然这个小伙伴态度不是很好,但是问题还是很好的:

  1. 每个日志文件大小,如何分割?日期分割?一天一个? 是一天一个目录还是一天一个文件? 还是一周一个目录?

    每个文件大小我喜欢250M这个数字,也这么配的,日期分割这个就不应该我来讲了,我说一个月一分割,一般应用都好几百个G了,我说一分钟一分割,好多应用还不到1M,所以按照自己线上的需求慢慢调整才行。

  2. 区不区分error和info日志在不同文件?

    员外坚决反对按照日志级别分文件,设想一下回溯现场的时候,info、warn、error 级别都是有用日志,如果分开了,是不是逐个去看?如果让我逐个去定位错误位置,我想我会骂娘的,至于如何正确的分文件输出日志,后面我会有补充,见下文。

  3. 打不打印其他级别日志?

    打不打印其他级别日志根本就是个伪问题,不需要打印其他级别也就不需要那么多日志级别了,这个问题是不是可以理解为日志应该开到什么级别,我一般开 info 级别,我也见过线上只开 error 的,然后业务里的日志输出都是error的(反面教材)。

  4. 能不能动态修改日志级别不停机?

    能的,参考我上一篇文章,而且这方面应该没有人做的比我文章里写的更好了。

  5. 是否需要异步日志,怎么异步日志?

    我个人不倾向于异步日志,磁盘IO满了,开了异步也是缓冲区满,缓冲区满了要么阻塞,要么抛弃,至于开了异步所带来的性能优势并不大。怎么异步日志我文章里也有写,请参阅公众号。

  6. 你们的访问量到了默认同步日志扛不住的地步了么?

    日志扛不住了要先考虑是不是过多,如果实在没法减少日志,就考虑将日志输出路径单独挂载磁盘、更换更好的磁盘等等。

正确的分文件输出日志

读过员外的文章就知道,员外是赞成分文件输出日志的,不过员外反对按照级别来输出文件。如何正确的按文件输出日志呢?以前文章没有写过,这里来补充一下。

很简单,配置多个appender,然后可以按照 loggger 来分文件,代码如下:


    

    

这个倒是很简单,但是还有一个问题,单个类如果有多种日志想要输出到多个位置,该怎么办,解决方案有两种,一个类持有多个 logger 实例:

class A {
  static final Logger log = LoggerFactory.getLogger("com.jiyuanwai.log.xxx");
    static final Logger log = LoggerFactory.getLogger("com.jiyuanwai.log.yyy");
  
  ...
}

这种办法实现简单,但是不优雅,我们来尝试拿出另外一套方案,就是 Maker 配合 Filter 来实现,当然根据以前的文章了解到我们还可以使用 Sift 配合 MDC 来实现,但员外不推荐,至于为什么,作为公众号粉丝福利可以关注公众号回复 “Sift” 来获取答案,我们来继续看 demo:

// Marker 也可以考虑 static final
Marker file1 = MarkerFactory.getMarker("file1");
Marker file2 = MarkerFactory.getMarker("file2");
log.info(file1, "A file 1 log.");
log.info(file2, "A file 2 log.");

配置文件如下:


  ${LOG_PATH}/testFile1.log
  true
  
    
      file1
    
    
    DENY
    
    ACCEPT
  
  
    ${FILE_LOG_PATTERN}
  


  ${LOG_PATH}/testFile2.log
  true
  
    
      
      file2
    
    
    DENY
    
    ACCEPT
  
  
    ${FILE_LOG_PATTERN}
  



  
  

结束语

以上只是抛砖引玉,日志分文件输出还可以写更多逻辑,小伙伴需要自己动手发掘。

至此日志系列就算是告一段落了,如果还有疑问小伙伴可以留言讨论,接下来一系列我们进入Spring Boot + Vue 的全栈之路,敬请关注。

以上是个人观点,如果有问题或错误,欢迎留言讨论指正,码字不易,如果觉得写的不错,求关注、求点赞、求转发

扫码关注公众号,第一时间获得更新

扫码关注

你可能感兴趣的:(slf4j,日志,java,logback)