timer只执行一次是因为其单线程机制下未捕获异常会终止整个调度线程；需在run()中try-catch，避免阻塞或耗时操作；推荐用scheduledexecutorservice或spring@scheduled替代。
Timer.schedule() 为什么只执行一次就停了
因为 Timer 默认使用单线程调度，一旦任务抛出未捕获异常，整个 Timer 线程会直接终止，后续所有任务（包括重复任务）全部失效。这不是“没触发”，而是线程已死。
- 必须在
TimerTask.run()内用 try-catch 包住全部逻辑，否则任意NullPointerException或IOException都会让定时器静默退出 - 不要在
run()中调用System.exit()、阻塞 IO（如Thread.sleep(10000)）或长时间计算，会卡住整个 Timer 线程 - 若需固定周期执行（如每5秒一次），用
timer.schedule(task, delay, period)；若只需延迟一次，用timer.schedule(task, delay)
Timer 和 ScheduledExecutorService 到底该选哪个
Timer 是 JDK 1.3 的老方案，轻量但脆弱；ScheduledExecutorService（推荐用 Executors.newScheduledThreadPool(1)）是 JDK 5 引入的现代替代，线程安全、异常隔离、支持 Callable、可动态取消。
-
Timer的任务异常会杀死整个调度线程；ScheduledExecutorService中单个任务失败不影响其他任务 -
Timer只有一个后台线程，多个任务串行执行；ScheduledExecutorService可配置多线程（哪怕只设 1 个，内部结构也更健壮） - 如果项目已用 Spring，直接上
@Scheduled(fixedRate = 5000)，底层自动对接ScheduledExecutorService，不用手管Timer
如何让 Timer 任务真正准时（而不是“大约”）
根本做不到。Timer 基于系统时钟 + 单线程轮询，实际触发时间受 JVM GC、线程调度、任务本身耗时等多重影响。比如设置 1000ms 后执行，但前一个任务跑了 800ms，那它至少要等到 1800ms 后才开始计时。
- 对精度要求 > 100ms 的场景（如实时行情推送），别用
Timer，改用System.nanoTime()自旋校准，或接入 Quartz / Netty HashedWheelTimer - 若只是发个桌面提醒、查个状态，
Timer完全够用——用户根本感知不到 ±300ms 偏差 - 避免在
run()中做耗时操作：数据库查询、HTTP 调用务必异步化，或改用独立线程池处理
Timer.cancel() 后任务还在运行？这是正常现象
timer.cancel() 只是标记 Timer 停止接受新任务，并不会中断正在执行的 TimerTask.run()。如果 run() 里有个 while 循环或 sleep，它会继续跑完。
立即学习“Java免费学习笔记（深入）”；
- 需要主动协作退出：在
TimerTask内定义 volatile boolean 字段（如running），cancel()前先置为 false，run() 中定期检查该标志 -
timer.purge()可清理已取消但尚未执行的任务，减少内存残留，但不解决“正在跑的任务”问题 - 真正想立即停掉任务，得用
Thread.interrupt()—— 但这要求你的任务逻辑主动响应中断（检查Thread.currentThread().isInterrupted()）
Timer 的单线程本质和异常传播机制。真要稳定调度，绕过 Timer 是更省心的选择。 
