slf4j和log4j2一起使用是否值得

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

同样，以下几点有利于log4j2：

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

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

是安全的：Log4j2 API提供与slf4j完全相同的保证-甚至更多。

现在，Log4j2本身已分为一个API和一个实现模块，使用SLF4J不再具有任何价值。

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

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

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

溢流阀：log4j-sf4j

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

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

• 讯息API
• Lambda用于懒惰的日志记录
• 记录任何对象而不只是字符串
• 免垃圾：尽可能避免创建变量或字符串
• 完成后，CloseableThreadContext会自动从MDC中删除项目

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

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

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

披露：我为Log4j2做贡献。

更新：似乎有些困惑，对Log4j2 API进行编程会以某种方式引入“门面外观”。Log4j2 API和SLF4J在这方面没有区别。

使用本地实现时，两个API都需要2个依赖关系，而对于非本地实现，这两个API都需要4个依赖关系。在这方面，SLF4J和Log4j2 API相同。例如：