Log4j吞吐量上有15%增加。JUL这轮比拼中比不上Log4j和Log4j2其结果和不使用上下文数据是一样的，日志是不可缺少的重要组成局部，应用系统中。所有的应用的出错信息等都应该能在日志文件中查找到有的应用系统日志可能数量很小，有的庞大的应用系统的日志是相当庞大，同时日志文件必需是方便用户定制和查找的要具备很高的性能，否则会影响应用系统的性能。

日志所耗费的时间就会显现。本文中，由 于日志通常涉及到IO读写磁盘（或者是阻塞或者是异步）这都要耗费时间。当在大型系统中有大量数据的时候。将深入 探讨目前Java开源世界中领先的五个日志框架，各个方面进行比拟，要指出的本文并不是探究哪个日志框架是最优秀的而只是列出各自的优缺点。

选取的五个日志框架分别为：

1.Log4J

2.Log4J2

3.Logback

4.SLF4JSimplLogSLF4JSL

5.JavaUtilLogJUL

每一个日志操作包括时间戳和其上下文的进程ID进行如下四个方面的测评：想对比下这些日志框架对于基本的日志记录活动的性能如何。

1.记录字符串常量

2.Logthe.toStrvaluofaPOJO对POJO使用.toStr方法

3.Logathrowablobject记录throwabl对象4只测试.toStr方法

通过衡量完成日纸记录的操作次数，决定为每种场景进行五次的评测。以决定哪一个有最佳的成果。每次测试中让日志引擎在一分钟内使用10个线程去执行，并且剔除最大的2次偏差，将余下的三次进行平均。

让CPU日志记录的时候都执行一些操作（如检查是否一个随机数是否素数）这些评测的日志引擎都使用各自的默认配置通过SLF4J来运行。评测是Amazonm1.largEC2实例上进行的每一个单独的日志记录操作中。

设置了%C布局参数以符合其他配 置，这给Log4j2一个性能相当大的提升，下面两个图中，值得注意的记录上下文的性能开销。

下面对基于4个场景的测试结果进行具体分析：

字符串常量，需要日志引擎使用线程和时间戳上下文去记录字符串常量。Log4j冠军，这轮比拼中。比JUL能多写270%日志行，比logback多12.5%比SLF4JSL多52%有趣的改变log4j2配置前，写的行数能是比改变后的1/4左右，更改配置后，性能排在第三位，只比logback记录的行数少30%

toStr，对于Log4j2来说，这轮比拼中记录的POJO使用其.toStr方法)同样使用的线程和时间戳。结果中。和第一回合差不多，但相比 SLF4JSL有25%性能提升。Log4j和Logback不相上下的位居第三，其吞吐量是SLF4JSL88%

Throwable，日志引擎记录异常的对象和相关的描述信息。其中Log4j2位居首位，这轮比拼中。其性能比SLF4JSL高3倍，SLF4JSL位于第五位。

记录的行数只大概有冠军的一半，而Log4j和Logback也是只能排在此轮的冠军之后。而第二位的反而是JUL能记录冠军Log4j2日志量的大概82%

toStr方法比拼，每一个日志项的上下文（例如线程ID,当 处置服务器日志的时候。类的相关上下文，时间戳等等）都是和日志内容一样重要。之前的测试中，使用的大多数日 志文件中常见的标志――线程ID号和时间戳。接下来我认为值得去分析单纯在日志中使用.toStr方法的性能。

Log4j2赢家（如果改变配置，这个时候。能获得180%性能提升）赢出Logback和JUL大概25%SL4FJSL则落败。每轮的五次测试中，SLF4JSL启用append时候性能比不启用要好。