Log4j OnStartupTriggeringPolicy问题及TriggeringPolicy上下文处理咨询

疑问一：OnStartupTriggeringPolicy 为何要用反射获取JVM启动时间？ #

OnStartupTriggeringPolicy 的设计目标不是“只要重启就滚动日志”，而是仅当日志文件属于上一次JVM实例时才触发滚动。

举个例子：如果JVM刚启动就生成了日志文件，随后因为热重载等原因重启，这时候日志文件是本次启动周期内创建的，就不该触发滚动——原策略要避免这种误触发场景。

至于为什么不用文件的创建/修改时间直接对比？因为系统时钟可能被人为回退、同步异常，导致文件时间戳出现“比JVM启动时间还晚”的异常情况，这时候用系统时间判断就会失效。而通过反射获取JVM启动时间（不同JDK版本获取方式不同：早期依赖sun.misc.VM，后来用ManagementFactory），是为了拿到一个不受系统时钟干扰的基准时间，确保只有真正属于上一轮JVM运行的日志文件才会被滚动。

你的需求是“只要文件非空就滚动”，这和原策略的精准场景定位不一样，所以你写的简化版策略更贴合你的需求，但原策略的复杂逻辑是为了覆盖更严谨的日志滚动场景。

疑问二：LoggerContext.reconfigure() 后，如何维护Appender/Filters的上下文状态？ #

当调用LoggerContext.reconfigure()时，旧的RollingFileAppender、TriggeringPolicy、Filters等组件都会被销毁，然后创建新的实例。如果需要跨reconfigure维护状态，用线程安全的静态变量是一种可行方案，但存在几个明显局限性：

• 内存泄漏风险：静态变量不会随Appender销毁而回收，频繁reconfigure会导致无用状态堆积。
• 多上下文冲突：如果应用存在多个LoggerContext（比如多模块、Web应用的多上下文场景），静态变量会被所有上下文共享，导致状态混乱。
• 实例绑定失效：如果状态是和单个Appender实例绑定的（比如每个Appender独立的计数、过滤规则），静态变量会让新老实例共享状态，破坏逻辑独立性。

更合适的替代方案包括：

• 利用LoggerContext属性：通过LoggerContext.putProperty()和getProperty()存储状态，LoggerContext在reconfigure时会保留自身属性（除非完全重建），能实现上下文隔离的状态维护。
• 插件生命周期钩子：自定义Appender/Filters时，实现InitializationAware接口，或者在start()/stop()方法中处理状态的保存与恢复，在组件销毁前把状态存入外部上下文，初始化时再读取。
• 依赖注入容器：如果应用本身用了Spring等容器，把需要维护的状态托管给容器，让容器负责跨reconfigure的实例管理。

如果你的状态是全局共享的（比如所有Appender共用的过滤规则），静态变量勉强可用，但必须做好线程安全控制（比如用Atomic类、锁），同时要注意在应用 shutdown 时清理静态资源。

内容的提问来源于stack exchange，提问作者SensorSmith