scheduleAtFixedRate以任务开始时间为基准对齐固定时间轴，若执行耗时超周期则立即触发下一次，导致堆积；应确保幂等或改用scheduleWithFixedDelay。
scheduleAtFixedRate() 的核心行为：别被“固定周期”字面意思骗了
这个方法不是简单地“每 N 毫秒启动一次任务”，而是按**初始延迟 + 周期**对齐一个时间轴，然后尽量让每次 run() 的**开始时刻**落在该时间轴上。如果某次任务执行耗时超过周期，下一次会立即触发（不等待），导致“连发”或“堆积”。这不是 bug，是设计如此。
常见错误现象：TimerTask 里做 HTTP 轮询，网络卡顿时，后续请求像叠罗汉一样涌出，可能压垮服务端或触发限流。
- 必须确保任务逻辑是幂等的，或加外部互斥（如
synchronized块、ReentrantLock）防止并发执行 - 周期值不宜设得太小（比如
100），尤其当任务含 I/O 时；建议不低于 500ms，并预留 2–3 倍执行时间余量 - 若需严格“上一次结束才等下一次”，应改用
Timer.schedule()配合递归调用，而非scheduleAtFixedRate()
正确构造 Timer 和 TimerTask：静态引用和生命周期管理是关键
Timer 是线程资源，内部持有一个后台线程；TimerTask 是一次性对象，不可复用。漏掉 cancel() 或未清理引用，会导致内存泄漏和线程持续运行（即使应用逻辑已退出）。
使用场景：Spring Boot 中作为轻量级轮询替代方案（非高可用/分布式场景）；或嵌入式、工具类小项目。
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 不要在方法内 new Timer() 后不保存引用——它无法被 cancel
- 推荐将
Timer声明为static final或由容器管理（如 Spring 的@PostConstruct/@PreDestroy） -
TimerTask必须继承并重写run()，不能直接 lambda（因 lambda 无法调用cancel()） - 务必在不再需要时调用
timer.cancel()，且之后不能再调度新任务
static final Timer timer = new Timer("polling-timer", true); // daemon=true 避免阻塞 JVM 退出
static final MyPollingTask task = new MyPollingTask();
// 启动：2 秒后首次执行，之后每 5 秒触发一次开始时间
timer.scheduleAtFixedRate(task, 2000, 5000);
// 停止（例如在 shutdown hook 或 @PreDestroy 中）
timer.cancel();
task.cancel(); // 可选，但推荐显式调用
异常未捕获会静默终止整个 Timer 线程
Timer 的后台线程一旦在 run() 中抛出未捕获异常（包括 RuntimeException），该线程立即死亡，后续所有已调度任务全部失效，且无任何日志提示——这是最常被忽略的致命坑。
性能影响：看似任务“停了”，实则是线程崩溃；监控指标会突然归零，排查困难。
- 必须在
run()方法最外层包 try-catch，至少记录 error 日志 - 不要依赖外围 try-catch——
Timer不传播异常到调用方 - 避免在
catch块中 throw 新异常，或调用System.exit() - 可考虑在 catch 后主动调用
this.cancel()并通知运维（如发告警）
class MyPollingTask extends TimerTask {
public void run() {
try {
doActualPolling(); // 可能抛 IOException / JSONException 等
} catch (Exception e) {
log.error("Polling task failed, continuing...", e);
// 不 throw，不 rethrow，不 return —— 让下次调度照常进行
}
}
}
与 ScheduledExecutorService 对比：什么情况下不该用 scheduleAtFixedRate()
如果你需要线程池复用、拒绝策略、更细粒度的异常控制、或未来可能升级为分布式调度，scheduleAtFixedRate() 就是临时方案。它的容错性和可观测性远弱于 ScheduledExecutorService。
兼容性影响：Java 5+ 全支持，但 Timer 在 Android 上部分版本有唤醒问题；而 ScheduledExecutorService 是现代标准。
- 已有
ExecutorService实例？直接用scheduler.scheduleAtFixedRate()，语义一致且更健壮 - 需要任务执行超时控制？
Timer不支持；ScheduledExecutorService可结合Future.get(timeout) - 要集成 Micrometer / Prometheus 监控执行延迟？
Timer无钩子；ScheduledThreadPoolExecutor可子类化增强
真正难处理的，从来不是怎么写那行调度代码，而是当某次轮询卡住 30 秒后，你能否快速判断是网络抖动、下游假死，还是 Timer 线程已经悄悄挂了。
