Java 周期调度器如何避免任务越积越多：固定频率、异常终止与恢复

线上有个每分钟刷新缓存的 Java 任务，监控上却出现了两个相反的现象：偶尔一整小时没有新数据，恢复后又发现任务并没有同时跑很多份。排查这类问题时，先看 ScheduledThreadPoolExecutor 的两个事实：周期任务默认不会重叠，但一次执行抛出未捕获异常后，后续执行会被抑制。

要让周期任务可恢复，关键不是把线程池开得更大，而是把任务异常变成可观察的结果，并确保调度器只创建一次。

影响面：为什么“每分钟一次”会变成无声停摆

设定 initialDelay=0、period=60 秒，并不代表每 60 秒必然有一次成功结果。若 Runnable 内部抛出未捕获异常，调度系列会结束；如果一次执行用了 90 秒，后续执行则会迟到，不能用“线程池里有多个线程”推断它会并行补齐。

更危险的是应用初始化代码被重复调用。每次调用都 new 一个 ScheduledThreadPoolExecutor，业务上看似只有一个任务，实际上有多个独立的周期源。日志中的相同任务名会让这个问题很难凭肉眼确认。

时间线：从一次异常到后续轮次消失

假设缓存刷新在 10:00、10:01 正常运行，10:02 解析上游响应时抛出 IllegalStateException。调度器不会自动替你重新安排这个周期系列，10:03 以后也不会再有该 ScheduledFuture 的正常执行。只有把异常拿到任务边界并记录，故障才会从“没有日志”变成可追踪事件。

图：从 ScheduledThreadPoolExecutor 到 scheduleAtFixedRate，再由 ScheduledFuture 观察 ExecutionException 的调用链。

根因：scheduleAtFixedRate 只负责调度，不负责业务恢复

scheduleAtFixedRate 解决的是时间触发问题，不会替业务决定“失败后立即重试几次”“失败是否告警”或“下次是否继续”。可以把原始任务包在一个边界方法里，确保异常被记录，同时让该轮失败不终止周期序列。

ScheduledThreadPoolExecutor scheduler = new ScheduledThreadPoolExecutor(1);
AtomicInteger failureCount = new AtomicInteger();

Runnable refreshCache = () -> {
    try {
        refreshRemoteCache();
        failureCount.set(0);
    } catch (RuntimeException ex) {
        int failures = failureCount.incrementAndGet();
        logger.warn("cache refresh failed, failures={}", failures, ex);
    }
};

ScheduledFuture> future = scheduler.scheduleAtFixedRate(
        refreshCache, 0, 1, TimeUnit.MINUTES);

这里的恢复含义很克制：捕获的是本轮异常，记录连续失败次数，下一轮仍由原来的 ScheduledFuture 触发。不要在 catch 里再次调用 scheduleAtFixedRate，那会制造第二个周期源。

修复动作：让失败、取消和关闭都能被验证

启动阶段只注册一次任务，并把返回的 ScheduledFuture 保存为组件成员。关闭时先取消周期任务，再关闭调度器；测试中则可以调用 future.get() 检查没有被异常终止。

public final class CacheRefreshJob implements AutoCloseable {
    private final ScheduledThreadPoolExecutor scheduler =
            new ScheduledThreadPoolExecutor(1);
    private final ScheduledFuture> future;

    public CacheRefreshJob() {
        this.future = scheduler.scheduleAtFixedRate(
                this::runSafely, 0, 1, TimeUnit.MINUTES);
    }

    private void runSafely() {
        try {
            refreshRemoteCache();
        } catch (RuntimeException ex) {
            logger.warn("cache refresh failed", ex);
        }
    }

    @Override
    public void close() {
        future.cancel(false);
        scheduler.shutdown();
    }
}

验收时观察三件事：异常发生后下一分钟仍有任务日志；同一时间窗口没有两条相同任务实例；应用关闭后 future.isCancelled() 为 true，调度器不再接收新任务。

防复发：区分执行变慢和重复提交

如果一次刷新耗时超过 60 秒，scheduleAtFixedRate 会让下一次启动变晚，但同一周期任务不会重叠。这是执行变慢，应该检查上游超时和任务耗时。若同一分钟出现两次完整刷新，则优先检查初始化路径、容器副本数量和是否重复创建 ScheduledThreadPoolExecutor。

任务本身仍可能把工作提交到另一个普通线程池；那部分是否重叠要由业务代码另行控制。不要只盯着调度器线程数，沿着“调度触发—刷新方法—下游调用—结果记录”这条链核对实例数。

图：scheduleAtFixedRate、周期任务、单次执行变慢与任务不重叠之间的状态边界。

常见问题：周期调度排查的三个确认点

任务执行时间超过 period 会不会自动并发补偿？

不会。后续执行可以迟到，但连续的周期执行不会并发重叠；需要并发处理时，应显式设计独立工作队列并定义幂等边界。

为什么没有异常日志，周期任务却停止了？

直接提交的周期 Runnable 可能让异常终止周期序列，而日志又没有覆盖任务边界。把异常捕获、失败计数和任务实例标识放在同一层，才能看到停止原因。

应该在 catch 中重新 scheduleAtFixedRate 吗？

通常不应该。重新注册会产生新的 ScheduledFuture，原任务和新任务的生命周期也难以统一。先让当前周期继续，再把重试策略交给明确的队列或退避组件。

总结：先保证一个周期源，再谈线程数

ScheduledThreadPoolExecutor 的可靠用法可以归结为三步：只初始化一个调度器，给周期任务包上异常边界，保存并在关闭时取消 ScheduledFuture。这样排查时能明确区分“任务异常后停止”“单次执行变慢”和“重复提交造成多实例”，修复也不会靠盲目加线程数。