记录奥运-当今五大Java记录框架之间的竞赛

开发人员：Takipi会告诉您何时新代码在生产中中断–

Log4J vs SLF4J简单vs Logback vs Java Util日志记录vs LOG4J2

日志记录实际上是每个服务器端应用程序中古老而固有的部分。 这是应用程序以持久且可读的方式输出实时状态的主要方法。 某些应用程序每天可能仅记录几兆字节，而其他应用程序可能会在数小时内记录千兆字节或更多的数据。

由于日志记录通常涉及IO将数据写入磁盘（阻塞或异步）–因此需要付出一定的代价。 在短时间内记录大量数据时，该成本会Swift增加。 我们决定更深入地研究当今一些领先的日志记录引擎的速度。

大多数开发人员记录数据的原因主要有以下三个：

1. 监视 –查看代码在吞吐量，规模，安全性等方面的行为。
2. 调试 –访问导致代码失败的状态（变量，堆栈跟踪…）。 Takipi帮助开发人员调试登台服务器和生产服务器，并了解代码崩溃和线程冻结的原因。
3. 分析 –利用应用程序中的实时数据得出有关其使用方式的结论。

在立面的后面 。 如今，大多数库都在代码的关键点内置了日志，以提供对其操作的可见性。 为了简化此过程并防止不同的库在同一个JVM中使用多种日志记录方法，将代码与底层引擎分离的日志记录Facade成为最重要的问题。 当我们分析Java的前100个软件库时 ，SLF4J成为当今开发人员使用的主要日志记录外观。

比赛

我们决定选择五个当今最杰出的伐木引擎，并观察它们在许多比赛中的表现。 现在，在拿出割炬和干草叉之前，我想澄清一下，并不是要说哪个更好，而是要了解在许多常见的记录任务中引擎之间的吞吐量差异。

参赛者

1. Log4J
2. Log4J2
3. 退回
4. SLF4J简单记录（SLF4J SL）
5. Java Util记录（JUL）

种族

我们想看看引擎如何比较一组标准的日志记录活动。 每个日志记录操作都包括一个时间戳和一个线程ID作为其上下文。

这些是种族：

1. 记录字符串常量
2. 记录POJO的.toString（）值
3. 记录可抛出对象
4. 记录没有时间/ tid上下文的字符串常量

轨道

我们决定每场比赛进行5次预赛，以确定最佳成绩，并衡量完成的伐木作业次数。 在每个测试中，我们都给日志记录引擎一个任务，以便在一分钟内跨10个线程执行（测试分别运行）。 然后，我们取出偏差最大的2个加热点，并对其余3个结果取平均值。

在每个单独的日志记录操作之间，我们给CPU做一些工作来在日志记录操作之间放置一些空间（检查是否有小的随机数是素数）。 引擎均使用其默认配置在SLF4J后面运行。 基准测试是在Amazon m1.large EC2实例上运行的。

结果

要查看完整的数据集– 单击此处 。

第1场–字符串常量

在这场比赛中，引擎正在记录一个字符串常量以及线程和时间戳上下文。 Log4J在这里显然是赢家，能够写的行数比JUL多了270％，比logback多了12.5％，比SLF4J SL多了52％。 值得注意的是，在更改Log4J2的配置之前，可以少写入4X（！）行，而swtich将其提升为＃3，而写入的行数仅比logback少30％。

第2场– .toString（）

在这场比赛中，引擎正在记录POJO（通过其.toString）以及线程和时间戳上下文。 Log4J2排在第1位，与SLF4J SL排在第2位相比，具有25％的优势（变更后），这里的结果更加接近。 Log4J和Logback在＃3位置并驾齐驱，JUL以SLF4J SL的88％吞吐率获得白银。

种族＃3 –投掷

在这场比赛中，引擎正在记录异常对象和描述字符串以及线程和时间戳上下文。 在此竞赛中，Log4J2着火了，与＃5的SLF4J SL相比，在＃1处记录的行数超过行的3倍（！）。

Log4J和Logback也被遗忘了，记录的次数不到我们尊敬的获胜者的一半。 7月排在第二名，与我们的获胜者相比，记录了82％的比赛成绩-不错。

第4场比赛（赤脚跑步）– .toString（）减去上下文

处理服务器日志时，每个条目的上下文（例如，线程ID，类上下文，时间戳等）几乎与条目本身的内容一样重要。 在以前的比赛中，我们使用了在大多数服务器日志条目中可以找到的两个最常见的上下文元素-线程ID和时间戳。 我们认为通过运行.toString（）竞赛而不使用任何引擎的上下文附加程序来分析这些开销非常有趣。

Log4J2是这里的赢家（更改会议后，获得180％的提振），Logback和JUL领先25％。 SLF4J SL紧随其后。 令人困惑的是，在5种不同的加热条件下，SLF4J SL使用添加器的效果要好于不使用添加器的效果（我们很乐意在评论中听到您对此的想法）。

Log4J的最大亮点是吞吐量增加了15％。 JUL在此竞赛中的表现不如Log4J或Log4J2出色，但无论是否包含上下文数据，JUL都能提供几乎完全相同的结果。

我很想听听您的意见和建议。

• 您还可以在GitHub上签出代码。

翻译自: https://www.javacodegeeks.com/2013/12/the-logging-olympics-a-race-between-todays-top-5-java-logging-frameworks.html