2

情况：我们使用带有异步附加程序的 SLF4j 和 Log4j 2 问题是我们还使用了使用java.util.Logging. 我看到关于使用性能的各种令人发指的警告，jul-to-slf4j因为您不能java.util.Logging因为它在 JDK 中而直接退出，并且因为......这就是http://www.slf4j 上的文档。 org/legacy.html说：

“...因此，从 7 月到 SLF4J 的翻译会严重增加禁用日志语句的成本（60 倍或 6000%），并显着影响启用日志语句的性能（总体增加 20%）。从 logback 版本 0.9.25 开始，借助 LevelChangePropagator，可以完全消除禁用日志语句的 60 倍转换开销。”

请注意，无论如何，使用 SLF4J +java.util.Logging您会遇到 20% 的性能损失，但您可以通过使用最新版本来放弃 60 倍的提升。

20% 是不可接受的。

欢迎和鼓励其他想法，但我想到的解决方案是根本不合并java.util.Logging。相反，请使用一个单独的配置文件，该文件指向与其他所有内容相同的日志文件。有没有人知道或知道我在哪里可以找到如何做到这一点的例子，假设这样做并不意味着所有创造的结束？

如果有更好的方法，我愿意接受。

4

1 回答 1

1

我认为最佳解决方案是降低 20% 的性能。如果您没有完全替换 JUL 类，则 Handler 是 LogRecord 第一次离开 JUL。您还需要编写自己的 LevelChangePropagator 版本，以便在 Log4J2 中对日志级别的更改（例如重新配置）反映在 JUL 记录器中。（否则 60 倍的命中会破坏禁用日志语句的性能。）

您可以用自己的（直接使用 SLF4J 或 Log4J2）替换 JUL 类，但由于 JUL 不在 Java 认可标准覆盖机制涵盖的包列表中，因此您实际上是在谈论在备用 JVM 上运行或关闭在维护复杂性方面。

您可以推出自定义 JSF 实现，可能通过采用开源实现并将所有 JUL 调用替换为 SLF4J 调用。您可以避免性能受到影响，并且不会像替换 JUL 那样困难。您仍然需要维护一个 JSF 分支，尽管如果您限制您的更改，维护分支可能不会太糟糕。它也不会涵盖任何其他调用 JUL 的代码。

于 2014-09-29T22:34:26.193 回答