78

新项目是否应该使用 logback 而不是 log4j 作为日志框架？

或者换句话说：'logback 是否比 log4j 更好（留下 logback 的 SLF4J-'功能'）？

4

7 回答 7

83

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

它提供了简洁的功能，例如参数化消息和（与 commons-logging 相比）映射诊断上下文（MDC、javadoc、文档）。

使用 SLF4J 使得日志后端可以以一种非常优雅的方式进行交换。

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

SLF4JBridgeHandler 的javadocs中解释了桥接 jul 。

我在几个项目中使用 SLF4J+Logback 组合的体验非常好，而 LOG4J 开发几乎停滞不前。

SLF4J 有以下剩余的缺点：

  • 它不支持可变参数以保持与 Java < 1.5 的兼容
  • 它不支持同时使用参数化消息和异常。
  • 它不包含对LOG4J 所具有的嵌套诊断上下文（NDC、 javadoc ）的支持。
于 2009-05-31T22:10:56.907 回答
22

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

这里有一些让我印象深刻的；

  • 更快的实施

    基于我们之前在 log4j 上的工作，logback 内部已经被重写，在某些关键执行路径上的执行速度提高了大约十倍。logback 组件不仅速度更快，而且内存占用更小。

  • 自动重新加载配置文件

    Logback-classic 可以在修改时自动重新加载其配置文件。扫描过程既快速又安全，因为它不涉及创建单独的扫描线程。这种技术上的微妙之处确保 logback 在应用程序服务器中运行良好，更普遍地在 JEE 环境中运行。

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

    当 logback 打印异常时，堆栈跟踪将包含打包数据。这是由 logback-demo web-application 生成的示例堆栈跟踪。

    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。 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] 在 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 ) [classes/:na] 在 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) [jetty-6.1.12.jar:6.1.12] 在 org.mortbay.jetty.servlet。 ServletHandler.handle(ServletHandler.java:361) [jetty-6.1.12.jar:6.1.12] 在 org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) [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，并且部署在 jetty 版本 6.1.12 下。因此，堆栈跟踪将快速通知读者有关异常中的类以及它们所属的包和包版本。当您的客户向您发送堆栈跟踪时，作为开发人员，您将不再需要要求他们向您发送有关他们正在使用的软件包版本的信息。该信息将成为堆栈跟踪的一部分。有关详细信息，请参阅“%xThrowable”转换字。

    这个特性非常有用，以至于一些用户错误地认为它是他们的 IDE 的一个特性。

  • 自动删除旧的日志档案

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

那里可能存在偏见，但同一个人确实编写了两个框架，如果他说使用 Logback 而不是 Log4j，他可能值得一听。

于 2011-05-18T12:27:21.463 回答
10

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

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

于 2009-01-20T12:47:08.900 回答
2

Logback 更了解 Java EE：
通常（从代码到文档）它牢记容器——多个应用程序如何共存、类加载器如何实现等。记录器的上下文、JNDI、JMX 配置等。

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

Log4j – 唯一的巨大优势是旧的 JVM 支持、小型 (IMO) NDC（仅限 Logback MDC）、一些扩展。例如，我为 Log4j 编写了 configureAndWatch 扩展，而 Logback 则没有

于 2010-04-22T17:02:32.517 回答
1

I would think that your decision should come down to the same one it would if you were deciding between using log4j or Jakarta Commons Logging - are you developing a library which will be included in other applications? If so, then it doesn't seem fair to force users of your library to also use your logging library of choice.

If the answer is no, I would just go with what is simpler to add and what you are more comfortable with. Sounds like logback is just as extensible and reliable as log4j, so if you're comfortable using it, go ahead.

于 2008-10-07T15:50:10.000 回答
1

最初的 log4j 和 logback 是由同一个人设计和实现的。

一些开源工具使用了 SLF4J。我没有看到这个工具有任何重大缺陷。因此，除非您的代码库中有很多 log4j 扩展，否则我会继续使用 logback。

于 2008-10-07T15:08:32.377 回答
-3

我对 SLF4J 不熟悉，我只对 logback 进行了简要介绍，但我想到了两件事。

首先，您为什么将工具排除在检查之外？我认为保持开放的心态并检查所有可能性以选择最佳方案是很重要的。

其次，我认为在某些项目中，一种工具比另一种工具更好，而在不同的项目中可能正好相反。我不认为一种工具总是比另一种工具更好。毕竟，没有灵丹妙药。

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

于 2008-10-07T14:58:45.500 回答