Java 是否值得将 slf4j 与 log4j2 一起使用

Is it worth to use slf4j with log4j2

提问by Andy897

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.

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

Also these points rule in favor of log4j2:

这些点也有利于 log4j2：

• SLF4J forces your application to log Strings. The Log4j 2 API supports logging any CharSequence if you want to log text, but also supports logging any Object as is.
• The Log4j 2 API offers support for logging Message objects, Java 8 lambda expressions and garbage-free logging (it avoids creating vararg arrays and avoids creating Strings when logging CharSequence objects).

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

采纳答案by Remko Popma

Go ahead: program to the log4j2 API instead of slf4j

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

It's safe: the Log4j2 API offers the exact same guarantees as slf4j - and more.

它是安全的：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.

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

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

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

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.

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

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

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

The escape valve: log4j-to-slf4j

逃生阀：log4j-to-slf4j

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

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

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:

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

• Message API
• Lambdas for lazy logging
• Log any Object instead of just Strings
• Garbage-free: avoid creating varargs or creating Strings where possible
• CloseableThreadContext automatically removes items from the MDC when you're finished with them

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

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

（有关更多详细信息，请参阅SLF4J 中不可用的 10 个 Log4j2 API 功能。）

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

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

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

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

---

---

Disclosure: I contribute to Log4j2.

披露：我为 Log4j2 做出了贡献。

---

---

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.

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

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:

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