Timer存在单线程泄漏风险：未捕获异常导致任务残留、线程不终止，引发句柄与内存泄漏；须在run()中try-catch并调用cancel()，生命周期结束时调用cancel()和purge()并置null；禁用static Timer，推荐改用ScheduledExecutorService。
核心问题在于：timer 本身是单线程调度器，内部持有一个后台线程（称为“timer thread”），只要还有未取消的任务在队列中，该线程就不会终止；而一旦任务执行中抛出未捕获异常，timer 默认不会自动移除该任务，也不会中断线程，导致任务残留、引用持续存在、线程无法退出——最终引发句柄泄漏（如底层 native 资源未释放）和内存泄漏。
确保 TimerTask 执行体不抛出未捕获异常
这是最直接的防线。TimerTask 的 run() 方法若抛出 RuntimeException 或 Error，Timer 不会取消它，也不会记录日志，任务会卡在“已触发但失败”状态，持续占用调度队列和线程资源。
- 所有业务逻辑必须包裹在 try-catch 中，尤其注意 I/O、解析、网络调用等高风险操作
- catch 块里应显式调用 this.cancel()（当前 TimerTask 实例），主动从队列中移除自己
- 避免在 run() 中 throw 新异常；如需上报，改用日志记录（如 SLF4J）而非抛出
Activity 或组件销毁时彻底清理 Timer 生命周期
在 Android 或类似有明确生命周期的场景中，Timer 往往被持有为成员变量，但 cancel() 调用时机不当会导致残留。
- 务必在 onDestroy() / onDetachedFromWindow() 等终态回调中调用 mTimer.cancel() 和 mTimer.purge()
- cancel() 终止 timer thread 并清空任务队列（但不清理已执行完但未被 purge 的 cancelled 任务）
- purge() 主动扫描并移除所有已 cancel 但尚未被调度器清理的 TimerTask 引用，防止弱引用残留干扰 GC
- 调用后立即将 mTimer 设为 null，切断强引用链
避免静态或长生命周期对象持有 Timer 引用
Timer 对象隐含一个守护线程，该线程会阻止 JVM 退出；若 Timer 被 static 字段或 Application Context 持有，即使 Activity 销毁，线程仍存活，关联的 TimerTask 闭包（如匿名内部类）可能持续引用 Activity 实例。
- 禁止将 Timer 声明为 static，尤其不要放在工具类或单例中长期持有
- 优先使用 Handler + Looper（主线程）或 ScheduledExecutorService（线程池管理更可控）替代 Timer
- 若必须用 Timer，确保其作用域严格绑定到短生命周期对象（如 Fragment、ViewModel），并配套清理逻辑
用 ScheduledExecutorService 替代 Timer（推荐升级路径）
ScheduledExecutorService 是更现代、更健壮的替代方案，其线程池可显式 shutdown，任务异常默认会打印堆栈且不影响后续调度，支持更灵活的取消策略。
立即学习“Java免费学习笔记（深入）”；
- 创建： ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor();
- 调度： scheduler.scheduleAtFixedRate(runnable, 0, 5, TimeUnit.SECONDS);
- 关闭： scheduler.shutdownNow(); → 立即中断所有运行中任务并拒绝新任务
- 配合 try-with-resources 或 finally 块确保 shutdown 被执行，避免线程泄漏
