timer.cancel() 不能中断正在执行的timertask，仅清空队列并停止调度线程；需在run()中检查中断状态或使用volatile标志位，配合purge()和置null，或改用支持中断的scheduledexecutorservice。
Timer.cancel() 确实能停止 Timer 的调度线程，并清空任务队列——但它**不会中断正在执行的 TimerTask**。这是多数人误以为“彻底停止”的关键盲区。
cancel() 后仍在运行的任务不会被终止
一旦 TimerTask.run() 开始执行，Timer.cancel() 对它完全无效。哪怕你调用后立刻返回，那个 run() 方法仍会继续跑完（除非它自己检查中断状态或主动退出）。
- 现象：调用
timer.cancel()后，控制台仍打印出后续日志，甚至触发网络请求或文件写入 - 原因：Java 的
Timer不对正在运行的TimerTask调用Thread.interrupt()，也不提供强制终止机制 - 正确做法：在
TimerTask.run()内部定期检查Thread.currentThread().isInterrupted()，或用 volatile 布尔标志位协作退出
cancel() 无法回收 Timer 持有的线程资源（尤其在未调用 purge() 时）
Timer 内部使用单个后台线程（TimerThread），cancel() 会让它退出，但前提是队列为空且无任务正在运行。如果任务长期阻塞（如 Thread.sleep(60_000)），该线程会卡住不退出，导致内存泄漏。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 必须配合
timer.purge()在 cancel 前清理已取消但尚未从队列移除的TimerTask实例（它们仍被引用） - 更稳妥的做法是：先调用
purge()，再cancel()，最后将引用置为null - 示例：
timer.purge(); // 清理已取消但滞留队列中的任务 timer.cancel(); timer = null;
替代方案：用 ScheduledExecutorService 更可控
Timer 是老旧 API，缺乏对任务生命周期的精细控制；而 ScheduledExecutorService 支持取消正在运行的任务（通过 Future.cancel(true) 发送中断信号）。
- 创建：
ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1);
- 提交并保留 Future：
Future> future = scheduler.scheduleAtFixedRate(task, 0, 5, TimeUnit.SECONDS);
- 真正“彻底停止”：
future.cancel(true); // true 表示尝试中断正在执行的线程 scheduler.shutdownNow(); // 尝试停止所有待处理任务并中断工作线程
- 注意：仍需在 task 中响应中断（如捕获
InterruptedException或检查isInterrupted()）
真正“彻底停止”的难点不在取消动作本身，而在任务是否具备可中断性——无论用 Timer 还是 ScheduledExecutorService，只要 run() 方法里有死循环、阻塞 I/O 或忽略中断，就停不住。别只盯着 cancel()，得从任务内部设计开始约束。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
