timer单线程调度易“卡住”是因为其仅用一个timerthread执行所有任务，任一任务执行过长、阻塞或抛出未捕获异常都会导致后续任务永久停滞且无提示。
Timer的单线程调度机制为什么会让任务“卡住”
因为 Timer 内部只用一个后台线程（TimerThread）执行所有 TimerTask，一旦某个任务执行时间过长、抛出未捕获异常，或发生阻塞，后续所有任务都会被挂起——不是延迟，是彻底停滞。
- 常见错误现象：
Timer看似“还在运行”，但预定的后续任务完全不触发，日志静默，CPU 占用低 - 典型使用场景：定时轮询接口、清理缓存、心跳上报——这些本该轻量的任务，一旦遇到网络超时或锁竞争就容易拖垮整个调度器
- 关键细节：即使你调用了
scheduleAtFixedRate，只要前一次任务没结束，下一次就不会启动；它不支持并行，也不重试
未捕获异常直接杀死Timer线程
Timer 对任务内的异常极其脆弱：只要 TimerTask.run() 抛出任何未捕获的 Throwable（包括 RuntimeException），后台线程立即终止，之后所有待执行任务永久丢失，且无日志、无回调、无提示。
- 常见错误现象：某次数据库查询失败抛了
NullPointerException，之后定时任务全停，但应用其他部分照常运行，极难定位 - 实操建议：必须在每个
TimerTask.run()最外层加try-catch(Throwable)，至少打日志；别依赖外围 try-catch——Timer不把异常往上抛 - 注意：
Timer.cancel()不会恢复已死线程，只能防止新任务加入；已取消的Timer无法重启
替代方案选 ScheduledThreadPoolExecutor 还是 Quartz
除非遗留系统强约束，否则直接弃用 Timer。核心差异不在功能多寡，而在容错模型：
-
ScheduledThreadPoolExecutor：线程池可配大小（哪怕只设 1），单任务异常不影响其他任务；支持execute+Future控制；但不提供持久化、集群调度能力 -
Quartz：适合需故障恢复、精确 cron 表达式、多节点协调的场景；但引入复杂度，小项目杀鸡用牛刀 - 性能提醒：默认
ScheduledThreadPoolExecutor的核心线程数为 1，若仍想单线程语义，可设new ScheduledThreadPoolExecutor(1)，但异常不再中断全局调度
迁移时最容易漏掉的兼容点
从 Timer 切到 ScheduledThreadPoolExecutor 时，最常踩的坑不是语法，而是语义误读：
立即学习“Java免费学习笔记（深入）”；
-
scheduleAtFixedRate在两者中行为一致，但Timer的“固定周期”实际受任务执行时间挤压，而ScheduledThreadPoolExecutor更严格（尤其线程数 >1 时） -
TimerTask是抽象类，必须继承；ScheduledThreadPoolExecutor接收Runnable或Callable，可直接用 lambda，但要注意闭包变量线程安全 - 别忘了手动 shutdown：
timer.cancel()对应scheduler.shutdown()；若用shutdownNow()，正在运行的任务可能被中断（取决于是否响应interrupt）
真正麻烦的从来不是换 API，而是那些藏在 run() 里没处理的异常、没释放的资源、没加锁的静态变量——它们在线程独占时没事，一进线程池就暴露。
