深刻掌握Java日志体系，不再迷路了

时间  2021-08-14
标签 html java git github spring apache 设计模式 api 数组 安全 栏目 Java 繁體版
原文   原文链接

点赞再看，养成习惯，公众号搜一搜【一角钱技术】关注更多原创技术文章。本文 GitHub org_hejianhui/JavaStudy 已收录，有个人系列文章。html

前言

对于一个应用程序来讲日志记录是必不可少的一部分。线上问题追踪，基于日志的业务逻辑统计分析等都离不日志。java领域存在多种日志框架，目前经常使用的日志框架包括Log4j 1，Log4j 2，Commons Logging，Slf4j，Logback，Jul。可是在咱们的系统里面到底该怎么使用日志框架？还在为弄不清commons-logging.jar、log4j.jar、sl4j-api.jar等日志框架之间复杂的关系而感到烦恼吗？还在为如何统一系统的日志输出而感到不知所措嘛？好比，要更改Spring的日志输出为Log4j 2，殊不知该引哪些jar包，只知道去百度一下所谓的博客，照着人家复制，却没法弄懂其中的原理？本文将弄懂其中的原理，只要你静下心看本文，你就能为所欲为更改你系统里的日志框架，统一日志输出！java

日志框架类别

记录型日志框架

  1. Jul (Java Util Logging)：JDK中的日志记录工具，也常称为JDKLog、jdk-logging，自Java1.4以来的官方日志实现。
  2. Log4j：Apache Log4j是一个基于Java的日志记录工具。它是由Ceki Gülcü独创的，如今则是Apache软件基金会的一个项目。 Log4j是几种Java日志框架之一。
  3. Log4j2：一个具体的日志实现框架，是Log4j 1的下一个版本，与Log4j 1发生了很大的变化，Log4j 2不兼容Log4j 1。
  4. Logback：一个具体的日志实现框架，和Slf4j是同一个做者，但其性能更好（推荐使用）。

门面型日志框架

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

看到这么多日志框架是否会以为比较混乱，这些日志框架之间有什么异同，都是由谁在维护，在项目中应该如何选择日志框架，应该如何使用? 不要急，咱们先把这些术语概念先有个印象。让咱们先了解一它们的发展历史。git

日志框架发展史

Java日志的恩怨情仇

  • 1996年早期，欧洲安全电子市场项目组决定编写它本身的程序跟踪API(Tracing API)。通过不断的完善，这个API终于成为一个十分受欢迎的Java日志软件包，即Log4j（由Ceki建立）。
  • 后来Log4j成为Apache基金会项目中的一员，Ceki也加入Apache组织。后来Log4j近乎成了Java社区的日志标准。听说Apache基金会还曾经建议Sun引入Log4j到Java的标准库中，但Sun拒绝了。
  • 2002年Java1.4发布，Sun推出了本身的日志库JUL(Java Util Logging),其实现基本模仿了Log4j的实现。在JUL出来之前，Log4j就已经成为一项成熟的技术，使得Log4j在选择上占据了必定的优点。
  • 接着，Apache推出了Jakarta Commons Logging，JCL只是定义了一套日志接口(其内部也提供一个Simple Log的简单实现)，支持运行时动态加载日志组件的实现，也就是说，在你应用代码里，只需调用Commons Logging的接口，底层实现能够是Log4j，也能够是Java Util Logging。
  • 后来(2006年)，Ceki不适应Apache的工做方式，离开了Apache。而后前后建立了Slf4j(日志门面接口，相似于Commons Logging)和Logback(Slf4j的实现)两个项目，并回瑞典建立了QOS公司，QOS官网上是这样描述Logback的：The Generic，Reliable Fast&Flexible Logging Framework(一个通用，可靠，快速且灵活的日志框架)。
  • Java日志领域被划分为两大阵营：Commons Logging阵营和Slf4j阵营。
  • Commons Logging在Apache大树的笼罩下，有很大的用户基数。但有证据代表，形式正在发生变化。2013年末有人分析了GitHub上30000个项目，统计出了最流行的100个Libraries，能够看出Slf4j的发展趋势更好。
  • Apache眼看有被Logback反超的势头，于2012-07重写了Log4j 1.x，成立了新的项目Log4j 2, Log4j 2具备Logback的全部特性。

大神Ceki github

log4j

早年，你工做的时候，在日志里使用了log4j框架来输出，因而你代码是这么写的spring

import org.apache.log4j.Logger;
//省略...
Logger logger = Logger.getLogger(Test.class);
logger.trace("trace");
//省略...
复制代码

jul

可是，岁月流逝，sun公司对于log4j的出现心里隐隐表示嫉妒。因而在jdk1.4版本后，增长了一个包为java.util.logging，简称为jul，用以对抗log4j。因而，你的领导要你把日志框架改成jul，这时候你只能一行行的将log4j的api改成jul的api，以下所示:apache

import java.util.logging.Logger；
//省略...
Logger loggger = Logger.getLogger(Test.class.getName()); 
logger.finest("finest");
//省略...
复制代码

能够看出，api彻底是不一样的。那有没有办法，将这些api抽象出接口，这样之后调用的时候，就调用这些接口就行了呢？设计模式

jcl

这个时候jcl(Jakarta Commons Logging)出现了，说jcl可能你们有点陌生，讲commons-logging-xx.jar组件，你们总有印象吧。JCL 只提供 log 接口，具体的实现则在运行时动态寻找。这样一来组件开发者只须要针对 JCL 接口开发，而调用组件的应用程序则能够在运行时搭配本身喜爱的日志实践工具。JCL能够实现的集成方案以下图所示 jcl默认的配置：若是能找到Log4j 则默认使用log4j 实现，若是没有则使用jul(jdk自带的) 实现，再没有则使用jcl内部提供的SimpleLog 实现。api

因而，你在代码里变成这么写了数组

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
//省略...
Log log =LogFactory.getLog(Test.class);
log.trace('trace');
//省略...
复制代码

至于这个Log具体的实现类，JCL会在ClassLoader中进行查找。这么作，有三个缺点:安全

  • 缺点一是效率较低
  • 二是容易引起混乱
  • 三是在使用了自定义ClassLoader的程序中，使用JCL会引起内存泄露。

slf4j

因而log4j的做者（Ceki）以为jcl很差用，本身又写了一个新的接口api，那么就是slf4j。

咱们在代码中须要写日志，变成下面这么写

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
//省略...
Logger logger = LoggerFactory.getLogger(Test.class);
//省略...
logger.info("info");
复制代码

在代码中，并不会出现具体日志框架的api。程序根据classpath中的桥接器类型，和日志框架类型，判断出logger.info应该以什么框架输出！注意了，若是classpath中不当心引了两个桥接器，那会直接报错的！

所以，在阿里的开发手册上才有这么一条

强制：应用中不可直接使用日志系统（log4j、logback）中的 API ，而应依赖使用日志框架 SLF4J 中的 API 。使用门面模式的日志框架，有利于维护和各个类的日志处理方式的统一。

Slf4j的使用

Slf4j与其它日志组件的关系说明

  • Slf4j的设计思想比较简洁，使用了Facade设计模式，Slf4j自己只提供了一个slf4j-api-version.jar包，这个jar中主要是日志的抽象接口，jar中自己并无对抽象出来的接口作实现。
  • 对于不一样的日志实现方案(例如Logback，Log4j...)，封装出不一样的桥接组件(例如logback-classic-version.jar，slf4j-log4j12-version.jar)，这样使用过程当中能够灵活的选取本身项目里的日志实现。

Slf4j与其它日志组件集成图

如图所示，应用调了sl4j-api，即日志门面接口。日志门面接口自己一般并无实际的日志输出能力，它底层仍是须要去调用具体的日志框架API的，也就是实际上它须要跟具体的日志框架结合使用。因为具体日志框架比较多，并且互相也大都不兼容，日志门面接口要想实现与任意日志框架结合可能须要对应的桥接器，上图红框中的组件便是对应的各类桥接器！

Slf4j与其余各类日志组件的桥接说明

jar包名 说明
slf4j-log4j12-1.7.30.jar Log4j1.2版本的桥接器，你须要将Log4j.jar加入Classpath。
slf4j-jdk14-1.7.30.jar java.util.logging的桥接器，Jdk原生日志框架。
slf4j-nop-1.7.30.jar NOP桥接器，默默丢弃一切日志。
slf4j-simple-1.7.30.jar 一个简单实现的桥接器，该实现输出全部事件到System.err. 只有Info以及高于该级别的消息被打印，在小型应用中它也许是有用的。
slf4j-jcl-1.7.30.jar Jakarta Commons Logging 的桥接器. 这个桥接器将Slf4j全部日志委派给Jcl。
logback-classic-1.0.13.jar(requires logback-core-1.0.13.jar) Slf4j的原生实现，Logback直接实现了Slf4j的接口，所以使用Slf4j与Logback的结合使用也意味更小的内存与计算开销

具体的介入方式参考下图

Slf4j源码分析

slf4j-api-version.jar中几个核心类与接口

类与接口 用途
org.slf4j.LoggerFactory(class) 给调用方提供的建立Logger的工厂类，在编译时绑定具体的日志实现组件
org.slf4j.Logger(interface) 给调用方提供的日志记录抽象方法，例如debug(String msg),info(String msg)等方法
org.slf4j.ILoggerFactory(interface) 获取的Logger的工厂接口，具体的日志组件实现此接口
org.slf4j.helpers.NOPLogger(class) 对org.slf4j.Logger接口的一个没有任何操做的实现，也是Slf4j的默认日志实现
org.slf4j.impl.StaticLoggerBinder(class) 与具体的日志实现组件实现的桥接类，具体的日志实现组件须要定义org.slf4j.impl包，并在org.slf4j.impl包下提供此类，注意在slf4j-api-version.jar中不存在org.slf4j.impl.StaticLoggerBinder，在源码包slf4j-api-version-source.jar中才存在此类

Slf4j调用过程源码分析，只加入slf4j-api-version.jar，不加入任何实现包

pom配置

<!--只有slf4j-api依赖-->
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>1.7.30</version>
</dependency>
复制代码

程序入口类

package com.niuh;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class App {
    final static Logger logger = LoggerFactory.getLogger(App.class);

    public static void main(String[] args) {
        logger.info("Hello World");
    }
}
复制代码

源码追踪分析

  1. 调用LoggerFactory的getLogger()方法建立Logger

  1. 调用LoggerFactory的getILoggerFactory方法来建立ILoggerFactory

  1. 调用LoggerFactory的performInitialization方法来进行初始化

  1. 调用LoggerFactory的bind()方法

  1. 调用LoggerFactory的findPossibleStaticLoggerBinderPathSet()方法获取StaticLoggerBinderPath集合

  1. 调用LoggerFactory的reportMultipleBindingAmbiguity()方法，记录绑定的StaticLoggerBinder信息

  1. LoggerFactory的reportMultipleBindingAmbiguity()方法

  1. LoggerFactory的bind()方法找不到StaticLoggerBinder，抛出NoClassDefFoundError异常

  1. LoggerFactory的bind()方法捕获NoClassDefFoundError异常，匹配到StaticLoggerBinder关键词记录信息到控制台

  1. LoggerFactory的performInitialization()方法内部调用bind()方法结束

  1. LoggerFactory的getLogger()方法内部getILoggerFactory()方法调用完成，建立出NOPLoggerFactory，而后由NOPLoggerFactory调用内部的getLogger()方法，建立出NOPLogger

  1. App类内部的logger实际为NOPLogger,调用logger.info()方法实际调用的是NOPLogger的info方法

Slf4j调用过程源码分析，加入slf4j-api-version.jar，与Logback组件

Slf4j做为门面采用Logback做为实现或者采用其它上面提到过的组件做为实现相似，这里只分析采用Logback组件做为实现

pom配置

<dependencies>
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
      <version>1.7.30</version>
    </dependency>
    <!--logback-classic依赖logback-core，会自动级联引入-->
    <dependency>
      <groupId>ch.qos.logback</groupId>
      <artifactId>logback-classic</artifactId>
      <version>1.2.3</version>
    </dependency>
</dependencies>
复制代码

程序入口类

同上

源码追踪分析

  • 一、二、三、4同上
    1. 调用LoggerFactory的findPossibleStaticLoggerBinderPathSet()方法获取StaticLoggerBinderPath集合

    1. 调用LoggerFactory的bind()方法的staticLoggerBinderPathSet集合对象赋值

    1. 在LoggerFactory的bind()方法中调用loback包下的StaticLoggerBinder建立单例对象

    1. 在LoggerFactory的bind()方法中调用reportActualBinding()记录日志加载信息

    1. LoggerFactory中INITIALIZATION_STATE的值为SUCCESSFUL_INITIALIZATION，调用StaticLoggerBinder的单例对象获取ILoggerFactory

    1. 此时LoggerFactory中的getLogger()方法中获取到的ILoggerFactory其实是logback jar下的LoggerContext

    1. 此时LoggerFactory调用getLogger()方法获取到的Logger其实是logback jar下的Logger

  • 最后输出

Slf4j调用过程源码分析，加入slf4j-api-version.jar，同时加入多种日志实现组件

在项目中若是用slf4j-api做为日志门面，有多个日志实现组件同时存在，例如同时存在Logback，slf4j-log4j12，slf4j-jdk14，slf4j-jcl四种实现，则在项目实际运行中，Slf4j的绑定选择绑定方式将有Jvm肯定，而且是随机的，这样会和预期不符，实际使用过程当中须要避免这种状况。

pom配置

<dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.11</version>
    </dependency>
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-log4j12</artifactId>
      <version>1.7.30</version>
    </dependency>
    <dependency>
      <groupId>ch.qos.logback</groupId>
      <artifactId>logback-classic</artifactId>
      <version>1.2.3</version>
    </dependency>
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-jdk14</artifactId>
      <version>1.7.30</version>
    </dependency>
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-jcl</artifactId>
      <version>1.7.30</version>
    </dependency>
</dependencies>
复制代码

程序入口类

同上

源码追踪分析

  • 基本步骤同上，这里只追踪主要不一样点
  • (1) 追踪LoggerFactory的bind()方法内部调用findPossibleStaticLoggerBinderPathSet()方法后，从classpath下4个jar包内找到StaticLoggerBinder

  • (2) 此时LoggerFactory的bind()方法内部调用reportMultipleBindingAmbiguity()方法，给出警告信息classpath下同时存在多个StaticLoggerBinder,JVM会随机选择一个StaticLoggerBinder

使用Slf4j时如何桥接遗留的api

在实际环境中咱们常常会遇到不一样的组件使用的日志框架不一样的状况，例如Spring Framework使用的是日志组件是Commons Logging，XSocket依赖的则是Java Util Logging。当咱们在同一项目中使用不一样的组件时应该若是解决不一样组件依赖的日志组件不一致的状况呢？如今咱们须要统一日志方案，统一使用Slf4j，把他们的日志输出重定向到Slf4j，而后Slf4j又会根据绑定器把日志交给具体的日志实现工具。Slf4j带有几个桥接模块，能够重定向Log4j，JCL和java.util.logging中的Api到Slf4j。

遗留的api桥接方案

jar包名 做用
log4j-over-slf4j-version.jar 将Log4j重定向到Slf4j
jcl-over-slf4j-version.jar 将Commons Logging里的Simple Logger重定向到slf4j
jul-to-slf4j-version.jar 将Java Util Logging重定向到Slf4j

桥接方式参见下图

使用Slf4j桥接注意事项

在使用Slf4j桥接时要注意避免造成死循环，在项目依赖的jar包中不要存在如下状况。

多个日志jar包造成死循环的条件 产生缘由
log4j-over-slf4j.jar和slf4j-log4j12.jar同时存在 因为slf4j-log4j12.jar的存在会将全部日志调用委托给log4j。但因为同时因为log4j-over-slf4j.jar的存在，会将全部对log4j api的调用委托给相应等值的slf4j,因此log4j-over-slf4j.jar和slf4j-log4j12.jar同时存在会造成死循环
jul-to-slf4j.jar和slf4j-jdk14.jar同时存在 因为slf4j-jdk14.jar的存在会将全部日志调用委托给jdk的log。但因为同时jul-to-slf4j.jar的存在，会将全部对jul api的调用委托给相应等值的slf4j，因此jul-to-slf4j.jar和slf4j-jdk14.jar同时存在会造成死循环

JCL与Slf4j实现机制对比

前面介绍过门面型的日志框架主要就两个JCL（Commons Logging）和Slf4j，咱们来简单了解下它们的区别：

JCL(Commons Logging)实现机制

JCL(Commons Logging) 是经过动态查找机制，在程序运行时，使用本身的ClassLoader寻找和载入本地具体的实现。详细策略能够查看commons-logging-*.jar包中的org.apache.commons.logging.impl.LogFactoryImpl.java文件。因为Osgi不一样的插件使用独立的ClassLoader，Osgi的这种机制保证了插件互相独立, 其机制限制了Commons Logging在Osgi中的正常使用。

Slf4j实现机制

Slf4j在编译期间，静态绑定本地的Log库，所以能够在Osgi中正常使用。它是经过查找类路径下org.slf4j.impl.StaticLoggerBinder，而后在StaticLoggerBinder中进行绑定。

日志实战

案例一

一个项目，一个模块用log4j，另外一个模块用slf4j+log4j2,如何统一输出？

其实在某些中小型公司，这种状况很常见。我曾经见过某公司的项目，由于研发不懂底层的日志原理，日志文件里头既有log4j.properties，又有log4j2.xml，各类API混用，惨不忍睹!

还有人用着jul的API，而后拿着log4j.properties，跑来问我，为何配置不生效！简直是一言难尽！

OK，回到咱们的问题，如何统一输出！OK，这里就要用上slf4j的适配器，slf4j提供了各类各样的适配器，用来将某种日志框架委托给slf4j。其最明显的集成工做方式有以下: 进行选择填空，将咱们的案例里的条件填入,根据题意应该选log4j-over-slf4j适配器，因而就变成下面这张图

就能够实现日志统一为log4j2来输出！

PS: 根据适配器工做原理的不一样，被适配的日志框架并非必定要删除！以上图为例，log4j这个日志框架删不删均可以，你只要能保证log4j的加载顺序在log4j-over-slf4j后便可。由于log4j-over-slf4j这个适配器的工做原理是，内部提供了和log4j如出一辙的api接口，所以你在程序中调用log4j的api的时候，你必须想办法让其走适配器的api。若是你删了log4j这个框架，那你程序里确定是走log4j-over-slf4j这个组件里的api。若是不删log4j，只要保证其在classpth里的顺序比log4j前便可！

案例二

如何让Spring以log4j2的形式输出？

Spring默认使用的是jcl输出日志，因为你此时并无引入Log4j的日志框架，jcl会以jul作为日志框架。此时集成图以下 而你的应用中，采用了slf4j+log4j-core，即log4j2进行日志记录，那么此时集成图以下 那咱们如今须要让Spring以log4j2的形式输出？怎么办？

OK，第一种方案，走jcl-over-slf4j适配器，此时集成图就变成下面这样了 在这种方案下，spring框架中遇到日志输出的语句，就会如上图红线流程同样，最终以log4J2的形式输出！

OK，有第二种方案么？

有，走jul-to-slf4j适配器，此时集成图以下

PS: 这种状况下，记得在代码中执行

SLF4JBridgeHandler.removeHandlersForRootLogger();
SLF4JBridgeHandler.install();
复制代码

这样jul-to-slf4j适配器才能正常工做，详情能够查询该适配器工做原理。

案例三

假设，咱们在应用中调用了sl4j-api，可是呢，你引了四个jar包，slf4j-api-xx.jar，slf4j-log4j12-xx.jar，log4j-xx.jar，log4j-over-slf4j-xx.jar，因而你就会出现以下尴尬的场面

如上图所示，在这种状况下，你调用了slf4j-api，就会陷入死循环中！slf4j-api去调了slf4j-log4j12,slf4j-log4j12又去调用了log4j，log4j去调用了log4j-over-slf4j。最终，log4j-over-slf4j又调了slf4j-api，陷入死循环！

spring4和spring5日志中的不一样

Spring4日志体系

构建spring4项目，采用java+注解的方式快速构建，pom中只引入spring-context包

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>4.3.21.RELEASE</version>
    </dependency>
</dependencies>
复制代码

运行下面的代码，能够看到有日志输出

public class MainClass {

    public static void main(String[] args) {
        AnnotationConfigApplicationContext annotationConfigApplicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
    }
}
复制代码

找到打印日志的地方，debug模式下，查看输出日志的Log是什么log 能够看出是jdk14Logger，这个在JCL中说过，这个指的是JUL，也就是说在默认spring日志体系下，采用的是JUL，

接下来，咱们按照以前的方法引入log4j，debug运行上面的程序，再次查看日志类型

<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>1.2.17</version>
</dependency>
复制代码

额，此次在增长log4j jar包和配置文件的状况下，spring4有使用了log4j，这么像JCL呢，木错，让咱们在idea中打开spring4的日志依赖结构： common-logging 这不就是JCL使用到的包吗，能够看出，Spring4使用的是原生的JCL，因此在有log4j的时候使用log4j打印日志，没有的时候使用JUL打印日志。

Spring5日志体系

依赖结构图：

大致结构没变，只是原来common-logging ，换成了spring-jcl，看名字就知道是spring自造的包，jcl，更是标注了，它使用的是JCL日志体系。

咱们仍是经过看源码来验证，咱们只用debug找到spring内部一个Log，看看他的产生方式和类型。此次我给你们找了AbstractApplicationContext里面找到产生Log的地方

进入这个方法的getLog()中，一直深刻，找到LogAdapter中的createLog()方法 能够看出来Spring5中对日志的生产，不在像原生JCL中那样使用一个数组，而后进行循环产生，这里用到的是Switch case，这个关键字段logApi又是在哪一部分赋值的呢？以下所示： 咱们看到是在静态代码块中赋的值，为了验证，咱们准备用其中提到的log4j2验证（注意：log4j不行，由于这里的switch没有log4j选项），首先咱们准备log4j2.xml的配置文件

<Configuration status="WARN">

    <Appenders>

        <Console name="Console" target="SYSTEM_OUT">

            <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>

        </Console>

    </Appenders>

    <Loggers>

        <Root level="debug">

            <AppenderRef ref="Console"/>

        </Root>

    </Loggers>

</Configuration>
复制代码

而后准备pom的依赖

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>5.2.8.RELEASE</version>
    </dependency>
    <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-core</artifactId>
        <version>2.10.0</version>
    </dependency>
</dependencies>
复制代码

运行下面的代码

public class MainClass {

    public static void main(String[] args) {
        AnnotationConfigApplicationContext annotationConfigApplicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
    }
}
复制代码

结果有日志打印出来了 因此，在Spring5中，依然使用的是JCL，可是不是原生的，是通过改造的JCL，默认使用的是JUL，而原生JCL中默认使用的是log4j。

项目中选择日志框架选择

若是是在一个新的项目中建议使用Slf4j与Logback组合，这样有以下的几个优势。

  • Slf4j实现机制决定Slf4j限制较少，使用范围更广。因为Slf4j在编译期间，静态绑定本地的LOG库使得通用性要比Commons Logging要好。

  • Logback拥有更好的性能。Logback声称：某些关键操做，好比断定是否记录一条日志语句的操做，其性能获得了显著的提升。这个操做在Logback中须要3纳秒，而在Log4J中则须要30纳秒。LogBack建立记录器（logger）的速度也更快：13毫秒，而在Log4J中须要23毫秒。更重要的是，它获取已存在的记录器只需94纳秒，而Log4J须要2234纳秒，时间减小到了1/23。跟JUL相比的性能提升也是显著的。

  • Commons Logging开销更高

# 在使Commons Logging时为了减小构建日志信息的开销，一般的作法是
if(log.isDebugEnabled()){
  log.debug("User name： " +
    user.getName() + " buy goods id ：" + good.getId());
}

# 在Slf4j阵营，你只需这么作：
log.debug("User name：{} ,buy goods id ：{}", user.getName(),good.getId());

# 也就是说，Slf4j把构建日志的开销放在了它确认须要显示这条日志以后，减小内存和Cup的开销，使用占位符号，代码也更为简洁
复制代码
  • Logback文档免费。Logback的全部文档是全面免费提供的，不象Log4J那样只提供部分免费文档而须要用户去购买付费文档。

参考资料

文章持续更新，能够公众号搜一搜「 一角钱技术 」第一时间阅读， 本文 GitHub org_hejianhui/JavaStudy 已经收录，欢迎 Star。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程