自动化任务调度常见故障与应对方法

定时任务没执行？先查时间配置

公司后台每天凌晨要跑数据统计，结果连续三天报表都是空的。一查才发现，原来是任务调度的时间写成了 0 0 12 * * ?，本意是想在凌晨执行，却误设成中午12点——那时候数据库还没完成备份，数据不全自然出错。Cron 表达式看着简单，但秒、分、时、日、月、周、年这七个字段顺序一旦搞混，或者用了不兼容的格式（比如 Quartz 和 Linux Cron 差异），任务就永远不会触发。

遇到任务不启动，第一件事就是核对调度表达式是否符合框架要求。比如 Spring Scheduled 不支持年字段，而有的系统周几是从1开始算，有的从0开始，写错了等于白配。

0 0 2 * * ? <!-- 每天凌晨2点执行 -->
0 */10 * * * ? <!-- 每10分钟执行一次 -->

任务卡住或堆积，可能是线程池满了

有个运维同事反馈，监控系统里一堆告警任务延迟了几个小时才发出去。登录后台一看，任务状态全是“运行中”，但实际上并没有真正执行。问题出在默认线程池只有10个线程，但高峰时段有上百个任务同时排队，后面的只能干等。

很多调度框架默认用单线程或极小线程池处理任务，一旦某个任务执行时间过长，比如网络请求卡住30秒，整个队列都会被拖慢。解决办法是显式配置线程池大小：

@Bean
public TaskScheduler taskScheduler() {
    ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler();
    scheduler.setPoolSize(20);
    scheduler.setThreadNamePrefix("task-scheduler-");
    return scheduler;
}

重复执行？分布式环境下锁没做好

服务做了集群部署，三台机器都连着同一个调度配置，结果每到整点短信通知发三遍。用户投诉不断，查日志发现三个实例都在触发相同任务。这不是调度器坏了，而是没做分布式锁。

像 Quartz 可以通过数据库表 QRTZ_LOCKS 加锁，确保同一时间只有一个节点执行任务。如果用的是轻量级方案比如 XXL-JOB 或 Elastic-Job，记得开启高可用模式，并连接统一注册中心。

任务执行失败但没报警

一个财务对账任务连续五天失败，没人发现，直到月底对不上账才暴露问题。查看日志才发现，异常被捕获后只打了条 info 级别的日志，没有任何通知。

自动化任务最怕“静默失败”。哪怕只是发邮件这种简单操作，也得加上错误回调机制。可以在任务外层包一层监听器，失败时自动推送钉钉或企业微信消息：

try {
    sendMonthlyReport();
} catch (Exception e) {
    log.error("月报发送失败", e);
    alertService.send("【任务失败】sendMonthlyReport 异常：" + e.getMessage());
}

依赖未就绪就启动任务

新上线的服务依赖 Redis 缓存，调度任务一启动就去读数据，结果报空指针。原因是应用虽然启动了，但缓存还没加载完。这种情况不能让任务一到点就硬跑，得先检查依赖状态。

可以加个简单的健康判断逻辑，比如：

if (!cacheService.isReady()) {
    log.warn("缓存未就绪，跳过本次执行");
    return;
}

或者结合 Spring 的 @ConditionalOnProperty 或启动探针，确保环境准备好了再激活调度器。

资源冲突导致任务异常

两个任务共用一个临时文件目录，一个在写，另一个直接清空了目录，结果文件生成了一半被删掉。这类资源竞争问题在多任务环境中很常见。

解决方案是隔离资源路径，或者加文件锁。更稳妥的做法是设计任务时就避免共享状态，比如每个任务用自己的工作目录：

String workDir = "/tmp/task_" + System.currentTimeMillis();
Files.createDirectory(Paths.get(workDir));