Java 并发这块坑真多，线程池又给我上了一课

上周四凌晨，报警系统突然狂响------我们的订单履约服务在促销活动中完全崩溃。SLA 从 99.95% 暴跌到 82%，而这一切只是因为一个自以为没问题的 ThreadPoolExecutor 配置。

现象：线程池竟成了系统瓶颈

场景很简单：订单履约服务需要并行处理大量促销订单的物流计算。我们用了 CompletableFuture + 自定义线程池来并发执行，核心配置如下：

java 复制代码

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    20,  // corePoolSize
    200, // maximumPoolSize
    60,  // keepAliveTime
    TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(1000) // 自以为足够大的队列
);

上线前压测一切正常，但流量高峰时突然出现：

请求延迟从 200ms 飙升到 30s+
监控显示 active threads 始终卡在 20（即 corePoolSize）
队列堆积 800+ 任务却不见扩容

你是不是也遇到过这种"线程池不按预期工作"的情况？

根因：队列与扩容的隐藏规则

关键问题出在 ThreadPoolExecutor 的任务处理逻辑上。很多人以为任务提交的顺序是：

优先用 corePool
不够就扩容到 maxPool
还不够才入队列

实际上 JDK 的默认策略是相反的**：**

**```java
// java.util.concurrent.ThreadPoolExecutor#execute
public void execute(Runnable command) {
if (workerCount < corePoolSize) {
addWorker(command, true); // 第一步：先尝试占满 corePool
} else if (workQueue.offer(command)) { // 第二步：队列能入队就入队！
// 注意这里可能造成队列无限堆积
} else {
addWorker(command, false); // 第三步：队列满了才触发扩容
}
}

复制代码

这就是为什么我们的系统：
* 初始时 20 个核心线程迅速占满
* 后续任务全部进入 `LinkedBlockingQueue`，** 永远不会触发 maxPool 扩容

* 队列堆积导致延迟爆炸，而线程数始终卡在 20

### 解法：两种正确姿势

#### 方案1：想让线程数弹性伸缩？用 SynchronousQueue

如果希望任务优先扩容线程而非入队：

```java
ThreadPoolExecutor executor = new ThreadPoolExecutor(
    20,
    200,
    60,
    TimeUnit.SECONDS,
    new SynchronousQueue<>() // 不存储任务，直接尝试交给线程
);

代价是：当线程数达到 maxPoolSize 时，新任务会直接触发 RejectedExecutionException

方案2：控制队列与扩容的平衡

更推荐的策略是明确队列容量与 maxPoolSize 的关系：

java 复制代码

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    20,
    200,
    60,
    TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(100), // 有界队列
    new ThreadPoolExecutor.CallerRunsPolicy() // 队列满后降级
);

此时行为变成：

20 核心线程 → 2. 入队 100 任务 → 3. 扩容到 200 线程 → 4. 最终由调用线程直接执行

数据对比与代价

配置方案	吞吐量（QPS）	P99延迟	资源占用
错误配置（无界队列）	1200	28s	低
SynchronousQueue	1800	210ms	高
有界队列+降级	1600	350ms	中

关键结论**：无界队列在突发流量下是定时炸弹，而 SynchronousQueue 需要接受更高的拒绝率。**

### 线程池避坑清单
1. 队列选择陷阱**：

LinkedBlockingQueue 默认无界（Integer.MAX_VALUE），OOM 前不会有拒绝
ArrayBlockingQueue 必须显式设容量
SynchronousQueue 适合"立即执行或拒绝"场景
1.** 拒绝策略漏配**：
默认 AbortPolicy 会抛异常导致上游故障
考虑 CallerRunsPolicy 或自定义降级逻辑
1.** 线程回收问题**：
只有非核心线程会回收，设置 allowCoreThreadTimeOut(true) 需谨慎
线程泄漏常见于未正确处理 ThreadLocal
1.** 上下文传递风险：
子线程会丢失 MDC/RequestContext，需通过装饰器传递：

java 复制代码

     executor = new ContextPropagatingExecutorWrapper(executor);

现在看这个问题可能觉得低级，但当你盯着监控图发现 poolSize 死活不涨时，那种绝望感懂的都懂。你在项目中是怎么处理线程池配置的？欢迎在评论区聊聊你的踩坑经历。