是否值得将slf4j与log4j2

Question

我无法决定是否使用slf4j与log4j2。基于在线帖子，看起来不会有任何性能影响，但它确实是必需的。

这些点也有利于log4j2：

• SLF4J强制您的应用程序记录字符串。如果要记录文本，Log4j 2 API支持记录任何CharSequence，但也支持按原样记录任何Object。
• Log4j 2 API支持记录Message对象，Java 8 lambda表达式和无垃圾日志记录（它避免了创建vararg数组并避免在记录CharSequence对象时创建字符串）。

Answer 1

继续：编程到log4j2 API而不是slf4j

安全：Log4j2 API提供与slf4j完全相同的保证 - 以及更多。

现在Log4j2本身被分成了API和一个实现模块，使用SLF4J已经没有任何价值了。

是的，保持选项开放是一种很好的工程实践。您可能希望稍后更改为另一个日志记录实现。

在过去10年左右的时间里，在应用程序中构建这样的灵活性意味着使用像SLF4J这样的包装器API。这种灵活性并非免费提供：此方法的缺点是您的应用程序无法使用底层日志记录库的更丰富的功能集。

Log4j2提供的解决方案并不要求您的应用程序仅限于最低公分母。

逃生阀：log4j-to-slf4j

Log4j2包含log4j-to-slf4j桥接模块。任何针对Log4j2 API编码的应用程序都可以选择随时将支持实现切换到任何符合slf4j的实现。

正如问题所述，与使用像slf4j这样的包装器API相比，使用Log4j2 API可以直接提供更多功能，并且具有一些非功能性优势：

• 消息API
• Lambdas for lazy logging
• 记录任何对象而不仅仅是字符串
• 无垃圾：避免创建varargs或尽可能创建字符串
• CloseableThreadContext会在您完成后自动从MDC中删除项目

（有关详细信息，请参阅10 Log4j2 API features not available in SLF4J。）

应用程序可以安全地使用Log4j2 API的这些丰富功能，而无需锁定到本机Log4j2核心实现。

SLF4J仍然是您的安全阀，它并不意味着您的应用程序应该再对SLF4J API进行编码。

披露：我参与了Log4j2。

更新：似乎有些混淆，Log4j2 API的编程以某种方式引入了外观和＃34;的外观。 Log4j2 API和SLF4J在这方面没有区别。

使用本机实现时，两个API都需要2个依赖项，而非本机实现需要4个依赖项。 SLF4J和Log4j2 API在这方面是相同的。例如：

Answer 2

有很多考虑因素使日志记录“比乍一看更复杂”，（因此是数十年的激烈内斗！）。

关注点分离

在一天结束时，代码“发送日志数据”并且该数据“最终到达某处”。但它的最终位置取决于收集它的目的。使情况大大复杂化的是，现代软件由各种组件组成，而且它们都可能需要记录日志。

让我们考虑一个最坏的情况：所有组件都使用 System.out#println(String)。至少所有语句都是按执行顺序排列的，但要辨别哪个组件生成了每条输出可能并不容易。并且某些组件对于它们使用的上下文可能过于冗长。

让我们考虑下一个最坏的情况：所有组件都做出自己的安排来控制它们的日志记录行为和目的地。管理员可能必须为单个软件配置数十个日志系统。现在日志语句不在一起并且它们乱序。希望他们都有一致的时间戳策略！

我们想要介于两者之间的东西：代码可以说“记录这个”并且管理员可以控制它结束的地方。

过于简短的历史

进入 Log4J v1，它解决了“levels”、“appenders”、“filters”、“layouts”和“contexts”等概念的问题……一种由分层“记录器命名空间”（包括一种方式）支持的概念架构自然地利用 Java 包命名空间），以及便于管理的配置机制。

那一切都很好……只要软件中的所有组件都依赖于相同的版本！曾经有一段时间，这些事情都在不断变化。 SLF4J 的主要贡献是从组件开发人员的角度将这些概念“强化”为一个稳定的 API，而不影响管理员完成他们部分工作的选项。图书馆可以依赖 SLF4J 'facade'，期望他们只在堆栈中调用几次就可以与'实现'交谈。管理员可以选择适合他们的方式将日志组合成他们关心的连贯记录。

（当你的软件在容器中运行时就更复杂了，容器有自己的日志需求，而你甚至不是在容器中运行的同一个应用程序......Tomcat的JULI日志——用于自己的内部日志记录 - “避开”在类加载器子上下文中运行的应用程序。）

Java Community Process 神秘地蔑视 Log4J 的工作，决定在 java.util.logging 中实现几乎相同的概念架构，但可以说在细节上的灵活性较低。然而，由于 j.u.l 本质上是 SLF4J 语义丰富性的一个子集，所以很容易让 SLF4J 成为 j.u.l 的门面。

Apache 的 Commons Util Logging 可能不是很有必要。 Ceki 自己的 Logback 引入了当时 Log4J v1 没有的管理功能 - 不仅是 SLF4J 的实现并解决了所有那些非常真实的类加载器问题，而且还为管理员提供了具有一些吸引人的功能的称职实现。

针对不同情况的日志

但是日志记录是在许多不同的上下文中完成的。在不过度阻塞线程的情况下将这些消息重击到超慢 I/O，并且除非需要，否则不支付计算日志消息的代价，并在多线程上下文中生成连贯的日志……这些都很重要。 （这就是不经常使用 java.util.logging 的原因！）。

有时，所需的优化会影响概念架构，而这反过来又会影响开发者端 API。例如，如果日志消息由于过滤而最终成为无操作，则闭包提供的机会肯定会加快速度。需要考虑 SLF4J.next 或其他一些 API 来使用该功能，并且不需要将 Log4J2 排除在此决定之外。由于 API 部分是 SLF4J 提供的概念上的超集，因此很容易使它成为 SLF4J 及其下的那些实现的外观……或者更直接地连接到管理员喜欢的东西。

对于应用程序开发人员来说，这真的无关紧要，只要最终管理员选择了一个日志记录工具，并且所有组件都可以注销该工具。如果该设施可以通过 SLF4J 和 Log4J2-the-API 接受消息，那很棒。 Log4J2-the-implementation 就是这样做的。您也可以拥有自己的蛋糕，也可以吃它：您的应用程序可以享受 Log4J2-the-API 提供的机会，同时仍然使用 SLF4J 充分满足的库。如果管理员蔑视 Log4J2-the-implementation（尽管从任何角度都很难看出他们为什么会这样做），那么他们可以使用任何已经支持 SLF4J 的东西，而无需等待日志实现支持 Log4J2-the-API。你可以吃蛋糕吃。

对于库开发人员来说，这更像是一个问题。安全路径是 SLF4J，因为它被广泛采用。如果日志记录对您的库的成功至关重要……特别是如果它是多线程的，则日志语句的生成可能会很昂贵，如果它们最终不会被消耗，则最好省略处理，如果有要处理大量日志语句，性能至关重要，并且您的用户可能会欣赏 Log4J2-实现的好处，然后执行 Log4J2。但是您也不会因为继续使用 SLF4J 而从您的用户那里窃取机会。如果愿意，管理员仍然可以使用 Log4J-the-implementation。

底线

如果您想要 Log4J2 提供的功能，请选择它们。如果你不需要它们，SLF4J 是一个成熟、稳定的接口，有很多支持。 SLF4J 仍然是开源基础设施的重要组成部分。 Ceki 为社区提供了很好的服务，作为回报，很多抱怨。

但最终还是由有能力的实现支持的丰富 API 盛行。今天的稳定就是明天的停滞。细化的过程一直在进行。不用下车，只要去你想去的地方。