未捕获异常会导致定时任务静默终止，ScheduledExecutorService 默认不传播异常；必须用 try-catch 包裹全部业务逻辑并记录完整堆栈，配合自定义 UncaughtExceptionHandler 兜底，禁用 Timer。
Java 定时任务中，未捕获异常会导致线程“静默终止”——不是整个 JVM 崩溃，而是该任务后续不再触发，且无日志、无告警。核心问题不在“线程被杀死”，而在于 ScheduledExecutorService 对 Runnable 中抛出的异常默认不做传播也不重试，任务直接从调度链中退出。
用 try-catch 包裹整个 run() 逻辑
这是最直接、最有效的防线。ScheduledFutureTask 在执行 Runnable.run() 时，若抛出未捕获异常，会中断当前执行，且 不会影响线程池其他线程，但该定时任务本身彻底停止（scheduleAtFixedRate / scheduleWithFixedDelay 都如此）。
必须把全部业务代码包进 try-catch：
- 捕获 Exception（而非仅 RuntimeException），覆盖 IO、NPE、数据库超时等常见异常
- 在 catch 块中记录完整堆栈（推荐 SLF4J + error 级别）
- 避免空 catch 或只打印 e.printStackTrace()（控制台日志易丢失）
示例：
立即学习“Java免费学习笔记（深入）”；
executor.scheduleAtFixedRate(() -> {try {
// 数据同步、HTTP 调用、DB 查询等
} catch (Exception e) {
log.error("定时任务执行失败，将跳过本次，下次继续", e);
}
}, 0, 30, TimeUnit.SECONDS);
为线程池设置统一的未捕获异常处理器
即使加了 try-catch，仍可能漏掉：静态初始化块异常、ThreadLocal 清理异常、第三方 SDK 内部线程抛出的异常。这时需兜底。
通过自定义 ThreadFactory 设置 UncaughtExceptionHandler：
- 每个工作线程启动时自动绑定异常处理器
- 能捕获 execute() 提交的 Runnable 中所有未处理异常
- submit(Callable) 的异常需靠 Future.get() 捕获，不走此路径
示例：
立即学习“Java免费学习笔记（深入）”；
ThreadFactory factory = r -> {Thread t = new Thread(r);
t.setUncaughtExceptionHandler((thread, ex) ->
log.error("线程 {} 遇到未捕获异常", thread.getName(), ex)
);
return t;
};
ScheduledExecutorService executor = new ScheduledThreadPoolExecutor(2, factory);
避免使用 Timer / TimerTask
Timer 是单线程模型，一旦任务抛异常，整个 Timer 线程终止，所有已调度任务永久失效，且无法恢复。这是比 ScheduledExecutorService 更危险的“全盘静默死亡”。
对比：
- Timer：一个异常 → 全部任务停摆，无日志，不可恢复
- ScheduledExecutorService：一个异常 → 仅该任务停止，线程池可继续服务其他任务（前提是没手动 shutdown）
除非遗留系统受限，否则应全面替换为 ScheduledExecutorService 或更高阶方案（如 Quartz、XXL-JOB）。
补充：监控与自愈建议
防御性编码只是基础。生产环境还需主动感知异常：
- 给每个定时任务添加执行计数器（如 Micrometer Counter），监控“执行次数骤降”
- 记录每次执行耗时与状态，用 Prometheus + Grafana 做异常频率告警
- 对关键任务，可在 catch 块中触发轻量级自愈逻辑（如重试一次、发钉钉通知、写入失败队列）
