定时任务异常会导致线程终止、调度失效，必须在方法最外层用try-catch捕获exception并记录完整堆栈，配合spring errorhandler和监控告警构建双重保障。
Java定时任务运行中一旦抛出未捕获异常，默认会导致该任务线程终止，后续调度直接失效——这不是“重试”或“跳过”，而是彻底停止执行。所以异常处理不是锦上添花，而是必须做好的兜底动作。
为什么定时任务异常会静默失败？
Timer、ScheduledExecutorService 或 Spring @Scheduled 底层都依赖线程池或单线程调度器。当任务执行中抛出 RuntimeException（比如空指针、数据库连接超时），若没显式 try-catch，异常会向上冒泡到调度器的 run() 方法。而多数调度器（尤其是 JDK 原生实现）不会重新提交任务，也不会记录完整堆栈（日志可能被吞掉），表现就是“某天起任务不跑了”，排查困难。
关键位置加 try-catch，别依赖外层兜底
在定时方法最外层用 try-catch 包住全部业务逻辑，是最直接有效的做法。不要指望全局异常处理器（如 @ControllerAdvice）能捕获定时任务异常——它只对 Web 层有效。
- 捕获 Exception（不只是 RuntimeException），覆盖 IO、SQL、JSON 解析等典型异常
- 记录完整异常堆栈（用 logger.error("xxx", e)），别只打 e.getMessage()
- 根据场景决定是否重试：幂等操作可立即重试；非幂等操作建议记日志+告警，人工介入
- 避免空 catch 或只打印 System.out —— 这等于掩盖问题
用 Spring 的 @Scheduled 配合自定义 ErrorHandler
Spring 提供了更优雅的扩展点：实现 ScheduledTaskRegistrar 的 errorHandler，或配置 TaskScheduler 的 error handler。
立即学习“Java免费学习笔记（深入）”；
- 在配置类中注册 TaskScheduler，并 setErrorHandler(new MyErrorHandler())
- MyErrorHandler 实现了 ErrorHandler 接口，统一处理所有 @Scheduled 抛出的异常
- 适合集中管控：统一发告警、落库记录、触发补偿流程
- 注意：它不能替代方法内 try-catch，只是第二道防线
监控 + 告警，让失败“看得见”
光靠日志不够。线上环境必须建立可观测性：
- 用 Micrometer + Prometheus 暴露任务执行状态（成功数、失败数、最近执行时间）
- 设置失败率阈值（如 5 分钟内失败 ≥3 次），触发企业微信/钉钉告警
- 对关键任务增加“心跳检查”：每次成功执行后写 Redis key，监控端定期读取并告警过期
- 避免只看日志量——任务停了，日志也停了
基本上就这些。核心就一条：把定时任务当成生产环境里的“独苗线程”来敬畏，每个 run() 方法都得是防止单点崩溃的堡垒。
