如何用线程池处理异步任务，避免队列积压

线程池出现队列积压，根因几乎从来不是"线程开得太少"，而是用了无界队列：new LinkedBlockingQueue<>() 的默认容量是 Integer.MAX_VALUE（2147483647），队列永远填不满，于是 maximumPoolSize 永远不会生效，任务只会无声无息地堆在队列里，直到 OOM 或接口大面积超时。结论：把队列改成有界队列、把线程数按业务算准、配一个明确的拒绝策略并持续监控 queue.size()，四点做到就能避免积压。

为什么线程池会积压？先搞清 ThreadPoolExecutor 的调度顺序

结论：ThreadPoolExecutor 的扩容顺序是"核心线程 → 入队 → 扩到最大线程 → 拒绝"，队列在最大线程之前，所以队列容量决定了线程池能不能真正扩容。

JDK 1.5 至今，ThreadPoolExecutor.execute() 的判定逻辑是：

1. 运行线程数 < corePoolSize，直接新建核心线程执行；
2. 否则任务入 workQueue；
3. 队列满了且线程数 < maximumPoolSize，新建非核心线程；
4. 队列满且线程数已达上限，触发 RejectedExecutionHandler。

很多人把 corePoolSize=8、maximumPoolSize=64 当成"忙了会自动扩到 64"，但只要队列没满，第 3 步永远走不到。所以 LinkedBlockingQueue 配 maximumPoolSize 是典型的无效配置。

线程池参数怎么设？corePoolSize、队列容量、最大线程数

结论：队列容量建议 200～1000，CPU 密集型任务 core = 核数 + 1，IO 密集型按"目标 QPS × 平均耗时(秒)"估算，再用有界队列兜住突发流量。

线程数估算公式：线程数 = 目标QPS × 平均响应时间(秒) ÷ 目标CPU利用率。例如目标 500 QPS、平均耗时 50ms、利用率 0.8，则 500 × 0.05 ÷ 0.8 ≈ 32 个线程。队列容量则按可接受延迟倒推：队列容量 ÷ 消费速率 = 最坏排队时长，500 容量、32 线程、每任务 50ms，最坏排队约 500 ÷ (32 ÷ 0.05) ≈ 0.78 秒，可接受就定 500。

一个可直接抄的配置：

ThreadPoolExecutor pool = new ThreadPoolExecutor(
    32,                               // corePoolSize
    64,                               // maximumPoolSize，队列满后才用得上
    60L, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(500),    // 有界队列，关键
    new NamedThreadFactory("order-task-%d"),
    new ThreadPoolExecutor.CallerRunsPolicy()
);

队列满了怎么办？四种拒绝策略怎么选

结论：不能丢的任务用 CallerRunsPolicy 做背压，能重试的用 AbortPolicy 快速失败并配合上游重试，DiscardPolicy 和 DiscardOldestPolicy 在业务系统里基本不该用。

CallerRunsPolicy 会让提交任务的线程（比如 Tomcat 的 HTTP 工作线程）自己跑这个任务，天然形成背压，把压力传回上游；代价是调用方被阻塞，如果任务耗时长，可能把 Web 容器线程池拖垮。AbortPolicy 抛 RejectedExecutionException，必须在上游捕获并降级（返回"系统繁忙"或写 MQ 重试），否则异常会直接冒到用户。

怎么监控线程池有没有积压？

结论：核心指标是 getQueue().size() 与 getActiveCount() 的比值，队列占用持续超过容量的 70% 就该告警。

需要盯的四个值：getPoolSize()（当前线程数）、getActiveCount()（活跃线程数）、getQueue().size()（排队数）、getCompletedTaskCount()（已完成数）。注意 getQueue().size() 在 LinkedBlockingQueue 上是原子变量，开销可控；但 getActiveCount() 会遍历 Worker，QPS 高的地方别每秒调。更稳的做法是继承 ThreadPoolExecutor 重写 beforeExecute/afterExecute，用 Micrometer 或 Prometheus 打点，再配 queueSize / capacity > 0.7 持续 1 分钟告警。

异步任务本身还要注意什么？

结论：每个任务必须有超时和幂等，且不同业务用独立线程池隔离。

CompletableFuture.supplyAsync(task, pool).orTimeout(3, TimeUnit.SECONDS) 能给任务加硬超时，避免个别慢任务长期占住线程。任务要幂等（用业务唯一键去重），因为超时后上游重试会重复提交。另外别全公司共用一个线程池：订单、推送、报表各用各的，否则报表任务把线程占满，订单会跟着一起积压。运行时可以用 setCorePoolSize()、setMaximumPoolSize() 动态调整，但队列容量创建后改不了，所以容量要预留余量，必要时换池。

总结：积压的解法是把"无界队列 + 大 maximumPoolSize"这套假扩容换掉——有界队列触发扩容，拒绝策略提供背压，监控指标提前预警，超时与幂等兜住尾部异常。