java timer/timertask因单线程阻塞、异常静默终止、schedule语义混淆、内存泄漏等问题不推荐使用，应改用scheduledthreadpoolexecutor或框架方案。
Java 中的 Timer 与 TimerTask 是早期 JDK 提供的轻量级定时任务方案，适合简单、低并发、无强可靠性要求的场景。但它存在几个关键局限性，容易在实际项目中引发隐蔽问题。
单线程模型导致任务互相阻塞
每个 Timer 实例背后只维护一个后台线程（TimerThread），所有 TimerTask 都按顺序串行执行。一旦某个任务耗时过长（比如网络请求超时、文件读写卡顿），后续所有任务都会被延迟，甚至堆积等待。
- 例如：A 任务每 100ms 执行一次，B 任务每 5s 执行一次；若 A 某次执行耗时 2s，B 就会晚 2s 启动，且无法“插队”
- 没有线程隔离机制，也无法为不同任务配置优先级或超时控制
异常未捕获即静默终止
TimerTask 的 run() 方法中若抛出未捕获的异常（包括 RuntimeException 和 Error），Timer 线程会直接退出，且不会重启、不报错、不通知——后续所有已安排但未执行的任务全部失效，新 schedule 的任务也再不会触发。
- 常见于日志写入失败、空指针访问、JSON 解析异常等未加 try-catch 的地方
- 修复方式：必须在 run() 最外层包裹 try-catch(Throwable)，至少记录错误日志
schedule 与 scheduleAtFixedRate 语义易混淆
两者表面参数相似，但调度逻辑根本不同，选错会导致业务逻辑偏差甚至并发风险：
- schedule()：基于上一次实际完成时间推算下一次执行点（固定延迟）。适合“每次做完等 N 毫秒再做下一次”，如轮询状态、缓存刷新
- scheduleAtFixedRate()：基于上一次计划开始时间推进（固定频率）。若任务执行慢于周期，可能连续触发多次，甚至并发执行（因线程未阻塞，只是任务入队）
- 误用示例：用 scheduleAtFixedRate 做每 5 秒调一次接口，某次网络延迟 6 秒，之后立刻触发两次请求，而你本意只是“尽量保持 5 秒间隔”
内存泄漏风险高，尤其在容器环境中
TimerThread 是守护线程，但只要还有未 cancel 的任务，它就持续运行，并隐式持有 TimerTask 对象的引用。而 TimerTask 若是匿名内部类或非静态内部类，就会间接持有所属外部类（如 Activity、Servlet、Spring Bean）的强引用。
- Android 中：Fragment 内 new Timer 但未在 onDestroy() 调用 timer.cancel() → Activity 无法回收
- Web 应用中：Timer 放在 ServletContext 或静态变量里 → 应用 reload 后旧线程残留，与新实例共存
- 根本解法：显式调用 timer.cancel()，并确保 TimerTask 不持有外部大对象；更推荐改用 ScheduledThreadPoolExecutor
其他次要但不可忽视的问题
系统时间变更会影响执行精度；对时间敏感场景（如金融计息、实时同步）误差会随运行时间累积；不支持任务取消回调、执行统计、线程命名等运维友好特性。
- 替代建议：JDK 1.5+ 推荐使用 ScheduledThreadPoolExecutor —— 多线程、异常可见、资源可控、支持自定义 ThreadFactory（可命名线程便于排查）、天然兼容 ExecutorService 生态
- 框架场景：Spring 中优先用 @Scheduled + TaskScheduler；Android 可考虑 Handler + Looper 或 WorkManager
