线程池中的坑：线程数配置不当导致任务堆积与拒绝策略失效

“线程池我不是早就会了吗？corePoolSize、maxPoolSize、queueSize 都能背下来！”

—— 真正出事故的时候你就知道，配置这仨数，坑多得跟高考数学题一样。

一、线上事故复盘：任务全卡死，日志一片寂静

几个月前有个定时任务服务，凌晨会并发处理上千个文件。按理说线程池能轻松抗住。

结果那天凌晨，监控报警：任务积压 5 万条，机器 CPU 却只有 3%！

去看线程 dump：

pool-1-thread-1 waiting on queue.take()  

pool-1-thread-2 waiting on queue.take()  

...

线程都在等任务，但任务明明在队列里！

当时线程池配置如下：

new ThreadPoolExecutor(
5,
10,
60L, TimeUnit.SECONDS,
new LinkedBlockingQueue<>(10000),
new ThreadPoolExecutor.AbortPolicy()

);

看起来没毛病对吧？

实际结果是：拒绝策略从未生效、maxPoolSize 永远没机会触发。

二、真相：线程池参数不是你想的那样配的

要理解问题，得先知道 ThreadPoolExecutor 的任务提交流程。

任务提交 → 核心线程是否满？
    ↓ 否 → 新建核心线程

    ↓ 是 → 队列是否满？

        ↓ 否 → 放入队列等待

        ↓ 是 → 是否小于最大线程数？

            ↓ 是 → 创建非核心线程

            ↓ 否 → 拒绝策略触发

也就是说：

只要队列没满，线程池就不会创建非核心线程。

所以：

• 
  
• 你的 corePoolSize = 5；
  
• 队列能放 10000 个任务；
  
• maxPoolSize = 10 永远不会触发；
  
• 线程永远就那 5 个在干活；
  
• 队列里的任务越堆越多，拒绝策略永远“假死”。
  

三、踩坑场景实录

四、正确配置姿势（我现在都这么配）

思路很简单：

“小队列 + 合理核心数 + 合理拒绝策略”

而不是 “大队列 + 盲目扩大线程数”。

例如 CPU 密集型任务：

int cores = Runtime.getRuntime().availableProcessors();

ThreadPoolExecutor executor = new ThreadPoolExecutor(

    cores + 1, 

    cores + 1,

    0L, TimeUnit.MILLISECONDS,

    new LinkedBlockingQueue<>(100),

    new ThreadPoolExecutor.CallerRunsPolicy()

);

IO 密集型任务：

int cores = Runtime.getRuntime().availableProcessors();

ThreadPoolExecutor executor = new ThreadPoolExecutor(

    cores * 2,

    cores * 4,

    60L, TimeUnit.SECONDS,

    new LinkedBlockingQueue<>(200),

    new ThreadPoolExecutor.CallerRunsPolicy()

);

关键思想：

• 
  
• 宁可拒绝，也不要堆积。
  
• 拒绝意味着“系统过载”，堆积意味着“慢性自杀”。
  

五、拒绝策略的“假死”与自定义方案

内置的 4 种拒绝策略：

• 
  
• AbortPolicy：直接抛异常（最安全）
  
• CallerRunsPolicy：调用方线程执行（可限流）
  
• DiscardPolicy：悄悄丢弃任务（最危险）
  
• DiscardOldestPolicy：丢最老的（仍可能乱序）
  

如果你想更智能一点，可以自定义：

new ThreadPoolExecutor.AbortPolicy() {
@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {

        log.warn("任务被拒绝，当前队列：{}", e.getQueue().size());
// 可以上报监控 / 发报警

    }

};

六、监控才是救命稻草

别等到队列堆积了才发现问题。

我建议给线程池加实时监控，比如：

ScheduledExecutorService monitor = Executors.newScheduledThreadPool(1);

monitor.scheduleAtFixedRate(() -> {

    log.info("PoolSize={}, Active={}, QueueSize={}",

             executor.getPoolSize(),

             executor.getActiveCount(),

             executor.getQueue().size());

}, 0, 5, TimeUnit.SECONDS);

这样你能第一时间看到线程数没涨、队列在爆。

🧠 七、总结（踩坑后记）

最后一句话：

“线程池是救命的工具，用不好就变慢性毒药。”

✍️ 写在最后

如果你看到这里，不妨想想自己的系统里有多少个 newFixedThreadPool、多少个默认 LinkedBlockingQueue 没有限制大小。

你以为是“优化”，其实是定时炸弹。