新项目是否应该使用 logback 而不是 log4j 作为日志框架？
或者换个说法：'logback 比 log4j 好吗（把 logback 的 SLF4J-'feature' 放在旁边）？'
【问题讨论】：
标签： java logging log4j logback
Logback 更多 Java EE 意识：
一般来说（从代码到文档），它牢记容器——多个应用程序如何共存、类加载器如何实现等。记录器的上下文、JNDI、JMX 配置等。
从开发者的角度来看几乎相同，Logback 补充道 参数化日志（无需使用 if(logger.isDebugEnabled()) 来避免字符串连接开销）
Log4j – 唯一的优点是旧的 JVM 支持，小 (IMO) NDC (Logback only MDC)，一些扩展。例如我为 Log4j 写了 configureAndWatch 扩展，Logback 没有这样的东西
【讨论】：
作者（Logback 和 Log4j 的作者）在http://logback.qos.ch/reasonsToSwitch.html 上列出了更改的原因。
这里有一些让我印象深刻的；
更快的实施
基于我们之前在 log4j 上的工作， logback 内部结构已经 重写执行大约十次 在某些关键执行上更快 路径。不仅是 logback 组件速度更快，它们有一个 内存占用也更小。
自动重新加载配置 文件
logback-classic 可以自动 重新加载其配置文件 修改。扫描过程是 既快速又安全，因为它没有 涉及创建一个单独的 用于扫描的线程。这项技术 微妙确保 logback 播放 在应用服务器和 更一般地在 JEE 内 环境。
带有打包数据的堆栈跟踪
当 logback 打印异常时， 堆栈跟踪将包括包装 数据。这是一个示例堆栈跟踪 由 logback-demo 生成 网络应用程序。
14:28:48.835 [btpool0-7] 信息
c.q.l.demo.prime.PrimeAction - 99 是
不是有效值
java.lang.Exception: 99 无效
在
ch.qos.logback.demo.prime.PrimeAction.execute(PrimeAction.java:28)
[类/：na]在
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
[struts-1.2.9.jar:1.2.9] 在
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
[struts-1.2.9.jar:1.2.9] 在
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
[struts-1.2.9.jar:1.2.9] 在
javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
[servlet-api-2.5-6.1.12.jar:6.1.12]
在
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502)
[码头-6.1.12.jar:6.1.12] 在
ch.qos.logback.demo.UserServletFilter.doFilter(UserServletFilter.java:44)
[类/：na]在
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115)
[码头-6.1.12.jar:6.1.12] 在
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:361)
[码头-6.1.12.jar:6.1.12] 在
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417)
[码头-6.1.12.jar:6.1.12] 在
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
[jetty-6.1.12.jar:6.1.12]
从上面你可以认出 应用程序正在使用 Struts 版本 1.2.9 并部署在 码头版本 6.1.12。因此，堆栈 痕迹会迅速通知读者 关于在 例外，但也包和 他们所属的包版本。什么时候 你的客户给你发了一堆 跟踪，作为开发人员你不会 不再需要让他们送你 有关版本的信息 他们正在使用的软件包。这 信息将成为堆栈的一部分 痕迹。请参阅“%xThrowable”转换 详细说明。
这个功能对 一些用户错误的观点 将其视为他们 IDE 的一项功能。
自动删除旧的日志档案
通过设置 maxHistory 属性 TimeBasedRollingPolicy 或 SizeAndTimeBasedFNATP，你可以 控制最大数量 归档文件。如果你的滚动 政策要求每月展期和 你想保留一年的价值 日志，只需设置 maxHistory 属性为 12。存档的日志文件 超过 12 个月 自动删除。
那里可能存在偏见，但同一个人确实编写了两个框架，如果他说使用 Logback 而不是 Log4j，他可能值得一听。
【讨论】：
您应该使用 SLF4J+Logback 进行日志记录。
它提供了简洁的功能，例如参数化消息和（与公共日志记录相反）映射诊断上下文（MDC、javadoc、documentation）。
使用 SLF4J 使得日志后端可以以一种非常优雅的方式进行交换。
此外，其他日志框架的 SLF4J supports bridging 到您将使用的实际 SLF4J 实现，因此来自第三方软件的日志事件将显示在您的统一日志中 - 除了 java.util.logging 可以不能像其他日志框架一样被桥接。
在 SLF4JBridgeHandler 的javadocs 中解释了桥接 jul。
我在几个项目中使用 SLF4J+Logback 组合的体验非常好，而 LOG4J 开发几乎停滞不前。
SLF4J 还有以下缺点：
【讨论】：
我会在所有情况下使用 slf4j 进行日志记录。这允许您在部署时而不是代码时选择要使用的实际日志记录后端。
事实证明，这对我来说非常有价值。它允许我在旧 JVM 中使用 log4j，在 1.5+ JVM 中使用 logback，如果需要，还可以使用 java.util.logging。
【讨论】：
我认为您的决定应该与您在使用 log4j 或 Jakarta Commons Logging 之间做出决定时的决定相同 - 您是否正在开发一个将包含在其他应用程序中的库？如果是这样，那么强制您库的用户也使用您选择的日志库似乎不公平。
如果答案是否定的，我会选择更容易添加且您更满意的内容。听起来 logback 和 log4j 一样可扩展和可靠，所以如果你觉得使用起来很舒服，那就继续吧。
【讨论】：
最初的 log4j 和 logback 是由同一个人设计和实现的。
一些开源工具使用了 SLF4J。我没有看到这个工具有任何重大缺陷。因此，除非您的代码库中有很多 log4j 扩展，否则我会继续使用 logback。
【讨论】：
我对 SLF4J 不熟悉，我只对 logback 进行了简要的了解，但我想到了两件事。
首先，您为什么将工具排除在检查之外？我认为保持开放的心态并检查所有可能性以选择最佳方案非常重要。
其次，我认为在某些项目中，一种工具比另一种工具更好，而在不同的项目中可能正好相反。我不认为一种工具总是比另一种工具更好。毕竟，没有灵丹妙药。
回答您的问题 - 是和否。这取决于项目，以及团队对一种工具的熟悉程度。如果整个团队都非常满意，我不会说“不要使用 log4j”，它满足所有需求，而且 logback 不提供我们完成任务所需的任何东西。
【讨论】：
log4j 和 logback 对于任何两个库、语言、IDE 等，然后查看结果！太奇妙了！ :D