日志框架看这一篇够了

除了功能需求外，选择日志库的一个重要原因通常是它如何满足非功能性需求，如可靠性和性能。下文从简单介绍到性能比较了解日志系统

日志种类

日志	简介	首选率
JDK	JDK自带	1%
SLF4J	日志门面(定义接口)	99%
Log4j	日志输出	0%
Log4j2	日志门面和日志输出	40%
Logback	日志输出	80%

日志选型

1. 活跃度
2. 文档完善

一、JDK Logger

1. java.util.logging是JDK自带的日志记录包；
2. 默认JDK的LogManager会在JRE目录下的"lib/logging.properties"文件中读取配置；
3. 依赖JDK更新

且不谈性能，JDK自带意味着在某些场景下有一定的使用可能，依赖JDK且就意味着需要跟随JDK更新，需求复杂情况下显得鸡肋，故一般情况下我们不会选择使用。

二、SLF4J

1. 门面日志，上层日志定义了接口形式；

本身不做具体的实现，也就不需要顾虑性能，主流的日志框架都有实现SLF4J标准，意味着使用SLF4J会使得后续切换日志框架成本降低。

三、Log4j

1. 早先日志框架
2. 以停止更新
3. 设计结构上比不上slf4j，性能上比不上logback

随着技术的发展，log4j的结构、性能被很多新的日志框架所替代。在设计结构上比不上slf4j，在性能上比不上logback。于是apache对垂垂老矣的log4j进行一次重生，不是优化。虽然都叫log4j但是，他们是两个完全不同的东西，为了方便区分他们，给了两个别名：log4j1、log4j2。

四、Log4j2

1. Log4j的升级
2. 包含门面日志也有日志输出，且比SLF4J丰富
3. 功能丰富
4. 多线程性能优秀
5. 出现过严重bug

官网

需要提到的是在多线程的情况下性能极其优秀，同时带有门面框架也适配SLF4J

五、Logback

1. 整体性能优秀
2. 多数之选
3. 功能丰富

官网

Logback在提供丰富功能的同时适配SLF4J，性能方面也是佼佼者，所以目前它作为了多数的选择

六、优选

目前主流无非log42或者logback

1、logback取代log4j的理由：

1、更快的实现：Logback的内核重写了，在一些关键执行路径上性能提升10倍以上。而且logback不仅性能提升了，初始化内存加载也更小了。

2、非常充分的测试：Logback经过了几年，数不清小时的测试。Logback的测试完全不同级别的。

3、Logback-classic非常自然实现了SLF4j：Logback-classic实现了SLF4j。在使用SLF4j中，你都感觉不到logback-classic。而且因为logback-classic非常自然地实现了slf4j ， 所 以切换到log4j或者其他，非常容易，只需要提供成另一个jar包就OK，根本不需要去动那些通过SLF4JAPI实现的代码。

4、非常充分的文档 官方网站有两百多页的文档。

5、自动重新加载配置文件，当配置文件修改了，Logback-classic能自动重新加载配置文件。扫描过程快且安全，它并不需要另外创建一个扫描线程。这个技术充分保证了应用程序能跑得很欢在JEE环境里面。

6、Lilith是log事件的观察者，和log4j的chainsaw类似。而lilith还能处理大数量的log数据 。

7、谨慎的模式和非常友好的恢复，在谨慎模式下，多个FileAppender实例跑在多个JVM下，能 够安全地写道同一个日志文件。RollingFileAppender会有些限制。Logback的FileAppender和它的子类包括 RollingFileAppender能够非常友好地从I/O异常中恢复。

8、配置文件可以处理不同的情况，开发人员经常需要判断不同的Logback配置文件在不同的环境下（开发，测试，生产）。而这些配置文件仅仅只有一些很小的不同，可以通过,和来实现，这样一个配置文件就可以适应多个环境。

9、Filters（过滤器）有些时候，需要诊断一个问题，需要打出日志。在log4j，只有降低日志级别，不过这样会打出大量的日志，会影响应用性能。在Logback，你可以继续 保持那个日志级别而除掉某种特殊情况，如alice这个用户登录，她的日志将打在DEBUG级别而其他用户可以继续打在WARN级别。要实现这个功能只需加4行XML配置。可以参考MDCFIlter 。

10、SiftingAppender（一个非常多功能的Appender）：它可以用来分割日志文件根据任何一个给定的运行参数。如，SiftingAppender能够区别日志事件跟进用户的Session，然后每个用户会有一个日志文件。

11、自动压缩已经打出来的log：RollingFileAppender在产生新文件的时候，会自动压缩已经打出来的日志文件。压缩是个异步过程，所以甚至对于大的日志文件，在压缩过程中应用不会受任何影响。

12、堆栈树带有包版本：Logback在打出堆栈树日志时，会带上包的数据。

13、自动去除旧的日志文件：通过设置TimeBasedRollingPolicy或者SizeAndTimeBasedFNATP的maxHistory属性，你可以控制已经产生日志文件的最大数量。如果设置maxHistory 12，那那些log文件超过12个月的都会被自动移除。

2、logback相比log4j2：

十分有意思的是两者的官网火药味十足，都表示自己更快

Log4j2： Apache Log4j 2 是对 Log4j 的升级，它比其前身 Log4j 1.x 提供了显着改进，并提供了 Logback 中可用的许多改进，同时修复了 Logback 架构中的一些固有问题。在多线程场景中，异步 Logger 的吞吐量比 Log4j 1.x 和 Logback 高 18 倍，延迟低几个数量级。

Logback： Logback 版本 1.3-alpha10 在同步日志记录的情况下比 log4j 快约 3 倍，比 log4j2 快约 1.6 倍。对于异步日志记录，logback 1.3 的执行速度比 log4j 快 2.5，比 log4j2 快 2.3 倍。

Logback官网测试
Log4j2官网测试

2.1、基准

引用Log4j2官网的测量标准

峰值吞吐量： 许多对外部事件做出反应的系统需要记录消息的爆发，然后是一段相对安静的时期。这个数字是在短时间内测量的最大吞吐量，并且可以让您了解日志库处理突发事件的能力。对于需要以恒定的高速率记录大量日志的系统（例如，批处理作业），这不太可能是衡量性能的有用指标。

最大持续吞吐量： 这是长时间平均的吞吐量。这是衡量日志库容量“上限”的有用指标。不建议反应式应用程序实际上以这种速率记录，因为在这种负载下，它们可能会遇到抖动和较大的响应时间峰值。

各种负载下的响应时间： 对于需要及时响应外部事件的应用程序来说，这是最重要的问题。响应时间是记录消息所需的总时间，是服务时间和等待时间的总和。服务时间是完成工作以记录消息所需的时间。随着工作量的增加，服务时间通常变化不大：做 X 量的工作总是需要 X 量的时间。等待时间是请求必须在队列中等待多长时间才能得到服务 。随着工作量的增加，等待时间通常会增长到服务时间的许多倍。

引用Log4j2的描述–对于此处描述的无锁队列，是基于LMAX Disruptor ，这是基于环形数组时间的无锁并发框架

异步日志记录对于处理突发事件很有用。它的工作原理是应用程序线程完成最少的工作以捕获日志事件中的所有必需信息，然后将此日志事件放入队列中以供后台线程稍后处理。只要队列足够大，应用程序线程应该能够在日志调用上花费很少的时间并很快返回到业务逻辑。

事实证明，队列的选择对于峰值吞吐量极为重要。Log4j 2 的 Async Loggers 使用无 锁数据结构，而 Logback、Log4j 1.2 和 Log4j 2 的 Asynchronous Appenders 使用 ArrayBlockingQueue。使用阻塞队列时，多线程应用程序在尝试将日志事件排入队列时经常会遇到锁争用。

简易测试结果

确实LogBack性能根好

–EOF–