Timer 任务异常时静默失败是因为其单线程模型下未捕获异常导致线程终止且不重启；schedule 基于实际完成时间调度，scheduleAtFixedRate 基于计划开始时间并可能并发执行；Android/Web 中易内存泄漏因 TimerThread 持有外部引用且未 cancel；ScheduledThreadPoolExecutor 更优因其线程隔离、资源可控、异常可见、支持命名线程。
Timer 为什么会在任务执行异常时静默失败
Java 的 Timer 默认使用单线程执行所有 TimerTask，一旦某个任务抛出未捕获异常（比如 NullPointerException 或 IOException），这个线程会直接终止，后续所有定时任务全部停摆——但控制台可能什么也不输出，看起来就像“定时器突然失灵了”。
这不是 bug，是设计使然：线程崩溃后，Timer 不会重启线程，也不会通知你。常见于日志写入失败、网络请求超时没 try-catch、或 run() 方法里调用了可能空指针的方法。
- 务必在
TimerTask.run()最外层加try-catch(Throwable)，至少打日志 - 不要依赖
Timer.cancel()后还能继续 schedule 新任务——它只停止待执行任务，不恢复已崩溃的线程 - 如果任务间有强依赖或需隔离错误影响，
Timer就不合适了
schedule() 和 scheduleAtFixedRate() 的行为差异在哪
两个方法都接受初始延迟和周期参数，但对“执行延迟”的处理逻辑完全不同，直接影响业务语义：
-
schedule()：基于上一次**实际执行完成时间**计算下一次触发点。如果某次任务耗时 800ms，周期设为 500ms，那下次至少要等 800+500=1300ms 后才启动 -
scheduleAtFixedRate()：基于上一次**计划开始时间**推进。同样例子下，它会立刻补上“漏掉的执行”，甚至并发执行（若前次还没结束）
典型误用场景：用 scheduleAtFixedRate() 做每 5 秒拉一次接口，结果因网络抖动某次耗时 6 秒，后续就连续触发两次请求——而你本意只是“尽量保持 5 秒间隔”，这时该换 schedule()。
立即学习“Java免费学习笔记（深入）”；
为什么 Timer 在 Android 或 Web 容器里容易内存泄漏
Timer 内部持有一个后台线程（TimerThread），只要还有未取消的任务，这个线程就不会退出。如果你在 Activity、Servlet 或 Spring Bean 中 new 了一个 Timer，但忘了调用 timer.cancel()，它就会一直持有外部类引用，导致整个 Activity 实例无法被 GC。
- Android 上常见于 Fragment 里启动定时刷新，离开页面后没 cancel，引发
Activity memory leak - Web 应用中，把
Timer放在 ServletContext 或静态变量里，应用 reload 时线程残留，新旧实例共存 - Spring 环境建议用
@Scheduled或TaskScheduler，它们由容器统一管理生命周期
替代方案：为什么现在更推荐 ScheduledThreadPoolExecutor
ScheduledThreadPoolExecutor 是 Timer 的现代平替，核心优势不是“功能更多”，而是“错误可预期、资源可控、语义清晰”：
- 线程池可配置大小，单个任务异常不会影响其他任务；默认拒绝策略会抛异常，而不是静默吞掉
- 支持
shutdown()/shutdownNow()明确释放资源，没有隐藏线程 - 返回
ScheduledFuture，能主动cancel(true)中断正在运行的任务 - 构造时传入
ThreadFactory，可命名线程便于排查（比如叫metrics-poller-1）
示例：new ScheduledThreadPoolExecutor(1, new NamedThreadFactory("health-check")) —— 比裸用 Timer 多写一行，但少踩三个月坑。
真正复杂的地方不在怎么写定时逻辑，而在谁负责清理、异常是否扩散、线程名能不能在 jstack 里一眼认出来。这些细节，Timer 全交给你猜。
