将 slf4j 与 log4j2 一起使用是否值得 [英] Is it worth to use slf4j with log4j2

问题描述

我无法决定是否将 slf4j 与 log4j2 一起使用.根据在线帖子，它看起来不会对性能造成任何影响，但它真的是必需的.

I am not able to decide whether to use slf4j or not with log4j2. Based on online posts, does not look like it will have any performance hit but is it really required.

这些点也有利于 log4j2:

Also these points rule in favor of log4j2:

• SLF4J 强制您的应用程序记录字符串.如果您想记录文本，Log4j 2 API 支持记录任何 CharSequence，但也支持按原样记录任何对象.
• Log4j 2 API 支持记录 Message 对象、Java 8 lambda 表达式和无垃圾记录(它避免在记录 CharSequence 对象时创建可变参数数组并避免创建字符串).

推荐答案

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

它是安全的:Log4j2 API 提供与 slf4j 完全相同的保证 - 以及更多.

既然Log4j2本身被分成了API和实现模块，那么使用SLF4J就没有任何价值了.

Now that Log4j2 itself is separated into an API and an implementation module, there is no longer any value in using SLF4J.

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

Yes, it is good engineering practice to keep your options open. You may want to change to another logging implementation later.

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

For the last 10 years or so, building such flexibility in your application meant using a wrapper API like SLF4J. This flexibility doesn't come for free though: the disadvantage of this approach is that your application cannot use the richer feature set of the underlying logging library.

Log4j2 提供了一种解决方案，它不需要将您的应用程序限制为最小公分母.

Log4j2 offers a solution that doesn't require that your application is restricted to the lowest common denominator.

逃生阀:log4j-to-slf4j

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

Log4j2 includes a log4j-to-slf4j bridge module. Any application coded against the Log4j2 API can choose to switch the backing implementation to any slf4j-compliant implementation at any time.

如问题中所述，与使用 slf4j 之类的包装器 API 相比，直接使用 Log4j2 API 可提供更多功能并具有一些非功能性优势:

As mentioned in the question, using the Log4j2 API directly offers more functionality and has some non-functional advantages versus using a wrapper API like slf4j:

• 消息接口
• 用于延迟日志记录的 Lambda
• 记录任何对象而不仅仅是字符串
• 无垃圾:尽可能避免创建可变参数或创建字符串
• CloseableThreadContext 会在您完成项目后自动从 MDC 中删除它们

(有关详细信息，请参阅 10 个 SLF4J 中不可用的 Log4j2 API 功能.)

(See 10 Log4j2 API features not available in SLF4J for more details.)

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

Applications can safely use these rich features of the Log4j2 API without being locked in to the native Log4j2 core implementation.

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

SLF4J is still your safety valve, it just doesn't mean your application should code against the SLF4J API anymore.

披露:我为 Log4j2 做出了贡献.

更新:对 Log4j2 API 进行编程以某种方式引入了外观的外观"似乎有些混乱.Log4j2 API 和 SLF4J 在这方面没有区别.

Update: There seems to be some confusion that programming to the Log4j2 API somehow introduces a "facade for a facade". There is no difference in this respect between the Log4j2 API and SLF4J.

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

Both APIs require 2 dependencies when using a native implementation, and 4 dependencies for a non-native implementation. SLF4J and the Log4j2 API are identical in this respect. For example:

这篇关于将 slf4j 与 log4j2 一起使用是否值得的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！