Java 线程池任务堆积怎么定位：队列容量、拒绝策略与线程状态检查

线上接口突然变慢时，监控面板里的线程数经常会给出一个误导性答案：活动线程只有 4 个，看起来并不忙，但队列里已经压着几千个任务。对 ThreadPoolExecutor 来说，任务是先进入线程池的接纳路径，再根据队列和线程上限决定后续动作；只看“当前有几个线程在跑”，很容易漏掉真正的瓶颈。

任务堆积的核心判断逻辑，是对比相邻采样点的队列增量、消费速度和提交速率的差值，单看某一个时刻的队列快照没法区分短时峰值和持续失控。

先用四个指标确认是不是“真的堆积”

第一步不是改参数，而是把同一时刻的状态放在一起看。getActiveCount() 表示当前大致正在执行任务的线程数，getPoolSize() 表示当前线程数，getQueue().size() 反映等待区长度，getCompletedTaskCount() 则可以和一段时间前的采样做差，观察消费速率。它们是瞬时读数，不能当作严格事务快照，但足以帮助判断方向。

用有界队列复现“线程不忙但任务很多”

下面的示例把核心线程数设为 2，最大线程数设为 4，队列容量设为 8，并让每个任务模拟较慢的下游调用。提交速度明显快于处理速度时，队列会先增长；在这个阶段，线程池可能仍然停留在核心线程数，不能只根据 maximumPoolSize 推断它应该马上创建更多线程。

import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

ThreadPoolExecutor pool = new ThreadPoolExecutor(
        2, 4, 30, TimeUnit.SECONDS,
        new ArrayBlockingQueue(8),
        new ThreadPoolExecutor.AbortPolicy());

for (int i = 0; i  {
        try {
            TimeUnit.MILLISECONDS.sleep(300);
            System.out.println("finished=" + taskId);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    });
}

你跑这个测试不用追求所有任务都执行成功，重点是把线程池的任务接纳流程跑通：先分配给空闲核心线程，塞不下就往队列里放；等队列也满了，才会创建非核心线程直到最大线程数，所有路径都堵死才走拒绝逻辑。线上环境的队列容量、任务超时时间一定得跟着实际流量做压测调优，别直接抄示例里的数字直接上生产。

建立连续采样，而不是只看一次快照

光看某一时刻队列里堆了 500 个任务，根本分不清是突增流量带来的短时峰值马上就能消化完，还是已经持续失控的积压。你可以按照业务调用的周期定时采样，每次记录当前队列长度、活动线程数、线程池总大小、已接收任务总数、已完成任务总数，再对比前后两次采样的差值判断趋势。注意采样逻辑本身要足够轻，别直接把队列里的任务对象完整打印到日志里，到头来排查工具本身给系统添了额外负载。

static void sample(ThreadPoolExecutor pool) {
    System.out.printf(
            "active=%d pool=%d largest=%d queue=%d completed=%d task=%d shutdown=%s%n",
            pool.getActiveCount(),
            pool.getPoolSize(),
            pool.getLargestPoolSize(),
            pool.getQueue().size(),
            pool.getCompletedTaskCount(),
            pool.getTaskCount(),
            pool.isShutdown());
}

例如连续三次采样得到 queue=120, 180, 260，同时 completed 的增量越来越小，就应该优先追查消费端耗时；如果队列下降但拒绝数仍增加，则还要检查提交端是否在多个线程池实例上重复提交，或旧实例正在关闭。

队列打满后，先确认拒绝策略有没有吞掉信号

ThreadPoolExecutor 默认使用 AbortPolicy，拒绝时抛出 RejectedExecutionException，调用方可以据此降级、重试或返回明确错误。DiscardPolicy 会静默丢弃任务，不适合对可靠性有要求的业务；CallerRunsPolicy 会让提交任务的线程执行被拒绝的任务，能够形成反压，但也可能把接口线程拖慢。

class CountingRejectHandler implements java.util.concurrent.RejectedExecutionHandler {
    private final java.util.concurrent.atomic.LongAdder rejected =
            new java.util.concurrent.atomic.LongAdder();

    @Override
    public void rejectedExecution(Runnable task, ThreadPoolExecutor executor) {
        rejected.increment();
        if (executor.isShutdown()) {
            throw new IllegalStateException("pool is shutting down");
        }
        throw new java.util.concurrent.RejectedExecutionException(
                "queue=" + executor.getQueue().size());
    }

    long rejectedCount() {
        return rejected.sum();
    }
}

自定义拒绝策略至少要把当前拒绝计数、队列瞬时长度、线程池是否已经标记关闭这几个核心信息埋到监控里。要不要重试完全看业务本身的属性：支付、库存扣减这类核心任务，别指望靠无限重试把容量不足的问题盖过去；允许丢数据的配置刷新、非核心统计类任务，也要在指标里明确标记丢弃状态，不能假装任务提交成功了瞒过告警。

把排查结论落到三个可执行动作

• 队列持续上升且下游耗时变长：先限制提交速率或做批量化，再定位外部调用、锁竞争和慢查询；不要直接无限增大队列。
• 队列上限太小但任务很短：用压测重新估算峰值并发，确认最大线程数、队列容量和内存预算后再调整。
• 拒绝发生在应用关闭期间：把关闭顺序、等待时间和提交方感知写进生命周期测试，避免新请求继续投递到已停止的线程池。

常见问题

为什么活动线程只有核心数，最大线程数却没有用满？

线程池通常会先尝试把任务放进工作队列，只有队列无法接纳时才继续创建线程直到最大数。要结合队列状态和构造参数判断，不能只看最大线程数。

队列容量是不是越大越好？

不是。队列越大，短期内越不容易触发拒绝，但任务等待时间、内存占用和故障恢复时间也可能变长。容量应由任务对象大小、可接受延迟和峰值流量共同决定。

CallerRunsPolicy 适合所有接口吗？

不适合。它会把任务执行成本转移给提交线程，能形成反压，却可能阻塞请求线程或消息消费线程。只有确认调用方能承受这段执行时间时才使用。

只记录队列长度够不够？

不够。至少同时记录活动线程、池大小、完成任务数、拒绝数和关闭状态，最好再关联任务耗时分位数，才能区分生产过快、消费变慢和生命周期误用。

上线前的线程池验收清单

给每个线程池补上有界队列、拒绝计数、连续采样和关闭测试，再用一次接近峰值的压测验证三个结果：队列能够回落、拒绝能够被业务感知、关闭后不会继续接收新任务。这样定位任务堆积时，监控数据会直接指向生产速率、消费延迟或生命周期问题，而不是停留在“把线程数调大”的猜测上。