线程池拒绝策略的“补偿”逻辑：实战实现一个将拒绝任务重新放回队列末尾的动态控制策略-Java面试题-PHP中文网

不能直接offer()是因为队列可能仍满导致任务丢失、缺乏重试控制易阻塞线程、忽略动态水位无法自适应；需有限重试、背压退避与运行时条件判断。

线程池拒绝策略的“补偿”逻辑：实战实现一个将拒绝任务重新放回队列末尾的动态控制策略

线程池拒绝任务时，直接丢弃或抛异常往往不够灵活。一种常见补偿思路是：不放弃任务，而是尝试将其“塞回”工作队列末尾，等待后续线程消费——但这不是简单调用 queue.offer() 就能生效的，需兼顾线程安全、重试边界与动态调控能力。

为什么不能直接 offer() 就完事？

ThreadPoolExecutor 的拒绝发生在 execute() 方法末尾，此时任务已确定被拒（比如队列满+线程数已达 maximumPoolSize）。若在拒绝策略中直接调用 workQueue.offer(runnable)，存在几个关键问题：

队列可能仍满：offer() 可能返回 false，导致任务彻底丢失；
缺乏重试控制：无限循环 offer 会阻塞拒绝线程（如主线程），引发雪崩；
忽略动态水位：队列长度、活跃线程数、系统负载都在变化，应根据实时状态决定是否重试、重试几次、间隔多久。

实现一个带动态控制的“回塞”拒绝策略

核心目标：在拒绝时，有限次尝试将任务重新入队，并支持根据线程池运行态自适应调整行为。下面是一个生产可用的简化实现：

注意：该策略适用于 LinkedBlockingQueue 或 ArrayBlockingQueue 等支持 offer() 的队列，且要求线程池配置为 CallerRunsPolicy 以外的拒绝策略（如 AbortPolicy）并被替换。

public class RetryableRejectionPolicy implements RejectedExecutionHandler {
    private final int maxRetry;
    private final long backoffMs;
    private final Supplier<boolean> shouldRetry;
<pre class="brush:php;toolbar:false;">public RetryableRejectionPolicy(int maxRetry, long backoffMs) {
    this(maxRetry, backoffMs, () -> true);
}

public RetryableRejectionPolicy(int maxRetry, long backoffMs,
                                Supplier<boolean> shouldRetry) {
    this.maxRetry = Math.max(0, maxRetry);
    this.backoffMs = Math.max(0, backoffMs);
    this.shouldRetry = shouldRetry;
}

@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
    if (r == null || executor == null) return;

    // 1. 先检查是否允许重试（动态条件）
    if (!shouldRetry.get()) {
        // 不满足条件，走兜底（如记录日志 + 抛异常 or 丢弃）
        throw new RejectedExecutionException("Task " + r + " rejected, retry disabled");
    }

    boolean offered = false;
    int attempt = 0;

    // 2. 有限次尝试入队
    while (attempt <p>}</p></boolean>