Java 线程池队列过长怎样设置背压

Java 线程池队列一直变长时，最直接的背压做法不是继续把队列调大，而是把无界队列改成有界队列，再配合明确的最大线程数和拒绝策略。对不能随便丢失的普通任务，可以优先考虑 CallerRunsPolicy：当线程池和队列都满了，提交任务的线程会暂时自己执行任务，提交速度自然被任务耗时拉慢。

这是一种简单的同步反馈，不等于完整的流量治理。队列容量、线程数和拒绝策略仍要根据任务耗时、调用方是否允许阻塞以及是否可以丢弃任务来定。

推荐的最小组合是：有限的 ArrayBlockingQueue、有限的 maximumPoolSize、可解释的 RejectedExecutionHandler。需要让提交方自动降速时，再使用 CallerRunsPolicy。

本文要点：无界队列只是在积压，不会形成压力反馈；有界队列负责给系统设上限；CallerRunsPolicy 负责把饱和信号传回提交线程。

先把线程池的容量边界画清楚

ThreadPoolExecutor 的提交逻辑可以按三个边界理解：先创建不超过 corePoolSize 的工作线程；核心线程忙时尝试放入工作队列；队列放不下时，才继续创建线程直到 maximumPoolSize。三者都达到上限后，才进入拒绝处理。

因此，使用无界的 LinkedBlockingQueue 时，队列通常一直能接收任务，maximumPoolSize 就很难发挥作用；生产者比消费者快得久了，积压会转化为内存占用和越来越长的等待时间。

有界队列把问题提前暴露出来。下面的数字只是可调整的起点：4 个核心线程、8 个最大线程、容量 100 的队列，表示系统最多允许一段有限的缓冲和并发，而不是承诺能稳定处理每秒 100 个任务。

int coreThreads = 4;
int maxThreads = 8;
int queueCapacity = 100;

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    coreThreads,
    maxThreads,
    30L,
    TimeUnit.SECONDS,
    new ArrayBlockingQueue(queueCapacity),
    new ThreadPoolExecutor.CallerRunsPolicy()
);

// 让线程名称能体现用途，便于日志中区分不同线程池。
executor.setThreadFactory(r -> {
    Thread thread = new Thread(r);
    thread.setName("order-worker-" + thread.getId());
    return thread;
});

这里的关键不是某个固定数字，而是三个参数要一起看：队列大一些可以吸收短时突发，但会增加等待；线程多一些可能提高 I/O 型任务的吞吐，也会增加上下文切换和下游压力；上限必须能解释。

让 CallerRunsPolicy 把压力传回提交方

队列满、线程数也到上限时，CallerRunsPolicy 不再把任务交给池内的 Worker，而是让调用 execute 的线程直接运行这个 Runnable。如果提交线程是消费请求的业务线程，它会在执行任务期间停止继续提交，形成最直观的反馈回路。

void submitOrderTasks(ThreadPoolExecutor executor, List orders) {
    for (Order order : orders) {
        // 队列与工作线程都饱和时，调用方会同步执行这个任务。
        executor.execute(() -> processOrder(order));
    }
}

void processOrder(Order order) {
    // 真实项目中应在这里处理超时、幂等和可重试边界。
    orderService.save(order);
}

这个策略的代价也很明确：提交线程可能被长任务阻塞，接口延迟会抬高；如果提交线程持有锁、运行在事件循环中，或不允许执行重任务，就不能直接套用。此时可以改为记录拒绝、快速失败，或把任务交给带容量控制的外部队列。

按任务可靠性选择拒绝处理

背压首先是容量问题，其次才是策略问题。不要为了让接口“看起来不报错”而静默丢任务。

如果使用 AbortPolicy，上层必须有处理拒绝的路径；如果使用自定义处理器，至少要记录任务类型、队列长度和拒绝次数，并避免在拒绝回调里再次无条件提交同一个池，否则可能形成递归或忙循环。

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    4,
    8,
    30L,
    TimeUnit.SECONDS,
    new ArrayBlockingQueue(100),
    // 业务任务不能静默丢失，所以让上层看到拒绝。
    new ThreadPoolExecutor.AbortPolicy()
);

try {
    executor.execute(task);
} catch (RejectedExecutionException ex) {
    // 这里可以返回“系统繁忙”、进入可靠重试或切换到外部队列。
    rejectCounter.increment();
    throw ex;
}

用最小指标判断背压是否真的生效

不要只盯着队列当前长度。至少同时观察 getQueue().size()、getActiveCount()、getPoolSize()、完成任务数和拒绝次数，并结合任务等待时间。队列偶尔升高后迅速回落，可能只是正常突发；队列长期接近容量且拒绝持续增加，说明消费能力不足或下游已经成为瓶颈。

复查时可以按下面的顺序做判断：

1. 先确认队列是否有界，避免把“最大线程数”误认为完整容量。
2. 再比较任务平均耗时和调用方提交速度，确认背压发生在预期位置。
3. 最后核对拒绝策略是否符合任务可靠性，特别是是否存在静默丢失。

关闭线程池时也要保留收尾路径。shutdown() 只是不再接收新任务，不会等待已有任务完成；需要等待时再配合 awaitTermination，避免应用退出时把排队任务误当成已经处理。

常见问题

队列容量越大，吞吐量一定越高吗？

不一定。大队列能吸收短时突发，却会拉长等待时间，也可能让最大线程数几乎没有机会扩展。应结合任务耗时和下游承载能力调参。

CallerRunsPolicy 会不会让接口变慢？

会，这是它形成反馈的方式。它适合可以接受提交方短暂阻塞的场景；若提交线程是事件循环或持有关键锁，应换成显式拒绝、异步缓冲或外部队列。

什么时候应该直接使用 AbortPolicy？

当任务不能静默丢失，但调用方也不能代执行时，使用 AbortPolicy 并让上层明确处理拒绝，通常比把任务悄悄丢掉更容易恢复和追踪。