Log4j OnStartupTriggeringPolicy 为什么要检查文件时间戳？

Question

和/或“如何安全地处理 RollingFileAppender TriggeringPolicy 中的上下文？”

我遇到问题OnStartupTriggeringPolicy未实现其既定目的

每次重新启动时触发翻转，但前提是文件大小大于零。

在“实时时钟”在一次启动时读取的时间可能比前一次启动时读取的时间早的系统上。

Tangent：是的，时钟向后跳很烦人。是的，它会产生其他问题。是的，我们已经/正在/将会采取措施来避免这种情况。不，不能充分避免告诉所有相关人员“好吧，那太糟糕了”。

在这种情况下，OnStartupTriggeringPolicy 不会在启动时触发翻转，因为在初始化时，它会根据 JVM 的启动时间检查文件时间戳。我编写了一个替代的 TriggeringPolicy，它只是在初始化时检查文件大小是否大于零，并且这

出现可以满足规定的目的。

因此，令人烦恼的问题是“我错过了什么？为什么 OnStartupTriggeringPolicy 需要花费如此多的精力，包括引发反射来查找 JVM 启动时间，来回答一个似乎有固定答案的问题？”。

ThisSO 答案向我指出了LoggerContext.reconfigure，这表明了一种情况，其中 RollingFileAppender 及其 Policy 对象可以被丢弃并重新创建。这对我来说意味着 Appender、Filter 及其从属对象必须诉诸（线程安全）静态来维护跨此事件（和其他事件？）的上下文。 然而，我不确定我是否遗漏了一些理由，即使这样也是不够/不合适的。

Answer 1

OnStartupTriggeringPolicy

 将日志文件的修改时间与 JVM 的启动时间进行比较，因为 

LOG4J2-1440：所有日志记录后端都允许随时重新配置，但翻转只能发生一次。

这对我来说意味着 Appender、Filter 及其从属对象必须诉诸（线程安全）静态来维护跨此事件（和其他事件？）的上下文。

与其前身和替代方案不同，Log4j Core 在重新配置事件期间“不会”丢失消息。这是通过将附加程序分为两部分来完成的：

执行实际工作的资源管理器（在您的情况下附加到文件）。它是引用计数的（

AbstractManager

中有一个静态注册表）并且不会停止，除非引用计数变为0，

• 一个追加器，在每次重新配置时重新创建。由于旧的追加程序在新的追加程序启动后

  停止，因此服务不会中断。