java日志详解及最佳实践

一、日志框架的分类

1.1、门面型日志框架：

1. JCL：Apache基金会所属的项目，是一套Java日志接口，之前叫Jakarta Commons Logging，后更名为Commons Logging
2. SLF4J：是一套简易Java日志门面，本身并无日志的实现。（Simple Logging Facade for Java，缩写Slf4j）

1.2、记录型日志框架:

1. JUL：JDK中的日志记录工具，也常称为JDKLog、jdk-logging，自Java1.4以来的官方日志实现。
2. Log4j：一个具体的日志实现框架。
3. Log4j2： 一个具体的日志实现框架，是LOG4J1的下一个版本，与Log4j 1发生了很大的变化，Log4j 2不兼容Log4j 1。
4. Logback：一个具体的日志实现框架，和Slf4j是同一个作者，但其性能更好（推荐使用）。

二、发展历程

要搞清楚它们的关系，就要从它们是在什么情况下产生的说起。我们按照时间的先后顺序来介绍。

Log4j：在JDK 1.3及以前，Java打日志依赖System.out.println(), System.err.println()或者e.printStackTrace()，Debug日志被写到STDOUT流，错误日志被写到STDERR流。这样打日志有一个非常大的缺陷，即无法定制化，且日志粒度不够细。
于是， Gülcü 于2001年发布了Log4j，后来成为Apache 基金会的顶级项目。Log4j 在设计上非常优秀，对后续的 Java Log 框架有长久而深远的影响，它定义的Logger、Appender、Level等概念如今已经被广泛使用。Log4j 的短板在于性能，在Logback 和 Log4j2 出来之后，Log4j的使用也减少了。

J.U.L：受Logj启发，Sun在Java1.4版本中引入了java.util.logging，但是j.u.l功能远不如log4j完善，开发者需要自己编写Appenders（Sun称之为Handlers），且只有两个Handlers可用（Console和File），j.u.l在Java1.5以后性能和可用性才有所提升。

JCL（commons-logging）：由于项目的日志打印必然选择两个框架中至少一个，这时候，Apache的JCL（commons-logging）诞生了。JCL 是一个Log Facade，只提供 Log API，不提供实现，然后有 Adapter 来使用 Log4j 或者 JUL 作为Log Implementation。
在程序中日志创建和记录都是用JCL中的接口，在真正运行时，会看当前ClassPath中有什么实现，如果有Log4j 就是用 Log4j, 如果啥都没有就是用 JDK 的 JUL。
这样，在你的项目中，还有第三方的项目中，大家记录日志都使用 JCL 的接口，然后最终运行程序时，可以按照自己的需求(或者喜好)来选择使用合适的Log Implementation。如果用Log4j, 就添加 Log4j 的jar包进去，然后写一个 Log4j 的配置文件；如果喜欢用JUL，就只需要写个 JUL 的配置文件。如果有其他的新的日志库出现，也只需要它提供一个Adapter，运行的时候把这个日志库的 jar 包加进去。
不过，commons-logging对Log4j和j.u.l的配置问题兼容的并不好，使用commons-loggings还可能会遇到类加载问题，导致NoClassDefFoundError的错误出现。到这个时候一切看起来都很简单，很美好。接口和实现做了良好的分离，在统一的JCL之下，不改变任何代码，就可以通过配置就换用功能更强大，或者性能更好的日志库实现。

SLF4J & Logback：SLF4J（Simple Logging Facade for Java）和 Logback 也是Gülcü 创立的项目，目的是为了提供更高性能的实现。从设计模式的角度说，SLF4J 是用来在log和代码层之间起到门面作用，类似于 JCL 的 Log Facade。对于用户来说只要使用SLF4J提供的接口，即可隐藏日志的具体实现，SLF4J提供的核心API是一些接口和一个LoggerFactory的工厂类，用户只需按照它提供的统一纪录日志接口，最终日志的格式、纪录级别、输出方式等可通过具体日志系统的配置来实现，因此可以灵活的切换日志系统。

三、详细介绍

Java日志体系（二）log4j

Java日志体系（三）commons-logging

Java日志体系（四）slf4j

Java日志体系（五）logback

Java日志体系（六）log4j2

Java日志体系（七）日志框架切换

Java日志框架性能比较

四、最佳实践

推荐使用 SLF4J + Logback。maven依赖如下，其中version字段用占位符代替，你应该根据项目的实际情况选择合适的版本：

<!--  =================================================  -->
<!--  日志及相关依赖（用slf4j+logback代替jcl+log4j）  -->
<!--  =================================================  -->
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>${version}</version>
</dependency>
<!-- 强制使用 logback的绑定 -->
<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-core</artifactId>
    <version>${version}</version>
</dependency>
<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>${version}</version>
</dependency>
<!-- 强制使用 logback的绑定,这里去除对log4j 的绑定 -->
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-log4j12</artifactId>
    <version>99.0-does-not-exist</version>
</dependency>
<!-- slf4j 的桥接器,将第三方类库对 log4j 的调用 delegate 到 slf api 上 -->
<!-- 这个桥接器是自己做的,主要是我们依赖的类库存在很多硬编码的引用 -->
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>log4j-over-slf4j</artifactId>
    <version>${version}</version>
</dependency>
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>jcl-over-slf4j</artifactId>
    <version>${version}</version>
</dependency>
<!-- 强制排除 log4j 的依赖,全部 delegate 到 log4j-over-slf4j 上 -->
<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>99.0-does-not-exist</version>
</dependency>
<dependency>
    <groupId>apache-log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>999-not-exist</version>
</dependency>
<!-- slf4j + logback 配置结束 -->

再提几点最佳实践：

1. 总是使用 Log Facade，而不是具体的 Log Implementation
2. 只添加一个 Log Implementation 依赖
3. 具体的日志依赖应该设置为 optional，并使用 runtime scope
   设为optional，依赖不会传递，这样如果你是个lib项目，然后别的项目使用了你这个lib，不会被引入不想要的Log Implementation 依赖；
   Scope设置为runtime，是为了防止开发人员在项目中直接使用Log Implementation中的类，而不使用Log Facade中的类。
4. 如果有必要, 排除依赖的第三方库中的Log Impementation依赖
   这是很常见的一个问题，第三方库的开发者未必会把具体的日志实现或者桥接器的依赖设置为optional，然后你的项目继承了这些依赖——具体的日志实现未必是你想使用的，比如他依赖了Log4j，你想使用Logback，这时就很尴尬。另外，如果不同的第三方依赖使用了不同的桥接器和Log实现，也极容易形成环。
   这种情况下，推荐的处理方法，是使用exclude来排除所有的这些Log实现和桥接器的依赖，只保留第三方库里面对Log Facade的依赖。

 

logback最佳实践

1 简介

logback是由log4jCeki Gülcü开发的开源日志组件，可以说是log4j的改进版；在现如今的项目中，logback的出现次数越来越多，是目前主流首选的日志记录工具。

logback大约有以下的一些优点：

• 内核重写、测试充分、初始化内存加载更小，这一切让logback性能和log4j相比有诸多倍的提升
• logback非常自然地直接实现了slf4j，这个严格来说算不上优点，只是这样，再理解slf4j的前提下会很容易理解logback，也同时很容易用其他日志框架替换logback
• logback有比较齐全的200多页的文档
• logback当配置文件修改了，支持自动重新加载配置文件，扫描过程快且安全，它并不需要另外创建一个扫描线程
• 支持自动去除旧的日志文件，可以控制已经产生日志文件的最大数量

2 结构

logback分成三个模块：logback-core，logback- classic，logback-access。

logback-core提供了logBack的核心功能，是另外两个组件的基础；

logback-classic模块实现了SLF4J API；

logback-access模块与Servlet容器集成提供Http来访问日志的功能。

3 依赖

首先要使用logback，maven项目中需要在pom.xml中添加依赖

<!--slf4j -->
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>1.7.20</version>
</dependency>

<!-- logback -->
<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>1.1.7</version>
</dependency>
<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-core</artifactId>
    <version>1.1.7</version>
</dependency>
<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-access</artifactId>
    <version>1.1.7</version>
</dependency>

使用如测试代码：

import org.junit.Test;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class slf4j_logbackDemo {
    Logger logger=  LoggerFactory.getLogger(slf4j_logbackDemo.class);

    @Test
    public void test() {
        logger.debug("debug message");
        logger.info("info message");
        logger.warn("warning message");
        logger.error("error message");
        logger.warn("login message");
    }
}

在classpath下声明配置文件：logback.xml;

<!--每天生成一个文件，归档文件保存30天：-->
<configuration >

    <!--设置自定义pattern属性-->
    <property name="pattern" value="%d{HH:mm:ss.SSS} [%-5level] [%thread] [%logger] %msg%n"/>

    <!--控制台输出日志-->
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <!--设置控制台输出日志的格式-->
        <encoder>
            <pattern>${pattern}</pattern>
        </encoder>
    </appender>

    <!--滚动记录日志文件：-->
    <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!--当天生成的日志文件名称：-->
        <file>e:/log.out</file>
        <!--根据时间来记录日志文件：-->
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <!--归档日志文件的名称：-->
            <fileNamePattern>testLog-%d{yyyy-MM-dd}.log</fileNamePattern>
            <!--归档文件保存30天-->
            <maxHistory>30</maxHistory>
        </rollingPolicy>
        <!--生成的日志信息格式-->
        <encoder>
            <pattern>${pattern}</pattern>
        </encoder>
    </appender>

    <!--根root logger-->
    <root level="DEBUG">
        <!--设置根logger的日志输出目的地-->
        <appender-ref ref="FILE" />
        <appender-ref ref="CONSOLE" />
    </root>

</configuration>

通过以上步骤，logback就可以正常的运行了。

4 加载

我们简单分析一下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用于向控制台输出日志，默认日志输出格式为”%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} – %msg%n”的 PatternLayoutEncoder 进行格式化。root logger 默认级别是 DEBUG。

5 配置文件

5.1 configuration

配置根节点

 

<configuration scan="true" scanPeriod="60" debug="false">
</configuration>  

• scan：程序运行时配置文件被修改，是否重新加载。true，重新加载；false,不重新加载；默认为true;

• scanPeriod：监测配置文件被修改的时间间隔，scan属性必须设置为true才可生效；默认为1分钟，默认单位是毫秒；

• debug：是否打印logback程序运行的日志信息。true,打印；false,不打印；默认为false;

5.2 contextName

上下文名称子节点

<configuration scan="true" scanPeriod="60 seconds" debug="false"> 
     <contextName>myAppName</contextName> 
　　  <!--其他配置省略-->
</configuration>    

每个logger都关联到logger上下文，默认上下文名称为default。但可以使用contextName设置成其他名字，用于区分不同应用程序的记录。一旦设置，不能修改。

5.3 property

属性变量

<configuration scan="true" scanPeriod="60" debug="false">
    <property name="pattern" value="%d{HH:mm:ss.SSS} [%-5level] [%logger] %msg%n" ></property>
</configuration>  

• name：变量的名称，可以随意起名，但建议名字要简明直译；

• value：变量的值；

在配置文件中，我们可以用 ${} 的方式来使用，将变量引入到其他节点中去。如果有多处使用相同的内容，便可使用属性变量的方式进行统一，减少很多不必要的代码；

5.4 timestamp

时间戳

<configuration scan="true" scanPeriod="60 seconds" debug="false"> 
　　<timestamp key="bySecond" datePattern="yyyyMMdd'T'HHmmss"/> 
　　<contextName>${bySecond}</contextName> 
　　<!-- 其他配置省略--> 
</configuration>

获取时间戳字符串，他有两个属性key和datePattern

• key：标识此 的名字；

• datePattern：设置将当前时间（解析配置文件的时间）转换为字符串的模式，遵循java.txt.SimpleDateFormat的格式。

5.5 logger(logger)

日志对象

logger分为2种，一种是普通日志对象，另一种是根日志对象。对于大部分应用来说，只设置根日志对象即可。
在java日志系统中，无论是log4j还是logback，他们的日志对象体系都是呈现“树”的形式，根日志对象为最顶层节点，其余包或者类中的日志对象都继承于根日志节点；

对于普通日志对象来说，我们可以设置某一个包或者某一个类的日志级别，还可以单独设置日志的输出目的地；

<configuration scan="true" scanPeriod="60" debug="false">   
    <logger name="java.sql" level="debug" addtivity="true">
        <appender-ref ref="CONSOLE" />
    </logger>   
</configuration>  

• name：用来指定此logger属于哪个包或者哪个类；

• level：用来指定此logger的日志打印级别；

• addtivity：是否向上传递日志打印信息。之前说了，logger对象呈现一个树的结构，根logger是树的顶端，下面的子logger的addtivity属性如果设置为true则会向上传递打印信息，出现日志重复打印的现象；

• appender-ref：日志输出目的地，将此logger所打印的日志交给此appender；

值得注意的是，上面的例子中，如果此logger没有指定appender，而且addtivity也设置为true，那么此logger对应的日志信息只会打印一遍，是由root来完成的；但是如果addtivity设置成false，那么此logger将不会输出任何日志信息；

5.6 logger(root)

根日志对象

也是日志对象中的一种，但它位于logger体系中的最顶层。当一个类中的logger对象进行打印请求时，如果配置文件中没有为该类单独指定日志对象，那么都会交给root根日志对象来完成；

节点中只有一个level属性，还可以单独指定日志输除目的地;

<configuration scan="true" scanPeriod="60" debug="false">   
    <root level="DEBUG">
        <appender-ref ref="CONSOLE" />
    </root>
</configuration>  

5.7 appender

日志输出目的地

 

与log4j中的appender一样，logback中的<appender>节点也同样负责日志输出的目的地。

appender中有2个必填属性–name和class。name为<appender>节点的名称，class为<appender>的全限定类名，也就是日志输出目的地的处理类。此外，我们还可以在<appender>中单独指定日志的格式，设置日志过滤器等操作；

<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">  
    <encoder>  
        <pattern>%-4relative [%thread] %-5level %logger{35} - %msg %n</pattern>  
    </encoder>  
</appender>  

在logback中，主要有以下三种日志目的地处理类：

(1) ConsoleAppender

ch.qos.logback.core.ConsoleAppender

将日志输出到控制台，可以在其节点中设置子节点，设置日志输出的格式；

<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">  
    <encoder>  
        <pattern>%-4relative [%thread] %-5level %logger{35} - %msg %n</pattern>  
    </encoder>  
</appender>  

其中，encoder表示对参数进行格式化。我们和上一部分的例子对比一下，发现这里是有所区别的，上面使用了定义，这里使用了定义，简单说一下：

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

(2) FileAppender

ch.qos.logback.core.FileAppender

将日志输出到具体的磁盘文件中，可以单独指定具体的位置，也可以设置日志的输出格式；

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

• ：表示写入的文件名，可以使相对目录也可以是绝对目录，如果上级目录不存在则自动创建
• ：如果为true表示日志被追加到文件结尾，如果是false表示清空文件
• ：表示输出格式，后面说
• ：如果为true表示日志会被安全地写入文件，即使其他的FileAppender也在向此文件做写入操作，效率低，默认为false

(3) RollingFileAppender

ch.qos.logback.core.rolling.RollingFileAppender

滚动记录日志，当符合节点中设置的条件时，会将现有日志移到新的文件中去。节点中可设置的条件为：文件的大小、时间等；

<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>e:/log.out</file>
    <append>true</append>  
    <prudent>false</prudent>
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <fileNamePattern>testLog-%d{yyyy-MM-dd}.log</fileNamePattern>
        <maxHistory>30</maxHistory>
    </rollingPolicy>
    <encoder>
        <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>
    </encoder>
</appender>

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

(4) AsyncAppender

ch.qos.logback.classic.AsyncAppender

异步记录日志，内部通过使用缓存的方式来实现异步打印，将日志打印事件event放入缓存中。具体数据结构为BlockingQueue；

<appender name="FILE" class="ch.qos.logback.core.FileAppender">  
    <file>e:/log.out</file>  
    <append>true</append>  
    <prudent>false</prudent>
    <encoder>  
        <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>  
    </encoder>  
</appender> 
<appender name ="ASYNC" class= "ch.qos.logback.classic.AsyncAppender">  
    <discardingThreshold>0</discardingThreshold>  
    <queueSize>512</queueSize>  
    <appender-ref ref ="FILE"/>  
</appender>  

• ：指的是BlockingQueue的队列容量大小，默认为256个；
• ：如果BlockingQueue中还剩余20%的容量，那么程序会丢弃TRACE、DEBUG和INFO级别的日志打印事件event，只保留WARN和ERROR级别的。为了保留所有的日志打印事件，可以将该值设置为0。

5.8 rollingPolicy

日志文件的滚动策略，与RollingFileAppender搭配使用，当日志文件发生变动时决定RollingFileAppender的行为；

在节点中有一个class属性，可选的值为TimeBasedRollingPolicy、FixedWindowRollingPolicy、TriggeringPolicy；

其中ch.qos.logback.core.rolling.TimeBasedRollingPolicy表示根据时间制定日志文件的滚动策略；

<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
    <fileNamePattern>testLog-%d{yyyy-MM-dd}.log</fileNamePattern>
    <maxHistory>30</maxHistory>
</rollingPolicy>

ch.qos.logback.core.rolling.FixedWindowRollingPolicy表示如果日志文件大小超过指定范围时，会根据文件名拆分成多个文件；

<rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">   
   <fileNamePattern>tests.%i.log.zip</fileNamePattern>   
   <minIndex>1</minIndex>   
   <maxIndex>3</maxIndex>   
 </rollingPolicy>   

5.9 triggeringPolicy

与节点一样，节点也属于日志滚动策略中的一种。

ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy表示根据日志文件大小，超过制定大小会触发日志滚动；

 <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">   
   <maxFileSize>5MB</maxFileSize>   
 </triggeringPolicy> 

5.10 encoder

日志格式化节点，负责格式化日志信息。只负责了两件事情，

• 负责将日志信息转换成字节数组
• 将字节数组写到输出流当中去

目前PatternLayoutEncoder是唯一有用的且默认的encoder，有一个节点，就像上面演示的，用来设置日志的输入格式，使用“%+转换符”的方式，如果要输出”%”则必须使用”%”对”%”进行转义。

在中使用来设置对应的格式；

<encoder>   
    <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>   
</encoder  

的一些可用参数用表格表示一下：

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

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

5.11 filter

最后来看一下，是的一个子节点，表示在当前给到的日志级别下再进行一次过滤，最基本的Filter有ch.qos.logback.classic.filter.LevelFilter和ch.qos.logback.classic.filter.ThresholdFilter，首先看一下LevelFilter：

<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>
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <level>WARN</level>
            <onMatch>ACCEPT</onMatch>
            <onMismatch>DENY</onMismatch>
        </filter>
    </appender>
     
    <logger name="java" additivity="false" />
    <logger name="java.lang" level="DEBUG">
        <appender-ref ref="STDOUT" />
    </logger>
     
    <root level="INFO">
        <appender-ref ref="STDOUT" />
    </root>
     
</configuration>

看一下输出：

2018-03-31 22:22:58.843 [main] WARN  java.lang.Object - =====warn=====

看到尽管配置的是DEBUG，但是输出的只有warn，因为在中对匹配到WARN级别时做了ACCEPT（接受），对未匹配到WARN级别时做了DENY（拒绝），当然只能打印出WARN级别的日志。

再看一下ThresholdFilter，配置为：

<?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>
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>INFO</level>
        </filter>
    </appender>
     
    <logger name="java" additivity="false" />
    <logger name="java.lang" level="DEBUG">
        <appender-ref ref="STDOUT" />
    </logger>
     
    <root level="INFO">
        <appender-ref ref="STDOUT" />
    </root>
     
</configuration>

看一下输出为：

2018-03-31 22:41:32.353 [main] INFO  java.lang.Object - =====info=====
2018-03-31 22:41:32.358 [main] WARN  java.lang.Object - =====warn=====
2018-03-31 22:41:32.359 [main] ERROR java.lang.Object - =====error=====

因为ThresholdFilter的策略是，会将日志级别小于的全部进行过滤，因此虽然指定了DEBUG级别，但是只有INFO及以上级别的才能被打印出来。

6 其他

logger与root

先从最基本的与开始。

用来设置某一个包或者具体某一个类的日志打印级别、以及指定。可以包含零个或者多个元素，标识这个appender将会添加到这个logger。仅有一个name属性、一个可选的level属性和一个可选的additivity属性：

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

也是元素，但是它是根logger，只有一个level属性，因为它的name就是ROOT，关于这个地方，有朋友微信上问起，源码在LoggerContext中：

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>();
}

Logger的构造函数为：

Logger(String name, Logger parent, LoggerContext loggerContext) {
    this.name = name;
    this.parent = parent;
    this.loggerContext = loggerContext;
}

看到第一个参数就是Root的name，而这个Logger.ROOT_LOGGER_NAME的定义为final public String ROOT_LOGGER_NAME = “ROOT”，由此可以看出节点的name就是”ROOT”。

接着写一段代码来测试一下：

public class Slf4jTest {
 
    @Test
    public void testSlf4j() {
        Logger logger = LoggerFactory.getLogger(Object.class);
        logger.trace("=====trace=====");  
        logger.debug("=====debug=====");  
        logger.info("=====info=====");  
        logger.warn("=====warn=====");  
        logger.error("=====error=====");  
    }
     
}

logback.xml的配置为：

<?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>
     
    <root level="info">
        <appender-ref ref="STDOUT" />
    </root>
     
</configuration>

root将打印级别设置为”info”级别，暂时不管，控制台的输出为：

2018-03-26 22:57:48.779 [main] INFO  java.lang.Object - =====info=====
2018-03-26 22:57:48.782 [main] WARN  java.lang.Object - =====warn=====
2018-03-26 22:57:48.782 [main] ERROR java.lang.Object - =====error=====

logback.xml的意思是，当Test方法运行时，root节点将日志级别大于等于info的交给已经配置好的名为”STDOUT”的进行处理，”STDOUT”将信息打印到控制台上。

接着理解一下节点的作用，logback.xml修改一下，加入一个只有name属性的：

<?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" />
       
     <root level="debug">
         <appender-ref ref="STDOUT" />
     </root>
       
</configuration>

注意这个name表示的是LoggerFactory.getLogger(XXX.class)，XXX的包路径，包路径越少越是父级，我们测试代码里面是Object.class，即name=”java”是name=”java.lang”的父级，root是所有的父级。看一下输出为：

2018-03-27 23:02:02.963 [main] DEBUG java.lang.Object - =====debug=====
2018-03-27 23:02:02.965 [main] INFO  java.lang.Object - =====info=====
2018-03-27 23:02:02.966 [main] WARN  java.lang.Object - =====warn=====
2018-03-27 23:02:02.966 [main] ERROR java.lang.Object - =====error=====

出现这样的结果是因为：

• 中没有配置level，即继承父级的level，的父级为，那么level=debug
• 没有配置additivity，那么additivity=true，表示此的打印信息向父级传递
• 没有配置，表示此不会打印出任何信息

由此可知，的打印信息向传递，使用”STDOUT”这个打印出所有大于等于debug级别的日志。举一反三，我们将的additivity配置为false，那么控制台应该不会打印出任何日志，因为的打印信息不会向父级传递且没有配置任何，大家可以自己试验一下。

接着，我们再配置一个：

<?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" />
    <logger name="java.lang" level="warn">
        <appender-ref ref="STDOUT" />
    </logger>
     
    <root level="debug">
        <appender-ref ref="STDOUT" />
    </root>
      
</configuration>

如果读懂了上面的例子，那么这个例子应当很好理解：

• LoggerFactory.getLogger(Object.class)，首先找到name=”java.lang”这个，将日志级别大于等于warn的使用”STDOUT”这个打印出来
• name=”java.lang”这个没有配置additivity，那么additivity=true，打印信息向上传递，传递给父级name=”java”这个
• name=”java”这个的additivity=false且不关联任何，那么name=”java”这个不会打印任何信息

由此分析，得出最终的打印结果为：

2018-03-27 23:12:16.147 [main] WARN  java.lang.Object - =====warn=====
2018-03-27 23:12:16.150 [main] ERROR java.lang.Object - =====error=====

举一反三，上面的name=”java”这个可以把additivity设置为true试试看是什么结果，如果对前面的分析理解的朋友应该很容易想到，有两部分日志输出，一部分是日志级别大于等于warn的、一部分是日志级别大于等于debug的。

参考资料：

https://blog.csdn.net/lixinkuan328/article/details/104113227

https://blog.csdn.net/Sadlay/article/details/88732271