新项目应该使用logback而不是log4j吗？[关闭]

新项目应该使用logback代替log4j作为日志框架吗？

或换句话说：“ logback是否比log4j好（将logback的SLF4J-'feature'放在旁边）？”

您应该使用SLF4J + Logback进行日志记录。

它提供了整齐的功能，例如参数化消息和（与commons-logging相比）Mapped Diagnostic Context（MDC，javadoc，documentation）。

使用SLF4J可以使日志记录后端以一种非常优雅的方式互换。

此外，SLF4J支持将其他日志记录框架桥接到您将要使用的实际SLF4J实现，因此来自第三方软件的日志记录事件将显示在您的统一日志中-java.util.logging不能桥接与其他日志记录框架相同。

SLF4JBridgeHandler的javadocs中解释了桥接jul 。

我在多个项目中使用SLF4J + Logback组合的经验非常好，并且LOG4J的开发工作几乎停滞了。

SLF4J还有以下缺点：

• 它不支持varargs与Java <1.5兼容
• 它不支持同时使用参数化消息和异常。
• 它不包含对LOG4J具有的嵌套诊断上下文（NDC，javadoc）的支持。

作者（包括Logback和Log4j）在http://logback.qos.ch/reasonsToSwitch.html上有更改原因的列表。

以下是一些对我不利的事情；

• 更快的实施

  根据我们之前在log4j上所做的工作，已重新编写了logback内部组件，使其在某些关键执行路径上的执行速度快大约十倍。Logback组件不仅速度更快，而且内存占用也较小。

• 自动重载配置文件

  经典的Logback可以在修改后自动重新加载其配置文件。扫描过程既快速又安全，因为它不涉及创建单独的扫描线程。这种技术上的微妙之处可确保在应用程序服务器中以及更一般而言在JEE环境中可以很好地执行回滚。

• 带有包装数据的堆栈跟踪

  当logback打印异常时，堆栈跟踪将包括打包数据。这是由logback-demo Web应用程序生成的示例堆栈跟踪。

  14：28：48.835 [btpool0-7]信息cqldemo.prime.PrimeAction-99不是有效值java.lang.Exception：99
  在ch.qos.logback.demo.prime.PrimeAction.execute（PrimeAction.java ：28）[classes /：na]在org.apache.struts.action.RequestProcessor.processActionPerform（RequestProcessor.java:431）[struts-1.2.9.jar：1.2.9]在org.apache.struts.action中。 org.apache.struts.action.ActionServlet.doPost（ActionServlet.java:432）上的RequestProcessor.process（RequestProcessor.java:236）[struts-1.2.9.jar：1.2.9] [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）[jetty-6.1.12.jar：6.1.12]在ch.qos.logback.demo.UserServletFilter.doFilter（UserServletFilter.java:44 ），位于org.mortbay.jetty.servlet.ServletHandler $ CachedChain.doFilter（ServletHandler.java:1115）的[classes /：na]，位于org.mortbay.jetty.servlet的[jetty-6.1.12.jar：6.1.12]。 org.mortbay.jetty.webapp.WebAppContext.handle（WebAppContext.java:417）上的ServletHandler.handle（ServletHandler.java:361）[jetty-6.1.12.jar：6.1.12] [jetty-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的功能，因此该功能可能非常有用。

• 自动删除旧的日志档案

  通过设置TimeBasedRollingPolicy或SizeAndTimeBasedFNATP的maxHistory属性，可以控制已存档文件的最大数量。如果您的滚动策略要求每月进行一次滚动并且您希望保留一年的日志，只需将maxHistory属性设置为12。早于12个月的归档日志文件将被自动删除。

那里可能会有偏差，但是同一个人确实编写了两个框架，如果他说在Log4j上使用Logback，那么他可能值得一听。

在所有情况下，我都会使用slf4j进行记录。这样，您可以在部署时而不是代码时选择要使用的实际日志记录后端。

事实证明，这对我来说非常有价值。它允许我在旧JVM的环境中使用log4j，在1.5+ JVM的环境中使用logback，如果需要，还可以使用java.util.logging。

重新登录Java EE意识更多：
从代码到文档，通常要牢记容器-多个应用程序共存，类加载器如何实现等。记录器的上下文，JNDI，JMX配置等。

与开发人员的预期几乎相同，Logback添加了参数化日志记录（无需使用if（logger.isDebugEnabled（））来避免字符串连接开销）

Log4j –唯一的优点是旧的JVM支持，小型（IMO）NDC（仅Logback MDC）和一些扩展。例如，我为Log4j编写了configureAndWatch的扩展名，为Logback编写了此扩展名

原始的log4j和logback是由同一个人设计和实现的。

一些开放源代码工具已使用SLF4J。我认为该工具没有任何重大缺陷。因此，除非您在代码库中对log4j有很多扩展，否则我将继续进行logback。

我认为您的决定应该归结为决定使用log4j还是Jakarta Commons Logging之间的决定-您是否正在开发将包含在其他应用程序中的库？如果是这样，那么强迫您的库用户也使用您选择的日志记录库似乎并不公平。

如果答案是否定的，那么我只会添加更简单的内容和您更喜欢的内容。听起来像logback和log4j一样可扩展和可靠，所以如果您愿意使用它，请继续。

我对SLF4J不熟悉，仅简要回顾了logback，但有两点想到。

首先，为什么要从检查中排除工具？我认为保持开放的态度并研究所有选择最佳方案的可能性很重要。

其次，我认为在某些项目中，一种工具比另一种工具更好，而在其他项目中则相反。我不认为一个工具总是比另一个工具更好。毕竟，没有银弹。

要回答您的问题-是和否。这取决于项目，以及团队对一种工具的熟悉程度。如果整个团队都很满意它，它可以满足所有需求，并且logback不提供完成任务所需的任何功能，那么我不会说“不要使用log4j”。