我无法决定是否将 slf4j 与 log4j2 一起使用。根据在线帖子,看起来它不会对性能造成任何影响,但它确实是必需的。
这些点也有利于 log4j2:
- SLF4J 强制您的应用程序记录字符串。如果您想记录文本,Log4j 2 API 支持记录任何 CharSequence,但也支持按原样记录任何对象。
- Log4j 2 API 支持记录 Message 对象、Java 8 lambda 表达式和无垃圾日志记录(它避免创建 vararg 数组并避免在记录 CharSequence 对象时创建字符串)。
最佳答案
继续:编程到 log4j2 API 而不是 slf4j
它是安全的:Log4j2 API 提供与 slf4j 完全相同的保证 - 甚至更多。
既然 Log4j2 本身被分离为一个 API 和一个实现模块,那么使用 SLF4J 已经没有任何值(value)了。
是的,让您的选择保持开放是一种良好的工程实践。您可能希望稍后更改为另一个日志记录实现。
在过去 10 年左右的时间里,在您的应用程序中构建这种灵 active 意味着使用像 SLF4J 这样的包装 API。但是,这种灵 active 并不是免费的:这种方法的缺点是您的应用程序无法使用底层日志库的更丰富的功能集。
Log4j2 提供了一种解决方案,不需要您的应用程序被限制在最低公分母上。
排气阀:log4j-to-slf4j
Log4j2 包含一个 log4j-to-slf4j
桥接模块。任何针对 Log4j2 API 编码的应用程序都可以随时选择将支持实现切换到任何符合 slf4j 的实现。
正如问题中提到的,与使用像 slf4j 这样的包装 API 相比,直接使用 Log4j2 API 提供了更多功能,并且具有一些非功能优势:
- 消息 API
- 用于延迟日志记录的 Lambdas
- 记录任何对象,而不仅仅是字符串
- 无垃圾:尽可能避免创建可变参数或创建字符串
- CloseableThreadContext 会在您完成后自动从 MDC 中移除项目
(有关详细信息,请参阅 10 Log4j2 API features not available in SLF4J。)
应用程序可以安全地使用 Log4j2 API 的这些丰富功能,而不会被锁定在原生 Log4j2 核心实现中。
SLF4J 仍然是您的安全阀,但这并不意味着您的应用程序应该再针对 SLF4J API 进行编码。
披露:我为 Log4j2 做出贡献。
更新:Log4j2 API 的编程以某种方式引入了“外观的外观”似乎有些困惑。 Log4j2 API 和 SLF4J 在这方面没有区别。
两个 API 在使用原生实现时需要 2 个依赖项,而对于非原生实现则需要 4 个依赖项。 SLF4J 和 Log4j2 API 在这方面是相同的。例如:
必需的依赖项 | 使用 log4j-api 作为 API | 使用 SLF4J 作为 API |
---|---|---|
Log4j 2 作为实现 | 2: log4j-api 和 log4j-core | 4: slf4j, log4j-slf4j-impl, log4j-api, log4j-core |
Logback 作为实现 | 4: log4j-api, log4j-to-slf4j, slf4j, Logback | 2: slf4j 和 Logback |
关于java - 将 slf4j 与 log4j2 一起使用是否值得,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/41498021/