ThreadPoolExecutor活跃线程数小于池大小时仍排队问题排查

你的问题核心在于无界队列与ThreadPoolExecutor线程创建逻辑的本质冲突，再结合几个可能的配置细节，导致了当前的现象，下面逐一拆解：

1. 无界队列直接限制线程池的线程创建上限为核心线程数 #

ThreadPoolExecutor的官方执行逻辑是：

1. 若当前运行线程数 < corePoolSize：直接创建新线程执行任务
2. 若当前运行线程数 >= corePoolSize：将任务加入队列
3. 若队列已满且运行线程数 < maxPoolSize：创建新线程直到达到maxPoolSize
4. 若队列已满且运行线程数 >= maxPoolSize：触发拒绝策略

当你使用无界队列（比如LinkedBlockingQueue未指定容量）时，队列永远不会满，步骤3和4永远不会触发。也就是说，线程池最多只会创建corePoolSize（128）个线程，绝不会超过这个数。

那为什么你的活跃线程数连128都没到？这就要看下面几个细节：

2. 核心线程未被完全创建的可能原因 #

• 线程池懒加载特性：ThreadPoolExecutor默认不会预先创建所有核心线程，而是在任务提交时逐个按需创建。如果任务提交速度不是爆发式的，线程池可能还没来得及创建满128个核心线程，就已经有任务开始排队了。你可以调用prestartAllCoreThreads()方法，预先启动所有核心线程，消除这个延迟。
• allowCoreThreadTimeOut参数被误设为true：这个参数默认是false，若被改成true，核心线程在空闲时会按照keepAliveTime超时销毁，导致活跃线程数降到低于corePoolSize。当新任务涌入时，线程池需要重新创建线程，但线程创建有开销，此时任务会先进入队列排队，直到新线程初始化完成。检查并确保这个参数为false。
• ThreadPoolExecutorWithMetrics包装类的干扰：如果这个自定义包装类重写了execute()、addWorker()等核心方法，可能意外修改了线程的创建逻辑。可以暂时替换为原生ThreadPoolExecutor测试，确认是否是包装类导致的问题。

3. 解决建议 #

• 若需要用到maxPoolSize的线程：放弃无界队列，改用有界队列（比如ArrayBlockingQueue），并合理设置队列容量。当队列满时，线程池会自动创建新线程直到达到maxPoolSize。
• 预先初始化核心线程：调用prestartAllCoreThreads()让所有核心线程提前就绪，避免任务来时的线程创建延迟。
• 检查核心线程超时配置：确保allowCoreThreadTimeOut为false，维持核心线程池的稳定。
• 验证包装类逻辑：确认ThreadPoolExecutorWithMetrics仅做指标采集，未修改原生线程池的执行逻辑。

内容的提问来源于stack exchange，提问作者CuriousCoder