新的项目应该使用logback而不是log4j？
新项目应该使用logback而不是log4j作为日志框架？
或者换句话说：“logback比log4j更好（离开SLF4J-”logback的特性“旁边）？
您应该使用SLF4J + Logback进行日志logging。
它提供了整洁的function，如参数化消息和（与公用日志logging相反）映射诊断上下文（MDC， javadoc ， 文档 ）。
使用SLF4J使日志后端以一种相当优雅的方式交换。
此外，SLF4J 支持将其他日志框架桥接到您将使用的实际SLF4J实现，因此从第三方软件logging事件将显示在您的统一日志中 – 不能桥接的java.util.logging除外与其他日志框架相同的方式。
桥接JUL在SLF4JBridgeHandler的javadoc中解释。
我在几个项目中使用SLF4J + Logback组合的经验非常丰富，而且LOG4J的开发几乎停滞不前。
SLF4J还有以下缺点：
- 它不支持可变参数以保持与Java <1.5的兼容性
- 它不支持同时使用参数化消息和exception。
- 它不包含对LOG4J具有的嵌套诊断上下文（NDC， javadoc ）的支持。
作者（Logback和Log4j）都有一个在http://logback.qos.ch/reasonsToSwitch.html上更改原因的列表。;
这里有一些突出在我身上;
-
更快的实施
根据我们之前关于log4j的工作，logback内部部分已被重写，在某些关键执行path上执行速度快了十倍。 logback组件不仅更快，而且还具有更小的内存占用量。
-
自动重新加载configuration文件
Logback-classic可以在修改后自动重新加载其configuration文件。 扫描过程既快速又安全，因为它不涉及创build单独的扫描线程。 这种技术上的细微之处确保了logback在应用程序服务器中以及在JEE环境中更普遍的运行。
-
堆栈跟踪包装数据
当logback打印exception时，堆栈跟踪将包含打包数据。 以下是由logback-demonetworking应用程序生成的示例堆栈跟踪。
14：28：48.835 [btpool0-7] INFO cqldemo.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 .jar：1.2.9]在org.apache.struts.action的org.apache.struts.action.RequestProcessor.process（RequestProcessor.java:236）[struts-1.2.9.jar：1.2.9]。 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 ）org.mortbay.jetty.servlet.ServletHandler上的[classes /：na] $ 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）[jetty-6.1.12.jar：6.1.12]从上面可以看出，应用程序正在使用Struts版本1.2.9，并且已经在jetty版本6.1.12下部署了。 因此，堆栈跟踪将迅速通知读者exception中的类，而且还包括它们所属的包和版本。 当您的客户向您发送堆栈跟踪信息时，作为开发人员，您不再需要让他们向您发送有关正在使用的程序包版本的信息。 这些信息将成为堆栈跟踪的一部分。 有关详细信息，请参阅“％xThrowable”转换字。
这个特性对于一些用户错误地认为它是IDE的一个特性非常有用。
-
自动删除旧的日志档案
通过设置TimeBasedRollingPolicy或SizeAndTimeBasedFNATP的maxHistory属性，可以控制最大数量的归档文件。 如果您的滚动策略要求每月滚动，并且希望保留一年的日志，则只需将maxHistory属性设置为12.超过12个月的归档日志文件将被自动删除。
那里可能有一个偏差，但同一个人写了两个框架，如果他说使用Log4j Log4j他可能值得听。
我会使用slf4jlogging所有情况。 这使您可以在部署时而不是代码时select要使用的实际日志logging后端。
这已经certificate对我来说非常有价值。 它允许我在旧的JVM中使用log4j，并在1.5+ JVM中使用logback，如果需要的话也使用java.util.logging。
Logback更多Java EE认识：
一般来说（从代码到文档），它始终牢记容器 – 多个应用程序如何共存，类加载器是如何实现的等等。logging器的上下文，包含JNDI，JMXconfiguration等。
从开发人员的预期几乎相同，Logback添加了参数化日志logging（不需要使用if（logger.isDebugEnabled（））来避免string连接开销）
Log4j – 只有巨大的加号是旧的JVM支持，小的（IMO）NDC（Logback only MDC），一些扩展。 例如，我为Log4j写了configureAndWatch的扩展，没有这样的Logback
原来的log4j和logback是由同一个人devise和实现的。
几个开源工具已经使用SLF4J。 我没有看到这个工具的任何重大缺陷。 所以除非你在代码库中有很多的log4j扩展，否则我会继续使用logback。
如果你决定使用log4j还是Jakarta Commons Logging，你是否会开发一个将被包含在其他应用程序中的库？ 如果是这样，那么迫使你的图书馆的用户也使用你select的日志库是不公平的。
如果答案是否定的，那么我只会select更简单的添加以及更舒适的方法。 听起来像logback就像log4j一样具有可扩展性和可靠性，所以如果您使用它的话，请继续。
我对SLF4J并不熟悉，我只是简单地看了一下logback，但是有两点让我想起来。
首先，你为什么排除一个工具检查？ 我认为保持开放的心态并考虑select最好的select是很重要的。
其次，我认为在一些项目中，一种工具比另一种工具更好，而在另一个项目中则相反。 我不认为一个工具总是比另一个工具更好。 毕竟， 没有银弹 。
回答你的问题 – 是的，没有。 这取决于项目，以及团队对一个工具的熟悉程度。 如果整个团队非常满意，我不会说“不要使用log4j”，它可以满足所有需求，而logback不提供任何我们需要完成的任务。
