线程池中的线程数量设置为多少比较合适？

影响因素

影响线程数设定的因素，主要有CPU核心数、以及应用类型。

CPU密集型应用

CPU密集型应用主要是指需要大量计算资源的应用，常见类型包括：

1. 科学计算：气象模拟、流体动力学模拟。
2. 图形渲染：3D动画制作、电影特效渲染。
3. 密码学运算：区块链挖矿、数据加密。
4. 机器学习和人工智能：神经网络训练、深度学习。
5. 金融分析：量化分析、高频交易。
6. 图像和视频处理：视频编辑、编码解码。
7. 编译器和代码分析：代码编译、大型软件项目编译。
8. 物理模拟：碰撞检测、物理引擎计算。
9. 数学计算：大数计算、符号计算。

这些应用依赖于强大的计算能力，多使用多线程和并行计算技术来提升性能。

IO密集型应用

IO密集型应用主要是指那些受限于输入/输出（I/O）操作速度的应用。常见的类型包括：

1. 数据库服务器：如MySQL、PostgreSQL。
2. 文件服务器：如NFS、Samba。
3. Web服务器：如Apache、Nginx。
4. 媒体流服务：如Netflix、YouTube。
5. 备份和恢复系统：如Acronis、Veeam。
6. 大数据处理和分析：如Hadoop、Spark。
7. 文件传输服务：如FTP服务器。
8. 日志记录和监控系统：如ELK Stack、Prometheus。
9. 分布式存储系统：如HDFS、Ceph、Amazon S3。

这些应用的性能主要受限于频繁的磁盘和网络读写操作，优化时需关注缓存、异步I/O等技术。

如何设定线程数

简单一点的话，可以根据应用类型来套用以下公式（但是，实际应用起来，也不要死守着公式不放，公式只是可以当作参考）：

• 如果是CPU密集型应用，则线程池线程数量大小设置为N+1 （N为CPU总核数 ）
• 如果是IO密集型应用，则线程池线程数量大小设置为2N+1 （N为CPU总核数）

但是，这两个公式不能无脑套用！

正确的设定方法为：没有固定答案，在项目刚上线的时候，先根据公式大致的设置一个预期数值，然后再根据你自己的实际业务情况，以及不断的压测结果，再不断调整，最终达到一个相对合理的值。

在说明压测的时候，要说清楚可接受的响应耗时是多少，大于这个阈值即是错误，错误率多少可接受。这样给出的线程池参数才合理。

为什么IO密集型应用的线程数量设置为2N+1？

在 IO 密集型应用中，线程多数时间等待 IO 操作而非消耗 CPU，因此增加线程数量能提高并发效率。经验公式 `2N+1` 中，`N` 是 CPU 核心数，2N 的线程数确保在 IO 等待时仍有线程执行计算，`+1` 确保至少一个线程始终工作。这样能充分利用 CPU 资源，避免因 IO 阻塞导致 CPU 闲置。

为什么cpu密集型应用的线程数设置为N+1？

在 CPU 密集型应用中，线程数通常设置为 `N+1`（`N` 为 CPU 核心数），这样能充分利用每个核心，并提供一个额外线程应对短暂阻塞，确保 CPU 不因偶然停顿而闲置。

真实程序中的线程数

那么在实际的程序中，或者说一些Java的业务系统中，线程数（线程池大小）规划多少合适呢？

先说结论：没有固定答案，先设定预期，比如我期望的CPU利用率在多少，负载在多少，GC频率多少之类的指标后，再通过测试不断的调整到一个合理的线程数

比如一个普通的，SpringBoot 为基础的业务系统，默认Tomcat容器+HikariCP连接池+G1回收器，如果此时项目中也需要一个业务场景的多线程（或者线程池）来异步/并行执行业务流程。

此时我按照上面的公式来规划线程数的话，误差一定会很大。因为此时这台主机上，已经有很多运行中的线程了，Tomcat有自己的线程池，HikariCP也有自己的后台线程，JVM也有一些编译的线程，连G1都有自己的后台线程。这些线程也是运行在当前进程、当前主机上的，也会占用CPU的资源。

所以受环境干扰下，单靠公式很难准确的规划线程数，一定要通过测试来验证。

流程一般是这样：

1. 分析当前主机上，有没有其他进程干扰
2. 分析当前JVM进程上，有没有其他运行中或可能运行的线程
3. 设定目标
4. 目标CPU利用率 - 我最高能容忍我的CPU飙到多少？
5. 目标GC频率/暂停时间 - 多线程执行后，GC频率会增高，最大能容忍到什么频率，每次暂停时间多少？
6. 执行效率 - 比如批处理时，我单位时间内要开多少线程才能及时处理完毕
7. ……
8. 梳理链路关键点，是否有卡脖子的点，因为如果线程数过多，链路上某些节点资源有限可能会导致大量的线程在等待资源（比如三方接口限流，连接池数量有限，中间件压力过大无法支撑等）
9. 不断的增加/减少线程数来测试，按最高的要求去测试，最终获得一个“满足要求”的线程数**

而且而且而且！不同场景下的线程数理念也有所不同：

1. Tomcat中的maxThreads，在Blocking I/O和No-Blocking I/O下就不一样
2. Dubbo 默认还是单连接呢，也有I/O线程（池）和业务线程（池）的区分，I/O线程一般不是瓶颈，所以不必太多，但业务线程很容易称为瓶颈
3. Redis 6.0以后也是多线程了，不过它只是I/O 多线程，“业务”处理还是单线程

所以，不要纠结设置多少线程了。没有标准答案，一定要结合场景，带着目标，通过测试去找到一个最合适的线程数。

可能还有同学可能会有疑问：“我们系统也没啥压力，不需要那么合适的线程数，只是一个简单的异步场景，不影响系统其他功能就可以”

很正常，很多的内部业务系统，并不需要啥性能，稳定好用符合需求就可以了。那么我的推荐的线程数是：CPU核心数