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

发布于01月06日

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

此外，这些点的规则有利于log4j2:

SLF4J强制应用程序记录字符串.如果要记录文本，Log4j 2 API支持记录任何字符序列，但也支持按原样记录任何对象.
Log4j 2 API支持记录消息对象、Java 8 lambda表达式和无垃圾日志(log)记录(它避免在记录CharSequence对象时创建vararg数组和字符串).

推荐答案

Go ahead: program to the log4j2 API instead of slf4j

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

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

是的，保留您的 Select 余地是很好的工程实践.您可能希望稍后更改为另一个日志(log)记录实现.

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

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

The escape valve: log4j-to-slf4j

Log4j2包括一个log4j-to-slf4j桥模块.任何根据Log4j2 API编码的应用程序都可以随时 Select 将支持实现切换到任何符合slf4j的实现.

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

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

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

Disclosure: I contribute to Log4j2.

更新:对log4j2api的编程以某种方式引入了"facade for a facade"，这似乎有些混乱.Log4j2 API和SLF4J在这方面没有区别.

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

Required dependencies	with log4j-api as API	with SLF4J as API
Log4j 2 as implementation	2: log4j-api and log4j-core	4: slf4j, log4j-slf4j-impl, log4j-api, log4j-core
Logback as implementation	4: log4j-api, log4j-to-slf4j, slf4j, Logback	2: slf4j and Logback