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 关闭时，默认行为是拒绝新任务，但**已提交但未触发的定时任务会被直接丢弃**，不会等它到点执行。

Java 接口排错助手

在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。

下载

• 错误现象：调用 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 不会主动抛，除非你显式调用并阻塞

线程池大小、拒绝策略、异常传播路径，这些细节在定时任务里比普通线程池更敏感——因为没人盯着它跑，一出问题就是静默失效。