Timer已过时，因其单线程模型导致异常或长任务会阻塞整个调度；推荐ScheduledThreadPoolExecutor（支持并发、异常隔离、灵活策略）或Quartz等第三方库。
Java 的 Timer 已过时，不推荐在新项目中使用；优先选 ScheduledThreadPoolExecutor 或第三方库（如 Quartz）。
为什么 Timer 容易出问题
Timer 是单线程调度器，所有任务共享同一个线程。一旦某个 TimerTask 执行时间过长、抛出未捕获异常，整个调度队列就会卡住或终止——后续任务全部丢失，且无日志提示。
- 单线程模型无法并行执行多个定时任务
-
TimerTask.run()抛出RuntimeException会导致该Timer永久失效 - 不支持固定速率（
scheduleAtFixedRate在任务延迟时会“追赶”，可能连续触发） - 没有线程池复用、拒绝策略、任务取消反馈等现代调度能力
如何安全地替代 Timer：用 ScheduledThreadPoolExecutor
它基于线程池，支持多任务并发、异常隔离、灵活的调度策略，并能正确处理失败任务。
关键差异：
立即学习“Java免费学习笔记（深入）”；
-
schedule()≈Timer.schedule()（延迟一次） -
scheduleAtFixedRate()和scheduleWithFixedDelay()都有对应方法，语义更清晰 - 每个任务异常不会影响其他任务，异常会打印到
stderr，也可自定义ThreadFactory或RejectedExecutionHandler
ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(2);
scheduler.schedule(() -> {
System.out.println("5秒后执行一次");
}, 5, TimeUnit.SECONDS);
scheduler.scheduleAtFixedRate(() -> {
System.out.println("每3秒执行，从首次启动开始计时");
}, 0, 3, TimeUnit.SECONDS);
scheduler.scheduleWithFixedDelay(() -> {
System.out.println("每次执行完，等2秒再执行下一次");
}, 0, 2, TimeUnit.SECONDS);
Timer 还能用吗？什么场景下勉强可用
仅限极简、短生命周期、无异常风险的脚本或遗留系统维护。例如：GUI 程序中 10 秒后自动关闭弹窗、测试中模拟简单延时。
若必须用，请务必：
- 始终在
TimerTask.run()内加try-catch，避免崩溃 - 调用
timer.cancel()和timer.purge()及时释放资源（尤其在非 daemon 线程中） - 不要在
TimerTask中做 I/O、网络或耗时计算
Timer timer = new Timer(true); // true 表示 daemon 线程
timer.schedule(new TimerTask() {
@Override
public void run() {
try {
System.out.println("安全执行");
} catch (Exception e) {
e.printStackTrace(); // 必须捕获，否则 timer 死掉
}
}
}, 1000);
真正需要复杂调度时，别硬扛
比如：按 Cron 表达式执行、任务持久化、分布式协调、失败重试、依赖调度、可视化管理——Timer 和 ScheduledThreadPoolExecutor 都不适用。
这时应直接引入：
-
Quartz：功能完备，但配置稍重 -
Spring Task（@Scheduled）：适合 Spring 生态，底层默认就是ScheduledThreadPoolExecutor，支持 Cron 和动态启停 -
JobRunr或ShedLock：轻量级，侧重分布式锁与去重
调度逻辑越靠近业务，越容易被忽略的是异常传播路径和资源生命周期——不是“能不能跑起来”，而是“挂了有没有人知道、会不会连累别的任务”。
