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

一调就崩 vs 一调就飞：线程池线程数究竟怎么定？

说起线程池配置，哈，我真是被坑怕了。那年刚进公司，小项目没几台服务器，公司却野心勃勃要“高并发”，我也青春年少，觉得线程多就是王道，甩手上了个Executors.newFixedThreadPool(1000)，哈哈哈，没想到，调着调着服务器直接进医院。

其实，线程池线程数这玩意儿吧，真不是多多益善。就像食堂窗口，窗口多了人手忙脚乱；窗口少了大家排长队，磨蹭得要死。究竟怎么配？我踩过的坑，今天就给大伙念叨念叨。

线程池为什么调着调着就崩？

刚开始我啥也不懂，直接怼

ExecutorService pool = Executors.newFixedThreadPool(1000); // 线程数随心情跳

理由很纯粹：线程多，速度快啊！结果发现，CPU Load 100%，Memory飙红，机器狂热，业务反而比单线程跑得还慢。更诡异的是，有次线程多了队列飘着两万任务卡死现场，没想到本地能飞，线上直接翘辫子。

后来明白了：

• 线程创建和上下文切换，其实有很大成本。
• CPU没变，线程多了只能排队，反而更慢。
• 线程太多还会因为资源抢夺（CPU、内存、锁）互相拖后腿。

简直一调就崩。一度怀疑人生。

线程池线程数到底怎么调？

其实Java官方有公式（我后来才知道，打脸），一句话总结：

线程数 = CPU核心数 × 效率因子

效率因子咋来？CPU密集型推荐1，IO密集型可以适当大一点。

举个栗子（纯CPU型）：

// 拿到机器核数
int coreCount = Runtime.getRuntime().availableProcessors();
// 算法型任务，一般线程数等于核心数
ThreadPoolExecutor pool = new ThreadPoolExecutor(coreCount, coreCount, ...);

要是多线程都是IO型的活？比如大量网络/磁盘操作，等IO时间多，那线程数可大胆放宽点：

• 线程数 ≈ CPU核心数 × 2~4

理由？IO时线程在等，CPU可以服务别的线程。
不过也别飙太高，内存和系统承载有极限。

踩坑瞬间

来，聊聊我被“线程数”这个小妖精坑最惨的瞬间：

• 线程数猛加，有的任务永远没执行——结果线程全在等IO，核心根本没时间轮到新活。
• 本地压测调了个顺滑数，线上CPU直冒烟才发现物理机核心压根没本地多。
• 系统明明不报错，但反应变慢，日志一看堆栈都是忙着切线程。

常见误区总结：

经验启示

写到这儿，给后来人来两句“踩坑经验”：

• 看任务类型分配线程数：CPU型别超过核心数，IO型别跑太激进。
• 监控先行，别盲调：先观察metrics，看CPU、内存、队列情况，有数据为王。
• 环境区别心中有数：开发、测试、生产机器配置不同，线程数要分开设。

小技巧：实在不懂，记住一个保命数——“CPU核数乘2”，先上线再慢慢精细调。

其实线程池这事，就像选鞋码，不合脚总出事。
调优说简单也简单，说细致能玩出花。
别心里没数乱上参，不然迟早“飞”着飞着、就崩了。

今天就聊到这，程序员也是要留点力气敲代码的不是？下回再唠，溜了！