情况：我们使用带有异步附加程序的 SLF4j 和 Log4j 2 问题是我们还使用 JSF，它使用java.util.Logging。我看到各种关于使用性能的令人发指的警告jul-to-slf4j因为你不能就这么放弃java.util.Logging因为它在 JDK 中并且因为...这是文档的内容http://www.slf4j.org/legacy.html http://www.slf4j.org/legacy.html says:
“...因此，j.u.l. 到 SLF4J 的转换会严重增加禁用日志语句的成本（60 倍或 6000%），并显着影响启用日志语句的性能（总体增加 20%）。从 logback 版本 0.9.25 开始，在 LevelChangePropagator 的帮助下，可以完全消除禁用日志语句 60 倍的翻译开销。”
我认为最佳解决方案是承受 20% 的性能损失。如果不完全替换 JUL 类，则 LogRecord 第一次离开 JUL 时会使用 Handler。您还需要编写自己的 LevelChangePropagator 版本，以便 Log4J2 中日志级别的更改（例如重新配置）反映在 JUL 记录器中。 （否则 60 倍命中将破坏禁用日志语句的性能。）
您可以用自己的类（直接使用 SLF4J 或 Log4J2）替换 JUL 类，但由于 JUL 不在 Java 认可标准覆盖机制涵盖的包列表中，因此您实际上是在谈论在备用 JVM 上运行或关闭其维护复杂性。
您可以推出自定义 JSF 实现，可能是采用开源实现并将所有 JUL 调用替换为 SLF4J 调用。您可以避免性能受到影响，而且不会像替换 JUL 那样困难。您仍然会维护 JSF 分叉，尽管如果您限制更改，那么维护分叉可能不会太糟糕。它也不会涵盖任何其他调用 JUL 的代码。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
