Timer适合单线程、低频、非关键任务；需继承TimerTask重写run()，用schedule()启动；注意delay单位为毫秒、period为固定间隔；务必捕获run()内异常并显式cancel()。
Timer.schedule() 和 TimerTask.run() 的基本用法
Java 的 Timer 和 TimerTask 是 JDK 自带的轻量级定时方案，适合单线程、低频、非关键任务（比如每分钟刷一次缓存状态）。核心就是：继承 TimerTask 写逻辑，用 Timer.schedule() 启动。
常见错误是直接在 run() 里写阻塞或耗时操作——这会卡住整个 Timer 线程，后续所有任务都会延迟甚至堆积。
-
TimerTask必须重写run()，不能抛出受检异常（得自己 try-catch） -
schedule()有多个重载，注意delay是毫秒，不是秒；period是**固定间隔**，不是固定时间点（即不校准） - 同一个
Timer实例可调度多个TimerTask，但共用一个后台线程，任一任务出异常未捕获，整个 timer 就 silently shutdown
Timer timer = new Timer();
timer.schedule(new TimerTask() {
public void run() {
System.out.println("每 2 秒执行一次");
}
}, 0, 2000);
Timer.cancel() 和 TimerTask.cancel() 的区别与调用时机
Timer.cancel() 终止整个计时器，清空任务队列，释放线程；TimerTask.cancel() 只取消该任务本身（对已启动的 run() 无效），且不影响其他任务。
容易踩的坑是：在 run() 里调用 this.cancel() 想实现“只执行一次”，结果发现没用——因为 schedule() 已把任务加入队列，cancel() 只对未触发的任务生效。真要单次执行，别用循环调度，直接用 schedule(task, delay) 即可。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 应用关闭前必须显式调用
timer.cancel()，否则线程不会退出，JVM 无法正常 shutdown -
TimerTask.cancel()返回 boolean，true 表示任务尚未执行，可取消成功；false 表示已运行或正在运行，取消失败 - 不要在
run()中反复 new Timer，每个 Timer 都开一个守护线程，极易内存泄漏
Timer 在多线程/异常场景下的致命缺陷
Timer 底层只用一个线程顺序执行所有任务，一旦某个 TimerTask.run() 抛出未捕获异常（比如 NullPointerException 或 IOException），这个线程就终止，后续所有任务永久停摆，且无任何日志提示——这是最常被忽略的线上故障根源。
它也不支持并发控制：没法限制同时最多执行几个任务，也没法动态增删任务（只能 cancel 后重建）。更麻烦的是，如果系统时间被手动调整（如 NTP 同步回拨），Timer 会彻底混乱——可能重复触发，也可能跳过若干轮。
- 异常必须在
run()内部 try-catch，连printStackTrace()都建议加上，否则等于静默失败 - 不要用
Timer做依赖精确时间的任务（如金融对账），它的精度和稳定性远不如ScheduledThreadPoolExecutor - Android 上尤其危险：
Timer线程默认是守护线程，Activity 销毁后若没 cancel，可能引发 Context 泄漏
什么情况下还能凑合用 Timer？
只有满足全部三个条件时，Timer 才算安全：任务绝对轻量（
一旦涉及 I/O、网络、数据库、用户交互，或者需要容错、监控、动态调度，就必须换掉。别指望加个 try-catch 就能兜住所有问题——线程挂了，任务队列丢了，时间漂移了，这些都不是 catch 能解决的。
真正该关注的是：你那个“定时刷新 token”的任务，有没有可能某次 HTTP 调用超时卡住 30 秒？如果有，Timer 就已经不可信了。
