新项目是否应使用logback而不是log4j作为日志框架？
或者换句话说：'logback是否比log4j好（留下SLF4J -'feature'的logback）？'
答案 0 :(得分：81)
您应该使用SLF4J + Logback进行记录。
它提供了一些简洁的功能，如参数化消息和（与公共记录相比）映射诊断上下文（MDC，javadoc，documentation）。
使用SLF4J可以非常优雅地交换日志后端。
此外，SLF4J supports bridging其他日志框架到您将使用的实际SLF4J实现，因此来自第三方软件的日志记录事件将显示在您的统一日志中 - 除了java.util.logging之外不能像其他日志框架那样桥接。
在SLF4JBridgeHandler的javadocs中解释了桥接jul。
我在几个项目中使用SLF4J + Logback组合方面有很好的经验，而且LOG4J开发几乎停滞不前。
SLF4J还有以下缺点：
答案 1 :(得分：20)
作者（Logback和Log4j）都有一个在http://logback.qos.ch/reasonsToSwitch.html更改的原因列表。
以下是一些突然出现的事情;
加快实施
基于我们之前关于log4j的工作， logback内部已经 重写大约十次 某些关键执行速度更快 路径。不仅是logback 组件更快，他们有一个 内存占用也较小。
自动重新加载配置 文件
Logback-classic可以自动进行 重新加载其配置文件 修改。扫描过程是 快速和安全，因为它没有 涉及创建一个单独的 用于扫描的线程。这个技术 微妙确保回归播放 在应用程序服务器和 更常见的是在JEE内 环境。
使用打包数据堆栈跟踪
当logback打印异常时， 堆栈跟踪将包括包装 数据。这是一个示例堆栈跟踪 由logback-demo生成 网络的应用程序。
14：28：48.835 [btpool0-7] INFO
c.q.l.demo.prime.PrimeAction - 99是
不是有效的价值
java.lang.Exception：99无效
在
ch.qos.logback.demo.prime.PrimeAction.execute（PrimeAction.java:28）
[classes /：na] at
org.apache.struts.action.RequestProcessor.processActionPerform（RequestProcessor.java:431）
[struts-1.2.9.jar：1.2.9] at
org.apache.struts.action.RequestProcessor.process（RequestProcessor.java:236）
[struts-1.2.9.jar：1.2.9] at
org.apache.struts.action.ActionServlet.doPost（ActionServlet.java:432）
[struts-1.2.9.jar：1.2.9] at
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）
[jetty-6.1.12.jar：6.1.12] at
ch.qos.logback.demo.UserServletFilter.doFilter（UserServletFilter.java:44）
[classes /：na] at
org.mortbay.jetty.servlet.ServletHandler $ CachedChain.doFilter（ServletHandler.java:1115）
[jetty-6.1.12.jar：6.1.12] at
org.mortbay.jetty.servlet.ServletHandler.handle（ServletHandler.java:361）
[jetty-6.1.12.jar：6.1.12] at
org.mortbay.jetty.webapp.WebAppContext.handle（WebAppContext.java:417）
[jetty-6.1.12.jar：6.1.12] at
org.mortbay.jetty.handler.ContextHandlerCollection.handle（ContextHandlerCollection.java:230）
[码头-6.1.12.jar：6.1.12]
从上面，你可以认出来 该应用程序正在使用Struts 版本1.2.9并部署在 码头版本6.1.12。因此，堆栈 痕迹会很快通知读者 关于invervening in the classes的课程 例外，但包和 它们所属的包版本。什么时候 你的客户发给你一个堆栈 跟踪，作为开发者你不会 更长的时间需要让他们发送给你 有关版本的信息 他们正在使用的包。该 信息将成为堆栈的一部分 跟踪。请参阅“％xThrowable”转换 有关详细信息的话。
此功能非常有用 一些用户错误的观点 将其视为IDE的一项功能。
自动删除旧日志存档
通过设置的maxHistory属性 TimeBasedRollingPolicy或 SizeAndTimeBasedFNATP，你可以 控制最大数量 存档文件。如果你滚动 政策要求每月翻转和 你希望保持一年的价值 日志，只需设置maxHistory即可 属性为12.存档的日志文件 将超过12个月 自动删除。
可能存在偏见，但同一个人确实编写了两个框架，如果他说使用Logback over Log4j，他可能值得一听。
答案 2 :(得分：10)
我会使用slf4j记录所有情况。这允许您在部署时而不是代码时选择要使用的实际日志记录后端。
这对我来说非常有价值。它允许我在旧的JVM中使用log4j，并在1.5+ JVM中使用logback，如果需要也可以使用java.util.logging。
答案 3 :(得分：2)
Logback更多Java EE意识：
一般来说（从代码到文档）它牢记容器 - 多个应用程序如何共存，类加载器如何实现等。记录器，JNDI，JMX配置等的上下文等。
Log4j - 只有巨型加号是旧的JVM支持，小型（IMO） NDC（仅Logback MDC），一些扩展。例如，我为Log4j编写了configureAndWatch的扩展，对于Logback
没有这样的东西答案 4 :(得分：1)
原始的log4j和logback是由同一个人设计和实现的。
一些开源工具使用过SLF4J。我认为这个工具没有任何重大缺陷。因此，除非你的代码库中有很多log4j的扩展，否则我会继续进行logback。
答案 5 :(得分：1)
我认为您的决定应该归结为使用log4j或Jakarta Commons Logging时决定的那个 - 您是否正在开发一个将包含在其他应用程序中的库？如果是这样，那么强迫您的库用户也使用您选择的日志库似乎是不公平的。
如果答案是否定的，我会选择更简单的方式和更舒适的方式。听起来像logback和log4j一样可扩展且可靠，所以如果你习惯使用它，请继续。
答案 6 :(得分：-3)
我不熟悉SLF4J，我只是简单介绍一下logback，但有两件事情会浮现在脑海中。
首先，为什么要从检查中排除工具？我认为保持开放的思想并研究选择最佳选择的所有可能性非常重要。
其次，我认为在某些项目中，一个工具比另一个工具更好，而在另一个项目中则相反。我不认为一个工具总是比另一个工具更好。毕竟，没有银弹。
回答你的问题 - 是的，不是。这取决于项目，以及团队对一个工具的熟悉程度。我不会说“不要使用log4j”如果整个团队对它非常满意，它会满足所有需求，并且logback不提供完成任务所需的任何东西。