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 实例。

Java 接口排错助手

在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。

下载

• 禁止将 Timer 声明为 static，尤其不要放在工具类或单例中长期持有
• 优先使用 Handler + Looper（主线程）或 ScheduledExecutorService（线程池管理更可控）替代 Timer
• 若必须用 Timer，确保其作用域严格绑定到短生命周期对象（如 Fragment、ViewModel），并配套清理逻辑

用 ScheduledExecutorService 替代 Timer（推荐升级路径）

ScheduledExecutorService 是更现代、更健壮的替代方案，其线程池可显式 shutdown，任务异常默认会打印堆栈且不影响后续调度，支持更灵活的取消策略。

• 创建： ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor();
• 调度： scheduler.scheduleAtFixedRate(runnable, 0, 5, TimeUnit.SECONDS);
• 关闭： scheduler.shutdownNow(); → 立即中断所有运行中任务并拒绝新任务
• 配合 try-with-resources 或 finally 块确保 shutdown 被执行，避免线程泄漏

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南