Log4j2 CronTriggeringPolicy与同cron定时任务的执行优先级问题

你观测到的日志滚动优先执行不是偶然巧合，是框架设计层面保障的既定规则，默认配置下完全能满足「先完成滚动再写入新日志」的预期，不需要额外做顺序适配。

核心逻辑说明 #

• 调度层天然存在触发先后差
  业务侧用的@Scheduled(cron = "0 0 0 * * ?")依赖Spring容器自带的TaskScheduler实现，默认采用单线程轮询匹配cron触发条件，任务到点后还要进入线程池排队等待执行资源，本身存在不可避免的调度延迟，触发响应速度慢于日志框架的内部调度。
  Log4j2的CronTriggeringPolicy schedule="0 0 0 * * ?"使用框架独立维护的内部守护线程做精确延迟调度，直接基于cron计算的下次触发时间差计时，到点后会第一时间抢占日志Appender的独占文件锁执行滚动切分，触发时机天然早于业务层的定时任务。
• 日志写入链路有强制前置检查兜底
  就算碰到极端时序场景：比如业务定时任务线程提前抢到CPU资源，比Log4j2的滚动调度线程更早启动，只要执行日志写入操作，就一定会触发前置检查——Log4j2在每一条日志真正写入磁盘前，都会先执行滚动策略的条件判断：如果发现当前时间已经跨过0点的滚动阈值，会立刻同步触发滚动流程，等旧日志文件归档、新文件句柄切换完成后，才会把当前日志写入新文件。整个过程由Appender内置锁保障原子性，不会出现「先把新日志写到旧文件，再执行滚动」的情况。

补充提示 #

你本地测试观察到的现象是稳定可复现的，不需要特意把两个cron表达式设置时间差来规避冲突。就算开启Log4j2异步日志、自定义Spring任务调度线程池，上述前置检查的兜底逻辑也会持续生效，不会出现新日志错写到前一天文件的问题。

内容的提问来源于stack exchange，提问作者바보린