Log4j2.xml中TimeBasedTriggeringPolicy如何设置滚动日志策略详细说明？

本文共计1230个文字，预计阅读时间需要5分钟。

Log4j2中的TimeBasedTriggeringPolicy并非到了凌晨就切换，而是依赖filePattern中的日期格式动态生成归档路径，并比较当前时间是否匹配新的周期。例如，若filePattern设置为logs/app-%d{yyy-MM-dd}-%i.log，则按天滚动；若误写为logs/app-%d{yyy-MM}.log，则按月滚动，但日志文件名中缺少日期信息，可能造成归档逻辑错误。

常见错误现象：app-2024-05.log 文件持续写入一整月，第二天仍不生成 app-2024-05-02.log。

• filePattern 中的 %d{...} 必须包含“最小滚动单位”——比如按天滚动，就得有 dd；按小时，就得有 HH
• fileName（当前活动文件）不能含动态日期，否则每次启动都可能新建文件，破坏滚动连续性
• 时区默认用 JVM 启动时的本地时区，跨时区部署时务必显式配 timeZone="GMT+8"

为什么加了 TimeBasedTriggeringPolicy 还是不归档？看 DefaultRolloverStrategy 是否限制了归档数

触发策略只决定“什么时候该滚”，真正执行压缩、重命名、删除老日志的是 DefaultRolloverStrategy。它默认不限制归档数量，但如果手动配了 max 却设得太小（如 max="3"），而实际日志量大、滚动快，就可能出现“刚滚完就被删”，甚至因文件被删导致下次滚动失败。

使用场景：线上服务要求保留最近 7 天日志，每天一个文件，共 7 个归档文件。

• 配 max="7" 是对的，但必须配合 filePattern 的日期精度（如 %d{yyyy-MM-dd}）
• 若同时用了 SizeBasedTriggeringPolicy，DefaultRolloverStrategy 会优先响应最先满足的策略，归档行为可能比预期更频繁
• 注意 max 指归档文件数，不含当前正在写的 fileName，所以设 max="7" 实际最多存 8 个文件（7 个归档 + 1 个 active）

TimeBasedTriggeringPolicy 和 CronTriggeringPolicy 到底选哪个？

别被名字误导：TimeBasedTriggeringPolicy 是“周期对齐型”滚动（如每天 0 点切，不管之前写了多少），适合常规日志归档；CronTriggeringPolicy 是“定时任务型”（按 cron 表达式触发，比如每天 2:30 执行一次滚动），但它不保证文件内容截止到该时刻——如果日志正狂写，2:30 滚动后，旧文件末尾可能缺最后几条。

性能影响：两者本身开销极小，但 CronTriggeringPolicy 在非标准时间点滚动，容易和 JVM GC、监控采集等任务撞上，引发 I/O 小高峰。

• 要严格按自然日/小时归档 → 用 TimeBasedTriggeringPolicy
• 需要在业务低峰期统一处理（比如凌晨批量清理前先切日志）→ 可考虑 CronTriggeringPolicy，但得接受时间点与内容边界不完全一致
• CronTriggeringPolicy 不支持 modulate 参数，无法自动对齐周期起点（比如 cron 设 0 0 2 * * ?，但想让第一次滚动发生在最近一个 2:00，它做不到）

滚动失败报错 Unable to rename ... to ...？大概率是 Windows 文件锁或权限问题

这个错误不是配置写错了，而是 Log4j2 尝试把当前日志文件重命名为归档名时被拦住了。Linux 下少见，Windows 下高频：JVM 进程自己还拿着文件句柄，或者杀进程没杀干净，残留句柄锁住文件；也可能是杀掉进程后立刻重启，旧句柄还没释放完。

典型错误信息：Unable to rename C:\logs\app.log to C:\logs\app-2024-05-01.log

• Windows 上建议加 append="false" 到 FileAppender，避免复用句柄（但会损失部分性能）
• 生产环境禁用 shutdownHook="true"（默认开启），防止 JVM 关闭时强制 flush 引发竞态；改用外部信号（如 SIGTERM）优雅关闭
• 排查时用 Process Explorer 搜文件名，看谁还持有着句柄

Log4j2 的滚动本质是“时间戳驱动的文件管理”，配置只是告诉它怎么算时间、怎么命名、删哪些。真正卡住的，往往不在 XML 写法，而在操作系统行为、进程生命周期、或和其他策略的隐式交互。