转载

编程开发（一）：日志框架

日志实现框架

Log4j

Log4j 是目前最为流行的 Java日志框架 之一， 1999年 发布首个版本， 2012年 发布最后一个版本， 2015年 正式宣布终止，官方也已不建议使用，并逐步被 Logback 和 Log4j2 等日志框架所替代，可是无法掩饰光辉历程，以及优良的设计理念。尽管 Log4j 有着出色的历史战绩，但早已不是 Java 日志框架的最优选择，还在使用该日志框架的项目往往是历史遗留问题。

Log4j API 核心类：

日志对象： org.apache.log4j.Logger
日志级别： org.apache.log4j.Level
日志管理器： org.apache.log4j.LogManager
日志仓储： org.apache.log4j.spi.LoggerRepository
日志附加器： org.apache.log4j.Appender
日志过滤器： org.apache.log4j.spi.Filter
日志格式布局： org.apache.log4j.Layout
日志事件： org.apache.log4j.LoggingEvent
日志配置器： org.apache.log4j.spi.Configurator
日志诊断上下文： org.apache.log4j.NDC 、 org.apache.log4j.MDC

JUL

Java Logging 是 Java 标准的日志框架，也称为 Java Logging API ，即 JSR 47 。从 Java 1.4 版本开始， Java Logging 成为 Java SE 的功能模块，其实现类存放在 java.util.logging 包下。

使用 Java Logging 最大好处是它属于 JDK内置 ，不需要添加额外依赖，默认配置文件位于： jre/lib/logging.properties ，具体可以查看 LogManager 类 readConfiguration 方法，启动的时候可以通过设置 VM 参数 java.util.logging.config.file 指定配置文件。

Java Logging API 核心类：

日志对象： java.util.logging.Logger
日志级别： java.util.logging.Level
日志管理器： java.util.logging.LogManager
日志处理器： java.util.logging.Handler
日志过滤器： java.util.logging.Filter
日志格式器： java.util.logging.Formatter
日志记录： java.util.logging.LogRecord
日志权限： java.util.logging.LoggingPermission
日志JMX接口： java.util.logging.LoggingMXBean

Logback

Logback 是 Log4j 创始人设计的又一个开源日志框架，可以看成 Log4j 的替代者，在架构和特征上有着相当提升。 Logback 当前分成三个模块：

logback-core ：其它两个模块的基础模块，提供一些关键的通用机制
```
logback-classic
Log4j
Log4j
SLF4J API
```

logback-access
logback-access
Tomcat
Jetty
Servlet容器
Http
access日志

Logback 核心类：

日志对象： ch.qos.logback.classic.Logger
日志级别： ch.qos.logback.classic.Level
日志管理器： ch.qos.logback.classic.LoggerContext
日志附加器： ch.qos.logback.core.Appender
日志过滤器： ch.qos.logback.core.filter.Filter
日志格式布局： ch.qos.logback.core.Layout
日志事件： ch.qos.logback.classic.spi.LoggingEvent
日志配置器： ch.qos.logback.classic.spi.Configurator

核心架构

上图是 logback 日志框架的输出日志的核心流程：

Logger 作为日志框架的代言人，程序开发通过 Logger 即可完成日志输出工作；

Logger
Filter
Level
LoggingEvent
Appender

```
Appender
Appender
Filter
```

Logger 和 Appender 是日志框架比较核心组件， Logger 代表日志输入源，其配置样例见下：

Appender 代表日志输出源，其配置样例见下：

Logger 和 Appender 相互独立，都可以实现对日志过滤操作，同时可以实现多对多映射关系，在开发中可以对这些特性灵活应用。比如：生产中一个很常见的做法就是构建一个 Level=Error 的 Appender ，然后让所有的 Logger 都指向该 Appender 就可以实现汇聚系统中所有 Error 级别的日志，可以快速监测系统运行是否出现异常状况。

Appender

<appender> 节点被配置时，必须配置两个属性 name 和 class 。 name 指定 Appender 的名称，而 class 指定 Appender 具体的实现类。

Appender核心类结构图：

UnsynchronizedAppenderBase :非线程安全的Appender基类，即 public void doAppend(E eventObject) 没有使用 synchronized 关键字，而 AppenderBase 类中的 doAppend() 方法都使用了 synchronized 关键字： public synchronized void doAppend(E eventObject) 。

Level

日志可以分配级别，包括： ALL 、 TRACE 、 DEBUG 、 INFO 、 WARN 、 ERROR 、 OFF ，其中 ALL 和 OFF 日志级别是用于 Appender 或 Logger 过滤使用。

TRACE(追踪) ：输出更细致的程序运行轨迹；
DEBUG(调试) :这个级别一般记录一些运行中的中间参数信息，只允许在开发环境开启，选择性在测试环境开启；
INFO(信息) ：用来记录程序运行中的一些有用的信息，例如：程序运行开始、结束、耗时、重要参数等信息，需要注意有选择性的有意义的输出，到时候自己找问题看一堆日志却找不到关键日志就没有意义了；
WARN(警告) ：一般用来记录一些用户输入参数错误；
ERROR(错误) ：一般用来记录程序中发生的任何异常错误信息( Throwable )，或者是记录业务逻辑错误；

Logger

通过 LoggerFactory 获取 Logger ： Logger getLogger(String name) ， LoggerFactory 采用工厂设计模式，内部维护一个 Map 缓存所有生成的 Logger 实例信息： Map<String, Logger> loggerCache = new ConcurrentHashMap() 。

继承规则

Logger 是有层次关系的，我们可一般性的理解为包名之间的父子继承关系。每个 Logger 通常以 class全限名称 为其名称。子 Logger 通常会从父 Logger 继承 Logger级别 、 Appender 等信息。

统一日志API

日志框架无论 Log4j 还是 Logback ，虽然它们功能完备，但是各自 API 相互独立，并且各自为政。当应用系统在团队协作开发时，由于工程师人员可能有所偏好，因此，可能导致一套系统同时出现多套日志框架情况。

其次，最流行的日志框架基本上基于实现类编程，而非接口编程，因此，暴露一些无关紧要的细节给用户，这种耦合性是没有必要的。

诸如此类的原因，开源社区提供 统一日志API 框架，最为流行的是：

apache commons-logging
JCL
log4j
java logging

slf4j
log4j
log4j2
java logging
logback

统一日志 API ，即日志门面接口层，直白点讲：提供了操作日志的接口，而具体实现交由 Logback 、 Log4j 等日志实现框架，这样就可以实现程序与具体日志框架间的解耦，对于底层日志框架的改变，并不影响到上层的业务代码，可以灵活切换日志框架。

日志体系

现在日志框架众多： slf4j 、 jcl 、 jul 、 log4j 、 log4j2 、 logback 等，它们之间存在什么样的关系，我们在开发过程中又如何选取这些日志框架呢？

首先，看下Java日志体系：

通过上图可以概括日志体系大致分为三层：日志接口门面层、绑定/桥接层以及日志实现层。

jcl-over-slf4j.jar(jcl -> slf4j):将commons-logging日志桥接到slf4j
jul-to-slf4j.jar(jul -> slf4j):java.util.logging的日志桥接到slf4j

log4j-over-slf4j.jar(log4j -> slf4j):将log4j的日志，桥接到slf4j
slf4j-log4j12.jar(slf4j -> log4j):slf4j绑定到log4j，所以这个包不能和log4j-over-slf4j.jar不能同时使用，会出现死循环

slf4j-jcl.jar(slf4j -> jcl):slf4j绑定到commons-logging日志框架上
slf4j-jdk14.jar(slf4j -> jul):slf4j绑定到jdk日志框架上，不能喝jul-to-slf4j.jar同时使用，会出现死循环

slf4j-nop.jar:slf4j的空接口输出绑定，丢弃所有日志输出
slf4j-simple.jar:slf4j自带的简单日志输出接口
log4j-slf4j-impl.jar(slf4j -> log4j2):将slf4j绑定到log4j2日志框架上，不能和log4j-to-slf4j同时使用
log4j-to-slf4j.jar(log4j2 -> slf4j):将log4j2日志桥接到slf4j上，不能和log4j-slf4j-impl同时使用

最为熟悉和使用率较高的 log4j 其实就位于日志实现层，即其为一种日志实现框架。既然 log4j 已经足够系统使用进行日志输出了，为啥还多此一举弄个 日志接口门面层 和 绑定/桥接层 ？看下图：

系统A 集成了 模块A 、 模块B 、 模块C 三个模块，但是这三个模块使用了不同的日志实现框架，现在 系统A 相当于同时存在了三个日志框架，那如何进行配置呢？每个框架都构建一个配置文件这种肯定是不行的，没法进行统一管理，日志较为混乱。

现在看下如何解决上述问题：

模块A 、 模块B 、 模块C 采用 slf4j 日志接口框架，而非具体日志实现类，具体使用哪种日志实现框架是由 系统A 配置决定的， 系统A 把 slf4j 绑定到 logback ，则统一采用 logback 日志框架， slf4j 绑定到 log4j 则统一采用 log4j 日志框架。 日志接口 --> 日志绑定 --> 日志实现 ，日志接口和日志实现进行了解耦，模块只关注接口不关注实现，具体采用哪种实现是由其所在的系统环境决定，这样就可以实现日志的统一配置和管理。

对于上述解决方案，如果 模块A 、 模块B 、 模块C 是新开发统一采用 slf4j 日志接口框架没问题，但是对于旧系统，比如 模块B 、 模块C 都是很久之前开发的模块，分别采用了不同的日志实现框架，见下图：

如果 系统A 把 slf4j 绑定到 logback 日志框架上，但是 模块B 、 模块C 由于没有采用 slf4j ，绑定对于它们来说是无效的，这时候就要使用 桥接 。

桥接的大致结构如上图，通过桥接把 log4j 、 jdk log 等日志实现框架桥接到 slf4j 上，由于 slf4j 又被绑定到了 logback 上，则 模块B 和 模块C 最终会被 logback 纳管，而不是 log4j 和 jdk log ，同样可以实现日志统一配置管理。

以上就是项目开发中经常遇到的问题，以及绑定和桥接之间的区别。

`spring` 体系中日志框架

Spring框架

Spring Framework 4.X 及之前的版本，都是使用的 标准版JCL 日志框架，该依赖由 spring-core 间接引入。 Spring 框架的日志信息都是使用 JCL 标准接口来进行输出。下面说下项目中常碰到的三种情况：

```
log4j
commons-logging
log4j
jcl
log4j
```

log4j2
commons-logging
log4j2
log4j2
jcl
log4j2
log4j-jcl.jar

slf4j
桥接模式
jcl日志
SLF4J
jcl-over-slf4j.jar
Spring框架

使用 spring 4.X 及之前版本的框架时一定要注意上面情况，否则很容易出现业务日志输出正常，但是 spring 框架本身日志没有输出的情况，导致一些错误无法察觉或者不利于排查。

spring5.0 带来了 commons-logging 桥接模块的封装，它被叫做 spring-jcl 而不是标准版 jcl ，无需添加额外依赖包，可自动检测绑定到 Log4j2 、 SLF4J 。

SpringBoot框架

springboot-1.X - springboot-2.X :

从 SpringBoot 框架可以看出，默认采用 SLF4J+Logback 组合的日志框架，通过 桥接模式 将其它日志框架桥接到 SLF4J 上。

SLF4J

SLF4J(Simple Logging Facade For Java) 是一个为 Java 程序提供日志输出的统一接口，并不是一个具体的日志实现方案，就像我们经常使用的 JDBC 一样，只是了一些标准规范接口。因此，单独的 SLF4J 是不能工作的，它必须搭配其他具体的日志实现方案。

SLF4J 和 Logback 是同一个作者开发的，所以 Logback 天然与 SLF4J 适配，不需要引入额外适配库。

这里还有个比较有意思的事情， SLF4J 项目提供了很多适配库、桥接库，唯独没有提供对 Log4j2 的适配库和桥接库，不过 Apache Logging 项目组自己开发了： log4j-slf4j-impl 和 log4j-to-slf4j 。

JCL

Jakarta commons-logging 简称 JCL ，是 apache 提供的一个通用日志门面接口，最后版本更新停留在 2014年 ，且默认只能提供对 Log4j 、 Java Logging 进行适配。

JCL 已慢慢淡出人们的视线，一些历史遗留项目也开始慢慢由 JCL 转向 SLF4J ，如： Spring 5.0 开始没有再依赖原生的 JCL 框架， SpringBoot 默认采用 SLF4J+Logback 。 SLF4J 已经成为了 Java日志组件 的明星选手，可以完美替代 JCL ，使用 JCL 桥接库也能完美兼容一切使用 JCL 作为日志门面的类库，现在的新系统已经没有不使用 SLF4J 作为 统一日志API接口层 的理由了。

核心原理

SLF4J 和 JCL 对比，二者最大区别在于它们的绑定机制的不同，这也决定了为什么 JCL 会被慢慢的淘汰掉的根本原因。

SLF4J绑定原理

1、 slf4j 定义好两个接口规范：

public interface LoggerFactoryBinder {
    //获取一个ILoggerFactory实现类，采用工厂设计模式创建Logger
    public ILoggerFactory getLoggerFactory();
    public String getLoggerFactoryClassStr();
}

public interface ILoggerFactory {
    public Logger getLogger(String name);
}

第一个接口 LoggerFactoryBinder 定义绑定类，如果日志框架需要和 slf4j 进行绑定，就要提供一个该接口实现类，并且名称是 StaticLoggerBinder ，这样，在 slf4j 模块中，使用 StaticLoggerBinder.getSingleton(); 就可以获取到这个绑定类，进而通过 StaticLoggerBinder 绑定类的 getLoggerFactory() 获取到 Logger 生产工厂 ILoggerFactory 。

注意：这里的绑定机制利用到了类加载原理，如果存在多个绑定类 StaticLoggerBinder ，根据类路径的前后顺序，只有有一个会被加载进来，这个加载进来的就实现了绑定。

2、 ILoggerFactory 也是 slf4j 模块提供的一个接口，因为各个日志框架中 LoggerFactory 不统一，所以 slf4j 提供一个接口，让各个日志框架把自己的 LoggerFactory 包装成 ILoggerFactory 接口，这样 slf4j 模块下就可以统一使用。这里利用到的是设计模式中的：适配模式。系统间对接比较常用的一种设计模式，系统间接口不统一，通过适配模式实现一致。

3、可以看下， slf4j 和 log4j 绑定使用 slf4j-log4j12.jar ，这个模块下 StaticLoggerBinder 实现见下：

public class StaticLoggerBinder implements LoggerFactoryBinder {

    private static final StaticLoggerBinder SINGLETON = new StaticLoggerBinder();

    public static final StaticLoggerBinder getSingleton() {
        return SINGLETON;
    }

    public static String REQUESTED_API_VERSION = "1.6.99"; 

    private static final String loggerFactoryClassStr = Log4jLoggerFactory.class.getName();

    private final ILoggerFactory loggerFactory;

    private StaticLoggerBinder() {
        loggerFactory = new Log4jLoggerFactory();
        try {
            @SuppressWarnings("unused")
            Level level = Level.TRACE;
        } catch (NoSuchFieldError nsfe) {
            Util.report("This version of SLF4J requires log4j version 1.2.12 or later. See also http://www.slf4j.org/codes.html#log4j_version");
        }
    }

    public ILoggerFactory getLoggerFactory() {
        return loggerFactory;
    }

    public String getLoggerFactoryClassStr() {
        return loggerFactoryClassStr;
    }
}

4、 StaticLoggerBinder ：静态绑定，这个静态是相对于 JCL 所使用的动态绑定来说的，为什么说是静态的呢？因为你如果要绑定，需要在环境中添加绑定相关的jar，这样slf4j就可以加载到绑定包中的 StaticLoggerBinder 类实现绑定。

接口和实现类之间采用一种松耦合的设计，有利于灵活的扩展，但是在使用时有需要一种技术把它们关联起来，这是软件设计中比较常用到的设计思想， JDK 1.6 对此专门提供了一种技术： SPI 。 SLF4J 从 1.8版本 起，也开始使用 SPI 方式实现绑定，而不再采用通过寻找指定类 StaticLoggerBinder 的方式进行绑定。下面代码就是 slf4j-1.8 中使用 SPI 进行绑定核心代码：

private static List<SLF4JServiceProvider> findServiceProviders() {
    ServiceLoader<SLF4JServiceProvider> serviceLoader = ServiceLoader.load(SLF4JServiceProvider.class);
    List<SLF4JServiceProvider> providerList = new ArrayList<SLF4JServiceProvider>();
    for (SLF4JServiceProvider provider : serviceLoader) {
        providerList.add(provider);
    }
    return providerList;
}

SLF4JServiceProvider 就是类似于上面的 LoggerFactoryBinder 接口，通过它可以获取到 ILoggerFactory ，这样其它日志框架和 slf4j 进行集成时只需要提供一个 SLF4JServiceProvider 接口的实现类即可，不再要求必须是像之前固定名称必须是： StaticLoggerBinder ，固定名称带来的一个问题是包路径也要一致，无形中存在侵入性，而使用 SPI 方式更加的灵活。比如我们常用到的 JDBC 也使用到 SPI ，感兴趣的可以多了解下，对系统设计还是比较实用的一种技术。

JCL绑定原理

JCL 采用动态绑定机制，缺点是容易引发混乱，在一个复杂甚至混乱的依赖环境下，确定当前正在生效的日志服务是很费力的，特别是在程序开发和设计人员并不理解 JCL 的机制时。

JCL 动态绑定的核心逻辑位于 LogFactoryImpl 类的 discoverLogImplementation 方法中如下代码块：

for(int i=0; i<classesToDiscover.length && result == null; ++i) {
    /**
    createLogFromClass()核心逻辑：通过Class.forName()加载适配器的类模板，
    然后调用Constructor.newInstance()构建适配器类实例
    */
 result = createLogFromClass(classesToDiscover[i], logCategory, true);
}

其中 classesToDiscover 数组的中定义了可以使用的适配器类，见下：

String[] classesToDiscover = {
            "org.apache.commons.logging.impl.Log4JLogger",
            "org.apache.commons.logging.impl.Jdk14Logger",
            "org.apache.commons.logging.impl.Jdk13LumberjackLogger",
            "org.apache.commons.logging.impl.SimpleLog"
};

简单来说： JCL 模块中会有判断，当前项目中是否存在 Log4j 的 API ，如果有就直接和 Log4j 进行绑定；如果没有，则继续向下查找，是否存在 JDK Log 相关 API ，如果有就绑定；如果 JDK Log 也没有，则提供一个 SimpleLog 默认实现，该实现什么也不做，输出的日志直接会被丢弃，什么也看不到。

总结

相较于 JCL 的 动态绑定机制 ， SLF4J 则简单得多，采用 静态绑定机制 ，可能你还没有很好理解这两者的本质区别，看下图：

编程开发（一）：日志框架

JCL 框架自动检查当前环境中是否存在相关日志 API ，如果有就绑定，注意它内部有个固定的绑定顺序，这种所谓的动态绑定很容易出现问题，特别是系统较大可能会存在很多日志框架，就会出现混乱，不够灵活，这就导致了为啥 JCL 已经被慢慢淘汰掉。

而 slf4j 采用的静态绑定，不是直接和日志框架进行绑定，而是中间多了一个环节：绑定类，它就像一个开关一样，关键是可以进行控制，比如想和 log4j2 进行绑定，就添加 log4j-slf4j-impl.jar ，开关就会打开进行绑定。 slf4j 不管是采用 StaticLoggerBinder 还是后面采用的 SPI ，始终有个绑定类控制绑定关系。