下面对基于4个场景的测试结果进行具体分析： 一 字符串常量 在 这轮比拼中，需要日志引擎使用线程和时间戳上下文去记录字符串常量。Log4j是冠军，比JUL能多写270%的日志行，比logback多12.5%， 比SLF4J SL多52%。有趣的是在我们改变log4j2的配置前，它写的行数能是比改变后的1/4左右，在更改配置后，性能排在第三位，只比logback记录的 行数少30%。 二.toString() 在 这轮比拼中记录的是POJO(使用其.toString方法)，同样使用的是线程和时间戳。结果中，对于Log4j2来说，和第一回合差不多，但相比 SLF4J SL有25%的性能提升。Log4j和Logback是并驾齐驱的，位居第三，其吞吐量是SLF4J SL的88%。 三.Throwable 在这轮比拼中，日志引擎记录异常的对象和相关的描述信息。其中Log4j2是位居首位，其性能比SLF4J SL高3倍，SLF4J SL位于第五位。 而Log4j和Logback也是只能排在此轮的冠军之后，记录的行数只大概有冠军的一半，而第二位的反而是JUL，能记录冠军Log4j2的日志量的大概82%。 四.toString()方法比拼 当 处理服务器日志的时候，每一个日志项的上下文（例如线程ID,类的相关上下文，时间戳等等）都是和日志内容一样重要。在之前的测试中，使用的是在大多数日 志文件中常见的标志――线程ID号和时间戳。接下来我们认为值得去分析单纯在日志中使用.toString()方法的性能。 这个时候，Log4j2是赢家（如果改变配置，能获得180%的性能提升），赢出Logback和JUL 大概25%。SL4FJ SL则落败。在每轮的五次测试中，SLF4J SL在启用appenders的时候性能比不启用要好。 Log4j在吞吐量上有15%的增加。JUL在这轮比拼中比不上Log4j和Log4j2，其结果和不使用上下文数据是一样的。 本文的测试代码可以在https://github.com/takipi/the-logging-olympics中下载。 |
