slf4j 作用及logback概述

为什么要使用slf4j

现实场景：

我们自己的系统中使用了logback这个日志系统

我们的系统使用了A.jar，A.jar中使用的日志系统为log4j

我们的系统又使用了B.jar，B.jar中使用的日志系统为slf4j-simple

这样，我们的系统就不得不同时支持并维护logback、log4j、slf4j-simple三种日志框架，非常不便。

解决这个问题的方式就是引入一个适配层，由适配层决定使用哪一种日志系统，而调用端只需要做的事情就是打印日志而不需要关心如何打印日志，slf4j或者commons-logging就是这种适配层。

从上面的描述，我们清楚地知道一点：slf4j只是一个日志标准，并不是日志系统的具体实现。

理解这句话非常重要，slf4j只做两件事情：

• 提供日志接口
• 提供获取具体日志对象的方法

slf4j-simple、logback-classic都是slf4j的具体实现，log4j并不直接实现slf4j，但是有专门的一层桥接slf4j-log4j12来实现slf4j。

slf4j实现原理

slf4j的用法就是一句"Logger logger = LoggerFactory.getLogger(Object.class);"

可见这里就是通过LoggerFactory去拿slf4j提供的一个Logger接口的具体实现而已。getLogger的时候会去classpath下找STATIC_LOGGER_BINDER_PATH，即所有slf4j的实现，在提供的jar包路径下，一定是有"org/slf4j/impl/StaticLoggerBinder.class"存在的。

    private static String STATIC_LOGGER_BINDER_PATH = "org/slf4j/impl/StaticLoggerBinder.class";

    private static Set<URL> findPossibleStaticLoggerBinderPathSet() {
        // use Set instead of list in order to deal with bug #138
        // LinkedHashSet appropriate here because it preserves insertion order during iteration
        Set<URL> staticLoggerBinderPathSet = new LinkedHashSet<URL>();
        try {
            ClassLoader loggerFactoryClassLoader = LoggerFactory.class.getClassLoader();
            Enumeration<URL> paths;
            if (loggerFactoryClassLoader == null) {
                paths = ClassLoader.getSystemResources(STATIC_LOGGER_BINDER_PATH);
            } else {
                paths = loggerFactoryClassLoader.getResources(STATIC_LOGGER_BINDER_PATH);
            }
            while (paths.hasMoreElements()) {
                URL path = paths.nextElement();
                staticLoggerBinderPathSet.add(path);
            }
        } catch (IOException ioe) {
            Util.report("Error getting resources from path", ioe);
        }
        return staticLoggerBinderPathSet;
    }

我们不能避免在系统中同时引入多个slf4j的实现，所以接收的地方是一个Set。

同时存在多个"org/slf4j/impl/StaticLoggerBinder.class"怎么办？

首先确定的是这不会导致启动报错只会打印warnning，其次在这种情况下编译期间，编译器会选择其中一个StaticLoggerBinder.class进行绑定，sfl4j也在reportActualBinding方法中报告了绑定的是哪个日志框架。

StaticLoggerBinder就比较简单了，不同的StaticLoggerBinder其getLoggerFactory实现不同，拿到ILoggerFactory之后调用一下getLogger即拿到了具体的Logger，可以使用Logger进行日志输出。

logback详解

logback有以下的一些优点：

• 内核重写、测试充分、初始化内存加载更小
• logback有比较齐全的200多页的文档
• logback当配置文件修改了，支持自动重新加载配置文件，扫描过程快且安全，它并不需要另外创建一个扫描线程
• 支持自动去除旧的日志文件，可以控制已经产生日志文件的最大数量

logback加载

当使用logback-classic.jar时，应用启动时logback会按照如下顺序进行扫描：

• 在系统配置文件System Properties中寻找是否有logback.configurationFile对应的value
• 在classpath下寻找是否有logback.groovy（即logback支持groovy与xml两种配置方式）
• 在classpath下寻找是否有logback-test.xml
• 在classpath下寻找是否有logback.xml

以上任何一项找到了就不进行后续扫描，按照对应的配置进行logback的初始化，具体代码实现可见ch.qos.logback.classic.util.ContextInitializer类的findURLOfDefaultConfigurationFile方法。

当所有以上四项都找不到的情况下，logback会调用ch.qos.logback.classic.BasicConfigurator的configure方法构造一个ConsoleAppender用于向控制台输出日志。

configuration

<configuration>只有三个属性：

• scan：当scan被设置为true时，当配置文件发生改变，将会被重新加载，默认为true
• scanPeriod：检测配置文件是否有修改的时间间隔，如果没有给出时间单位，默认为毫秒，当scan=true时这个值生效，默认时间间隔为1分钟
• debug：当被设置为true时，将打印出logback内部日志信息，实时查看logback运行信息，默认为false

logger与root

<logger>用来设置某一个包或者具体某一个类的日志打印级别以及指定<appender>。

<logger>可以包含零个或者多个<appender-ref>元素，没有配置<appender-ref>，表示此<logger>不会打印出任何信息。此时看additivity配置是否向上级传递打印。

<logger>仅有一个name属性、一个可选的level属性和一个可选的additivity属性：

• name：用来指定受此logger约束的某一个包或者具体的某一个类
• level：用来设置打印级别，五个常用打印级别从低至高依次为TRACE、DEBUG、INFO、WARN、ERROR，如果未设置此级别，那么当前logger会继承上级的级别
• additivity：是否向上级logger传递打印信息，默认为true

<root>也是<logger>元素，但是它是根logger，只有一个level属性，因为它的name就是ROOT，源码在LoggerContext中：

final public String ROOT_LOGGER_NAME = "ROOT"
public LoggerContext() {
    super();
    this.loggerCache = new ConcurrentHashMap<String, Logger>();

    this.loggerContextRemoteView = new LoggerContextVO(this);
    this.root = new Logger(Logger.ROOT_LOGGER_NAME, null, this);
    this.root.setLevel(Level.DEBUG);
    loggerCache.put(Logger.ROOT_LOGGER_NAME, root);
    initEvaluatorMap();
    size = 1;
    this.frameworkPackages = new ArrayList<String>();
}

ps：

这个name表示的是LoggerFactory.getLogger(XXX.class)，XXX的包路径，包路径越少越是父级。

譬如：Logger logger = LoggerFactory.getLogger(Object.class);  name="java"是name="java.lang"的父级，root是所有<logger>的父级。

<?xml version="1.0" encoding="UTF-8" ?>
<configuration scan="false" scanPeriod="60000" debug="false">

    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <layout class="ch.qos.logback.classic.PatternLayout">
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</pattern>
        </layout>
    </appender>

    <logger name="java" additivity="false" /> 没有appender-ref 此logger不打印并且不往上传递
    <logger name="java.lang" level="warn">  打印warn以上的日志  向上name为java的传递
        <appender-ref ref="STDOUT" />
    </logger>

    <root level="debug">
        <appender-ref ref="STDOUT" />
    </root>

</configuration>

appender

<appender>是<configuration>的子节点，是负责写日志的组件。

<appender>有两个必要属性name和class：

• name指定<appender>的名称
• class指定<appender>的全限定名

<appender>有好几种：

ConsoleAppender，ConsoleAppender的作用是将日志输出到控制台。

<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"><encoder><pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</pattern></encoder></appender>

其中，encoder表示对参数进行格式化。上面使用了<layout>定义<pattern>，这里使用了<encoder>定义<pattern>。

• <encoder>是0.9.19版本之后引进的，以前的版本使用<layout>，logback极力推荐的是使用<encoder>而不是<layout>
• 最常用的FileAppender和它的子类的期望是使用<encoder>而不再使用<layout>

FileAppender，将日志写到文件中。

<appender name="FILE" class="ch.qos.logback.core.FileAppender">
    <file>D:/123.log</file>
    <append>true</append>
    <encoder>
        <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>
    </encoder>
</appender>

• <file>表示写入的文件名，可以使相对目录也可以是绝对目录，如果上级目录不存在则自动创建
• <append>如果为true表示日志被追加到文件结尾，如果是false表示清空文件
• <encoder>表示输出格式

RollingFileAppender，滚动记录文件，先将日志记录到指定文件，当符合某个条件时再将日志记录到其他文件。

<appender name="ROLLING-FILE-1" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <fileNamePattern>rolling-file-%d{yyyy-MM-dd}.log</fileNamePattern>
        <maxHistory>6</maxHistory>
    </rollingPolicy>
    <encoder>
        <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>
    </encoder>
</appender>

<rollingPolicy>的作用是当发生滚动时，定义RollingFileAppender的行为，TimeBasedRollingPolicy是最常用的滚动策略，它根据时间指定滚动策略，既负责滚动也负责触发滚动，有以下节点：

• <fileNamePattern>，必要节点，包含文件名及"%d"转换符，"%d"可以包含一个Java.text.SimpleDateFormat指定的时间格式，如%d{yyyy-MM}，如果直接使用%d那么格式为yyyy-MM-dd。
• <maxHistory>，可选节点，控制保留的归档文件的最大时限，如果超出数量就删除旧文件，假设设置每个月滚动且<maxHistory>是6，则只保存最近6个月的文件

异步写日志

日志通常来说都以文件形式记录到磁盘，例如使用<RollingFileAppender>，这样的话一次写日志就会发生一次磁盘IO，这对于性能是一种损耗，因此更多的对于每次请求必打的日志，我们会采取异步写日志的方式而不让此次写日志发生磁盘IO，阻塞线程从而造成不必要的性能损耗。

<?xml version="1.0" encoding="UTF-8" ?>
<configuration scan="false" scanPeriod="60000" debug="false">

    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</pattern>
        </encoder>
    </appender>

    <appender name="ROLLING-FILE-1" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
              <fileNamePattern>D:/rolling-file-%d{yyyy-MM-dd}.log</fileNamePattern>
              <maxHistory>30</maxHistory>
        </rollingPolicy>
        <encoder>
              <pattern>%-4relative [%thread] %-5level %lo{35} - %msg%n</pattern>
        </encoder>
    </appender>

    <!-- 异步输出 -->
    <appender name ="ASYNC" class= "ch.qos.logback.classic.AsyncAppender">
        <!-- 不丢失日志.默认的,如果队列的80%已满,则会丢弃TRACT、DEBUG、INFO级别的日志 -->
        <discardingThreshold>0</discardingThreshold>
        <!-- 更改默认的队列的深度,该值会影响性能.默认值为256 -->
        <queueSize>256</queueSize>
        <!-- 添加附加的appender,最多只能添加一个 -->
        <appender-ref ref ="ROLLING-FILE-1"/>
    </appender>

    <logger name="java" additivity="false" />
    <logger name="java.lang" level="DEBUG">
        <appender-ref ref="ASYNC" />
    </logger>

    <root level="INFO">
        <appender-ref ref="STDOUT" />
    </root>

</configuration>

当我们配置了AsyncAppender，系统启动时会初始化一条名为"AsyncAppender-Worker-ASYNC"的线程。

当Logging Event进入AsyncAppender后，AsyncAppender会调用appender方法，appender方法中再将event填入Buffer（使用的Buffer为BlockingQueue，具体实现为ArrayBlockingQueye）前，会先判断当前Buffer的容量以及丢弃日志特性是否开启。当消费能力不如生产能力时，AsyncAppender会将超出Buffer容量的Logging Event的级别进行丢弃，作为消费速度一旦跟不上生产速度导致Buffer溢出处理的一种方式。

"AsyncAppender-Worker-ASYNC"的线程的作用，就是从Buffer中取出Event，交给对应的appender进行后面的日志推送。

AsyncAppender并不处理日志，只是将日志缓冲到一个BlockingQueue里面去，并在内部创建一个工作线程从队列头部获取日志，之后将获取的日志循环记录到附加的其他appender上去，从而达到不阻塞主线程的效果。因此AsyncAppender仅仅充当的是事件转发器，必须引用另外一个appender来做事。

• discardingThreshold，假如等于20则表示，表示当还剩20%容量时，将丢弃TRACE、DEBUG、INFO级别的Event，只保留WARN与ERROR级别的Event，为了保留所有的events，可以将这个值设置为0，默认值为queueSize/5
• queueSize，BlockingQueue的最大容量，默认为256
• includeCallerData表示是否提取调用者数据，这个值被设置为true的代价是相当昂贵的，为了提升性能，默认当event被加入BlockingQueue时，event关联的调用者数据不会被提取，只有线程名这些比较简单的数据
• appender-ref表示AsyncAppender使用哪个具体的<appender>进行日志输出

encoder

<encoder>节点负责两件事情：

• 把日志信息转换为字节数组
• 把字节数组写到输出流

目前PatternLayoutEncoder是唯一有用的且默认的encoder，有一个<pattern>节点，用来设置日志的输入格式，使用“%+转换符"的方式，如果要输出"%"则必须使用"\%"对"%"进行转义。

转换符	作  用	是否避免使用
c{length} lo{length} logger{length}	输出日志的logger名称，可有一个整型参数来缩短<logger>名称，有几种情况： 1、不输入表示输出完整的<logger>名称 2、输入0表示只输出<logger>最右边点号之后的字符串 3、输入其他数字表示输出小数点最后边点号之前的字符数量	否
C{length} class{length}	输出指定记录的请求的调用者的全限定名，length同上	是
d{pattern} date{pattern}	输出时间格式，模式语法同java.text.SimpleDateFormat兼容	否
caller{depth}	输出生成日志的调用者的位置信息，整数选项表示输出信息深度	否
L	输出执行日志的请求行号	是
m msg message	输出应用程序提供的信息	否
m	输入执行日志请求的方法名	是
n	输出平台相关的分行符"\n"或者"\r\n"，即换行	否
p le level	输出日志级别	否
r relative	输出从程序启动到创建日志记录的时间，单位为毫秒	否
t thread	输出产生日志的线程名称	否

最后一列是"是否避免使用"，因为这些信息是无法直接拿到的（比如请求行号、调用方法名），logback必须通过一些特殊手段去获取这些数据（比如在日志打印出产生一个堆栈信息），这种操作会比较影响效率，因此除非必要，否则不建议打印这些数据。

Filter

<filter>是<appender>的一个子节点，表示在当前给到的日志级别下再进行一次过滤。

最基本的Filter有ch.qos.logback.classic.filter.LevelFilter和ch.qos.logback.classic.filter.ThresholdFilter

    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</pattern>
        </encoder>
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <level>WARN</level>
            <onMatch>ACCEPT</onMatch>
            <onMismatch>DENY</onMismatch>
        </filter>
    </appender>

    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</pattern>
        </encoder>
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>INFO</level>
        </filter>
    </appender>

LevelFilter对匹配到WARN级别时做了ACCEPT（接受），对未匹配到WARN级别时做了DENY（拒绝），因此只能打印出WARN级别的日志。

ThresholdFilter的策略是会将日志级别小于<level>的全部进行过滤，因此只有INFO及以上级别的才能被打印出来。