原文来自于：https://zha-ge.cn/java/98

Java线程池那些坑：我与线程池的恩怨情仇

有时候，觉得写Java就像带熊孩子。你以为“线程”分分钟搞定，不就是new Thread(runnable).start()多敲几下么？Too young，too naive，躺平的你总有一天要被线程数爆表狠狠教育。

但故事嘛，总有转折。那天领导突发奇想：来，整个百万级并发。🐶

闲聊一句：啥叫线程池？

线程池（ThreadPool），顾名思义，就是线程大本营。你提交任务，它找线程“打零工”；不用再开新线程，而是回收、循环再用。说白了，就是：

• 重复利用，减少资源消耗；
• 支撑大规模并发，不至于把服务器跑死。

听起来跟共享单车差不多：车永远不够，但调度妙，骑到就有。

初见线程池

那会儿我还清纯，Ctrl+C、Ctrl+V贴了段Spring教程里的套路：

ExecutorService pool = Executors.newFixedThreadPool(10);
for (int i = 0; i < 100; i++) {
    pool.execute(() -> doSomething());
}
// …
pool.shutdown();

一切安好。100个任务，10个线程轮流干活儿。线程池兢兢业业，背地里帮我调度。只要活不是太多，场面还hold得住。

踩坑瞬间

风平浪静中，总有暗礁。后来有次，接口突然“爸爸级”访问量。我天真地加了行：

ExecutorService pool = Executors.newCachedThreadPool();

一顿大操作，服务器内存直接干爆。日志里红彤彤一片OutOfMemoryError——老哥们都淹死在线程海了。

为什么？原来newCachedThreadPool()不做数量限制，爱启多少启多少！百万请求，百万线程，服务器CPU和内存都当我透明的……

更扎心的还有Executors.newSingleThreadExecutor()假装安全，但任务不及时清理，hold住所有请求卡成PPT翻页。

那会儿真想薅作者头发。后来明白，线程池四个关键参数：

• 核心线程数（corePoolSize）
• 最大线程数（maximumPoolSize）
• 队列长度（workQueue）
• 拒绝策略（rejectedExecutionHandler）

每一样都是打仗能不能赢的关键装备，马虎不得。

线程池底层小插曲

给你们看个关键代码，理解池子咋帮你调度：

if (workerCount < corePoolSize) {
    addWorker(command);
} else if (workQueue.offer(command)) {
    // 任务进队列，线程还够
} else if (workerCount < maxPoolSize) {
    addWorker(command);
} else {
    reject(command); // 尴尬，线程爆了只能拒绝
}

大致流程：

1. 有闲人就直接执行；
2. 没人了先扔队列；
3. 还不够就临时多找人帮忙；
4. 实在不行，对不起，给你一闷棍（拒绝策略）。

经验启示

• **一定要自定义线程池参数！**别偷懒用Executors.xxxThreadPool()。生产里手动写死最安心。
• 队列过长=积压，太短=频繁拒绝；合理配合业务量调节。
• **线程池不是万能药。**池子再高级，硬件不够照样跪。
• 注意线程安全问题，别以为交给池子就高枕无忧。
• 打印个活跃线程数和队列大小日志，时刻关心池子温度。

表格速查一波：

扯点闲篇收个尾巴

Java线程池挺像“打怪刷副本”——boss很多，组队分工。但别太迷信“大锅饭”：参数得自己掌控，池子别乱用。工作原理、适用场景心里有数，线上才不被坑。

最后提醒一句：别小看每一行线程池代码。不然下次，线上告警弹窗的时候，哭的就是你啦！