是否值得将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，但也支持按原样记录任何Object。
- Log4j 2 API支持记录Message对象，Java 8 lambda表达式和无垃圾日志记录（它避免创建vararg数组并避免在记录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:
- Message API
- 用于延迟记录的Lambdas
- 记录任何对象而不仅仅是字符串
- 无垃圾：避免创建变量或创建字符串在可能的情况下
- 当你完成它们时，CloseableThreadContext会自动从MDC中删除项目
- 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
（有关详细信息，请参阅 SLF4J中未提供的10个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屋！
