怎么通过 Timer 和 TimerTask 实现简单的定时任务
先明确几个核心要点：Timer是单线程调度器，TimerTask是任务载体，二者必须配对使用；schedule()方法实现的是固定延迟调度，而scheduleAtFixedRate()则是固定速率；最后，务必记得调用timer.cancel()来释放资源。话说回来，对于新项目，更推荐使用ScheduledExecutorService作为替代方案。
Timer 和 TimerTask 的基本协作方式
在Ja va的定时任务体系里，Timer扮演着调度指挥官的角色，而TimerTask则是具体执行任务的士兵。二者必须协同作战，缺一不可。一个Timer实例可以指挥多个TimerTask，但所有任务默认都在同一个后台线程里排队执行——这就带来了一个典型问题：如果某个“士兵”动作太慢，后续所有任务都得跟着等，触发时间自然就被推迟了。
更棘手的是容错性。一旦某个TimerTask的run()方法里抛出了未捕获的异常，整个Timer线程就会直接“罢工”退出，后续所有排队的任务都将不再执行，而且不会自动重启。这种静默失败，在线上排查起来相当头疼。
- 正确做法是继承
TimerTask类并重写run()方法，而不是直接去new一个Runnable。 - 任务逻辑应当尽量轻量，避免包含耗时的I/O操作或复杂计算。如果确实需要处理重活，请在
run()方法内部显式地启动新线程或提交到独立的线程池。 - 这是一条重要经验：务必在
run()方法内用try-catch块包裹全部业务逻辑，防止意外异常导致整个调度器崩溃。
schedule() 与 scheduleAtFixedRate() 的关键区别
这两个方法看似相似，但调度策略有本质不同，用错了场景效果可能适得其反。
schedule()采用的是“固定延迟”策略。简单说，它下次执行的时间点，等于上一次任务实际结束的时间加上设定的延迟间隔。如果某次执行超时了，后续任务都会顺延。
而scheduleAtFixedRate()追求的是“固定速率”。它下次执行的时间点，是基于上一次任务计划开始的时间加上周期来计算的。即使某次执行超时，它也会尽力“追赶”进度，可能会在短时间内连续执行以弥补落后的次数。
如何选择？举个例子就清楚了：像心跳上报这类对时间间隔要求严格的任务，就适合用scheduleAtFixedRate()，以保证上报频率的稳定性。而对于缓存清理、日志轮转这类任务，用schedule()更合适，可以避免因为前一次清理动作慢，导致短时间内密集触发多次。
schedule(task, delay)：一次性任务，延迟指定毫秒后执行一次。schedule(task, firstTime, period)：首次在firstTime这个时间点执行，之后每隔period毫秒执行一次（按延迟模式）。scheduleAtFixedRate(task, firstTime, period)：首次在firstTime执行，之后严格按周期推进（按速率模式）。
如何安全取消定时任务和释放资源
这里有个容易被忽视的陷阱：Timer不会自动关闭。即使你把所有TimerTask都取消了，Timer对象本身仍然持有着后台线程，这可能导致内存泄漏，甚至在Web应用重启或JVM关闭时造成阻碍。因此，必须显式调用timer.cancel()，这个操作会终止后台线程并清空所有待执行的任务队列。
另一个常见的混淆点在于：TimerTask.cancel()方法仅仅是将当前这个任务从Timer的队列中移除，它不会影响其他任务，更不会停止Timer线程。如果任务已经开始执行，调用cancel()对正在运行的run()方法没有任何打断作用。
- 最佳实践是在应用关闭或组件销毁的生命周期钩子中，优先调用
timer.cancel()。 - 如果任务内部启动了子线程、打开了文件或数据库连接等资源，必须在
TimerTask的run()方法内自行管理这些资源的生命周期，cancel()方法不会帮你处理。 - 避免在代码中到处new Timer()。建议将其作为单例复用，或者结合Spring等依赖注入容器来统一管理其生命周期。
为什么现在更推荐 ScheduledExecutorService
那么，既然Timer有这么多需要注意的地方，有没有更好的选择？答案是肯定的。Timer核心的单线程模型决定了其容错性差、功能单一。相比之下，ScheduledExecutorService（例如通过Executors.newScheduledThreadPool(1)创建）则强大得多：它天然支持多线程执行、可以配置任务拒绝策略、能返回ScheduledFuture对象来取消任务或获取执行结果，最关键的是，单个任务的异常不会导致整个调度器崩溃。
从兼容性看，ScheduledExecutorService自JDK 5起就已全面支持，技术栈上毫无障碍。Timer虽然还能用，但在新项目或微服务架构中，已经很少被选用了。迁移成本其实很低——基本上就是把TimerTask换成Runnable或Callable，然后将schedule()方法调用替换为ScheduledExecutorService的对应方法即可。
真正让人头疼的，往往是那些遗留系统里的老代码。里面那些没有加try-catch保护的TimerTask，就像一颗颗定时冲击波，说不定哪天就因为一个未处理的异常而静默停摆，到那时，排查问题所花的时间，可能远比当初就把它替换掉要多得多。这，才是关键所在。
