scheduleatfixedrate从上一次任务开始时间计时，若执行耗时超过间隔会堆积；schedulewithfixeddelay从上一次结束时间计时，可防堆积；shutdown()会丢弃未触发任务，需配合awaittermination()；runnable必须捕获异常，否则定时器静默失效。
scheduleAtFixedRate 会累积执行，别直接当“每秒跑一次”用
很多人以为 scheduleAtFixedRate 就是“每隔 N 毫秒执行一次”，结果发现任务越跑越密，甚至线程池爆掉。根本原因是：它从**上一次任务开始时间**起算间隔，不是等上一次执行完再计时。如果任务执行耗时 > 间隔，下一次就会立刻触发（不排队等待），形成堆积。
- 适用场景：需要严格对齐起始时间的调度，比如每分钟整点上报监控数据
- 错误现象：
RejectedExecutionException或日志里看到连续密集的执行时间戳 - 参数注意：
initialDelay是首次延迟，period是固定周期，和任务耗时无关 - 示例：
scheduler.scheduleAtFixedRate(runnable, 0, 1, TimeUnit.SECONDS)—— 若 runnable 耗时 1.5 秒，第二轮会在第 1 秒就启动，第三轮在第 2 秒启动，以此类推
scheduleWithFixedDelay 才是“执行完再等 N 毫秒”
真正想要“每次执行完，隔 N 毫秒再跑下一次”，必须用 scheduleWithFixedDelay。它以**上一次任务结束时刻**为起点计时，天然防堆积。
- 适用场景：轮询外部接口、清理临时文件、避免并发写冲突的任务
- 常见误配：把
scheduleAtFixedRate的代码直接改成scheduleWithFixedDelay，但没改period含义——这里它不再是“周期”，而是“延迟”，语义变了 - 性能影响：不会因单次执行变慢而滚雪球，但整体吞吐量会下降（因为要等任务结束）
- 示例：
scheduler.scheduleWithFixedDelay(runnable, 0, 1, TimeUnit.SECONDS)—— 即使 runnable 耗时 2 秒，下次也一定在第 3 秒才开始
shutdown() 不等于立即停，未执行任务可能被丢弃
ScheduledExecutorService 关闭时，默认行为是拒绝新任务，但**已提交但未触发的定时任务会被直接丢弃**，不会等它到点执行。
- 错误现象：调用
shutdown()后，预期还有一次执行，结果没了 - 想等最后一次运行完？得加
awaitTermination()，但要注意超时设置——太短会提前返回，太长卡主线程 - 安全做法：
scheduler.shutdown(); if (!scheduler.awaitTermination(5, TimeUnit.SECONDS)) { scheduler.shutdownNow(); } - 兼容性注意：JDK 19+ 对
shutdownNow()中中断正在运行的定时任务行为更严格，老版本可能不抛InterruptedException
不要在 Runnable 里吞掉异常，否则定时任务会静默消失
Java 线程池默认遇到未捕获异常会终止该线程，但 ScheduledExecutorService 的调度线程是复用的——一旦 Runnable 抛出未处理异常，当前任务终止，后续调度也停止，没有任何日志提示。
立即学习“Java免费学习笔记（深入）”；
- 典型坑：
run()里调用 HTTP 接口没 try-catch，网络失败后整个定时器“死”了 - 实操建议：所有
Runnable/Callable必须包一层 try-catch，至少打日志；或者重写ThreadFactory设置UncaughtExceptionHandler - 示例片段：
public void run() { try { doWork(); } catch (Exception e) { log.error("Scheduled task failed", e); } } - 别依赖
Future.get()捕异常——定时任务的Future不会主动抛，除非你显式调用并阻塞
