Java 线程池怎么设计任务拒绝反馈：拒绝处理器、错误语义与调用方重试

线上批量导入的高峰一到，订单异步任务池就开始报 RejectedExecutionException。真正难处理的不是这行异常，而是调用方不知道该丢弃、降速、稍后重试，还是把任务交回当前线程。Java 的 RejectedExecutionHandler 正好把这件事变成一个可设计的契约：先说明拒绝原因，再决定任务去向，最后让调用方拿到稳定的结果。

先把一次任务拒绝说清楚

这个例子里，线程池有 2 个工作线程、容量为 2 的队列。提交第 5 个任务时，如果前 2 个任务仍在运行、队列也已占满，execute 就没有位置接收新任务；如果池已经调用过 shutdown，后续提交同样会走拒绝处理。两者都触发 rejectedExecution，但业务含义完全不同。

前者是“当前过载”，通常可以让上游降速或延迟重试；后者是“生命周期已结束”，重试只会制造更多错误。官方接口文档也明确说明，拒绝既可能因为线程和队列上限被触达，也可能因为执行器正在关闭。

四种内置策略，差别在任务去了哪里

AbortPolicy：把失败交给提交方

这是 ThreadPoolExecutor 的默认策略。拒绝时抛出 RejectedExecutionException，调用方可以记录任务标识、返回稍后重试，或切换到持久化补偿队列。它最适合不能悄悄丢任务的场景，前提是调用方真的捕获并处理异常。

CallerRunsPolicy：用提交线程形成反压

任务会在调用 execute 的线程中直接运行。这个策略能自然拖慢生产者，但如果提交线程是 HTTP 工作线程，慢任务就会占住请求处理能力；如果任务本身可能再次提交同一个池，还要额外检查递归和延迟放大。

DiscardPolicy 与 DiscardOldestPolicy：只适合可丢数据

DiscardPolicy 静默丢弃当前任务；DiscardOldestPolicy 先丢掉队列中最老的任务，再尝试提交当前任务。它们没有给业务层返回失败信号，适合过期即无效的刷新通知一类任务，不适合订单、扣款或审计事件。

自定义处理器要先区分过载和关闭

与其在 rejectedExecution 里 sleep 后反复调用 execute，不如把一次拒绝转换成明确的结果。下面的处理器只负责记录池状态和发出业务异常，重试次数、退避时间和幂等键由调用方管理。

final class BackpressureHandler implements RejectedExecutionHandler {
    @Override
    public void rejectedExecution(Runnable task, ThreadPoolExecutor pool) {
        boolean closing = pool.isShutdown() || pool.isTerminating();
        String reason = closing ? "executor-closing" : "capacity-saturated";
        System.err.printf("task rejected: reason=%s, active=%d, queued=%d%n",
                reason, pool.getActiveCount(), pool.getQueue().size());
        throw new TaskRejectedException(reason);
    }
}

final ThreadPoolExecutor pool = new ThreadPoolExecutor(
        2, 4, 30, TimeUnit.SECONDS,
        new ArrayBlockingQueue(2),
        Executors.defaultThreadFactory(),
        new BackpressureHandler());

日志里的 reason 是给监控和调用方看的稳定字段，不要把 getQueue().size() 当成绝对准确的并发快照；它只用于判断趋势和排查现场。任务本身还应携带业务 ID，避免只凭一条异常消息定位。

调用方重试应该围绕幂等，而不是围绕异常次数

提交端先捕获自定义异常，再根据拒绝原因决定动作。过载可以回到消息表或延迟队列，关闭则应切换到停止流程。重试前必须保证任务有幂等键，否则一次“提交成功但响应丢失”的边界会造成重复处理。

try {
    pool.execute(() -> orderService.sync(orderId, requestId));
} catch (TaskRejectedException ex) {
    if ("capacity-saturated".equals(ex.reason())) {
        retryStore.save(requestId, orderId); // 由独立消费者退避重试
    } else {
        shutdownReporter.record(requestId, ex.reason());
    }
}

上线前用三个结果验收策略是否真的生效

第一，填满工作线程和队列，确认过载分支留下任务 ID，并且没有在拒绝处理器里阻塞等待。第二，先调用 shutdown 再提交任务，确认日志标记为关闭，而不是误报容量不足。第三，让一次重试成功和一次重试达到上限，分别检查幂等记录、告警字段与最终状态。

如果选了 CallerRunsPolicy，还要从提交线程的耗时和线程池外部的请求延迟一起验收；如果选了丢弃策略，则必须有业务明确证明任务过期可丢，并用计数器监控丢弃数量。

常见问题

为什么线程池没有满也会拒绝任务？

执行器关闭后会拒绝新任务，即使当前活动线程数很低。排查时先看生命周期状态，再看活动线程和队列容量。

能不能在拒绝处理器里自动重试？

不建议。处理器里等待或递归提交会让过载更严重，也难以控制重试次数。把任务交给有幂等键的补偿通道更容易验收。

什么时候可以使用 CallerRunsPolicy？

当提交线程可以承受任务耗时、并且业务确实希望通过阻塞生产者形成反压时可以考虑。不要把它当成无成本的“永不失败”。

把拒绝设计成可观察的业务边界

线程池参数决定何时拒绝，拒绝处理器决定怎样表达拒绝，调用方则决定是否补偿。三者要用同一个任务 ID、拒绝原因和最终状态串起来。这样出现高峰时，系统可以降速、补偿或停止，而不是让一条异常把任务命运藏起来。