可能很多人都看到过一个线程数设置的实践：

  • CPU 密集型的程序 - 外围数 + 1
  • I/O 密集型的程序 - 外围数 * 2

不会吧，不会吧，真的有人依照这个实践布局线程数？

线程数和CPU的小测试

抛开一些操作系统，计算机原理不谈，说一个根本的实践（不必纠结是否谨严，只为好了解）：

一个CPU外围，单位工夫内只能执行一个线程的指令

那么实践上，我一个线程只须要不停的执行指令，就能够跑满一个外围的利用率。

来写个死循环空跑的例子验证一下：

测试环境：AMD Ryzen 5 3600, 6 - Core, 12 - Threads

public class CPUUtilizationTest {    public static void main(String[] args) {        //死循环，什么都不做        while (true){        }    }}

运行这个例子后，来看看当初CPU的利用率：

从图上能够看到，我的3号外围利用率曾经被跑满了

那基于下面的实践，我多开几个线程试试呢？

public class CPUUtilizationTest {    public static void main(String[] args) {        for (int j = 0; j < 6; j++) {            new Thread(new Runnable() {                @Override                public void run() {                    while (true){                    }                }            }).start();        }    }}

此时再看CPU利用率，1/2/5/7/9/11 几个外围的利用率曾经被跑满：

那如果开12个线程呢，是不是会把所有外围的利用率都跑满？答案肯定是会的：

如果此时我把下面例子的线程数持续减少到24个线程，会呈现什么后果呢？

从上图能够看到，CPU利用率和上一步一样，还是所有外围100%，不过此时负载曾经从11.x减少到了22.x（load average解释参考https://scoutapm.com/blog/understanding-load-averages），阐明此时CPU更忙碌，线程的工作无奈及时执行。

古代CPU根本都是多外围的，比方我这里测试用的AMD 3600，6外围12线程（超线程），咱们能够简略的认为它就是12外围CPU。那么我这个CPU就能够同时做12件事，互不打搅。

如果要执行的线程大于外围数，那么就须要通过操作系统的调度了。操作系统给每个线程调配CPU工夫片资源，而后不停的切换，从而实现“并行”执行的成果。

然而这样真的更快吗？从下面的例子能够看出，一个线程就能够把一个外围的利用率跑满。如果每个线程都很“王道”，不停的执行指令，不给CPU闲暇的工夫，并且同时执行的线程数大于CPU的外围数，就会导致操作系统更频繁的执行切换线程执行，以确保每个线程都能够失去执行。

不过切换是有代价的，每次切换会随同着寄存器数据更新，内存页表更新等操作。尽管一次切换的代价和I/O操作比起来微不足道，但如果线程过多，线程切换的过于频繁，甚至在单位工夫内切换的耗时曾经大于程序执行的工夫，就会导致CPU资源过多的节约在上下文切换上，而不是在执行程序，得失相当。

下面死循环空跑的例子，有点过于极其了，失常状况下不太可能有这种程序。

大多程序在运行时都会有一些 I/O操作，可能是读写文件，网络收发报文等，这些 I/O 操作在进行时时须要期待反馈的。比方网络读写时，须要期待报文发送或者接管到，在这个期待过程中，线程是期待状态，CPU没有工作。此时操作系统就会调度CPU去执行其余线程的指令，这样就完满利用了CPU这段闲暇期，进步了CPU的利用率。

下面的例子中，程序不停的循环什么都不做，CPU要不停的执行指令，简直没有啥闲暇的工夫。如果插入一段I/O操作呢，I/O 操作期间 CPU是闲暇状态，CPU的利用率会怎么样呢？先看看单线程下的后果：

public class CPUUtilizationTest {    public static void main(String[] args) throws InterruptedException {        for (int n = 0; n < 1; n++) {            new Thread(new Runnable() {                @Override                public void run() {                    while (true){                        //每次空循环 1亿 次后，sleep 50ms，模仿 I/O期待、切换                        for (int i = 0; i < 100_000_000l; i++) {                         }                        try {                            Thread.sleep(50);                        }                        catch (InterruptedException e) {                            e.printStackTrace();                        }                    }                }            }).start();        }    }}

哇，惟一有利用率的9号外围，利用率也才50%，和后面没有sleep的100%相比，曾经低了一半了。当初把线程数调整到12个看看：

单个外围的利用率60左右，和方才的单线程后果差距不大，还没有把CPU利用率跑满，当初将线程数减少到18：

此时单核心利用率，曾经靠近100%了。由此可见，当线程中有 I/O 等操作不占用CPU资源时，操作系统能够调度CPU能够同时执行更多的线程。

当初将I/O事件的频率调高看看呢，把循环次数减到一半，50_000_000，同样是18个线程：

此时每个外围的利用率，大略只有70%左右了。

线程数和CPU利用率的小总结

下面的例子，只是辅助，为了更好的了解线程数/程序行为/CPU状态的关系，来简略总结一下：

  1. 一个极其的线程（不停执行“计算”型操作时），就能够把单个外围的利用率跑满，多外围CPU最多只能同时执行等于外围数的“极其”线程数
  2. 如果每个线程都这么“极其”，且同时执行的线程数超过外围数，会导致不必要的切换，造成负载过高，只会让执行更慢
  3. I/O 等暂停类操作时，CPU处于闲暇状态，操作系统调度CPU执行其余线程，能够进步CPU利用率，同时执行更多的线程

  4. I/O 事件的频率频率越高，或者期待/暂停工夫越长，CPU的闲暇工夫也就更长，利用率越低，操作系统能够调度CPU执行更多的线程

    线程数布局的公式

    后面的铺垫，都是为了帮忙了解，当初来看看书本上的定义。《Java 并发编程实战》介绍了一个线程数计算的公式：

$$Ncpu=CPU 外围数$$

$$Ucpu=指标CPU利用率，0<=Ucpu<=1$$

$$\frac{W}{C}=等待时间和计算工夫的比例$$

如果心愿程序跑到CPU的指标利用率，须要的线程数公式为：

$$Nthreads=Ncpu*Ucpu*(1+\frac{W}{C})$$

公式很清晰，当初来带入下面的例子试试看：

如果我冀望指标利用率为90%（多核90），那么须要的线程数为：

外围数12 利用率0.9 (1 + 50(sleep工夫)/50(循环50_000_000耗时)) ≈ 22

当初把线程数调到22，看看后果：

当初CPU利用率大略80+，和预期比拟靠近了，因为线程数过多，还有些上下文切换的开销，再加上测试用例不够谨严，所以理论利用率低一些也失常。

把公式变个形，还能够通过线程数来计算CPU利用率：

$$Ucpu=\frac{Nthreads}{Ncpu*(1+\frac{W}{C})}$$

线程数22 / (外围数12 * (1 + 50(sleep工夫)/50(循环50_000_000耗时))) ≈ 0.9

尽管公式很好，但在实在的程序中，个别很难取得精确的等待时间和计算工夫，因为程序很简单，不只是“计算”。一段代码中会有很多的内存读写，计算，I/O 等复合操作，准确的获取这两个指标很难，所以光靠公式计算线程数过于理想化。

实在程序中的线程数

那么在理论的程序中，或者说一些Java的业务零碎中，线程数（线程池大小）布局多少适合呢？

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

比方一个一般的，SpringBoot 为根底的业务零碎，默认Tomcat容器+HikariCP连接池+G1回收器，如果此时我的项目中也须要一个业务场景的多线程（或者线程池）来异步/并行执行业务流程。

此时我依照下面的公式来布局线程数的话，误差肯定会很大。因为此时这台主机上，曾经有很多运行中的线程了，Tomcat有本人的线程池，HikariCP也有本人的后盾线程，JVM也有一些编译的线程，连G1都有本人的后盾线程。这些线程也是运行在以后过程、以后主机上的，也会占用CPU的资源。

不过对于业务零碎来说，个别这些线程不太会成为瓶颈

所以受环境烦扰下，单靠公式很难精确的布局线程数，肯定要通过测试来验证。

流程个别是这样：

  1. 剖析以后主机上，有没有其余过程烦扰
  2. 剖析以后JVM过程上，有没有其余运行中或可能运行的线程

  3. 设定指标

    1. 指标CPU利用率 - 我最高能容忍我的CPU飙到多少？
    2. 指标GC频率/暂停工夫 - 多线程执行后，GC频率会增高，最大能容忍到什么频率，每次暂停工夫多少？
    3. 执行效率 - 比方批处理时，我单位工夫内要开多少线程能力及时处理完毕
    4. ……
  4. 梳理链路关键点，是否有卡脖子的点，因为如果线程数过多，链路上某些节点资源无限可能会导致大量的线程在期待资源（比方三方接口限流，连接池数量无限，中间件压力过大无奈撑持等）
  5. 一直的减少/缩小线程数来测试，按最高的要求去测试，最终取得一个“满足要求”的线程数**

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

  1. Tomcat中的maxThreads，在Blocking I/O和No-Blocking I/O下就不一样
  2. Dubbo 默认还是单连贯呢，也有I/O线程（池）和业务线程（池）的辨别，I/O线程个别不是瓶颈，所以不用太多，但业务线程很容易称为瓶颈
  3. Redis 6.0当前也是多线程了，不过它只是I/O 多线程，“业务”解决还是单线程

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

可能还有同学可能会有疑难：“咱们零碎也没啥压力，不须要那么适合的线程数，只是一个简略的异步场景，不影响零碎其余性能就能够”

很失常，很多的外部业务零碎，并不需要啥性能，稳固好用合乎需要就能够了。那么我的举荐的线程数是：CPU外围数

附录

Java 获取CPU外围数

Runtime.getRuntime().availableProcessors()//获取逻辑外围数，如6外围12线程，那么返回的是12

Linux 获取CPU外围数

# 总核数 = 物理CPU个数 X 每颗物理CPU的核数 # 总逻辑CPU数 = 物理CPU个数 X 每颗物理CPU的核数 X 超线程数# 查看物理CPU个数cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l# 查看每个物理CPU中core的个数(即核数)cat /proc/cpuinfo| grep "cpu cores"| uniq# 查看逻辑CPU的个数cat /proc/cpuinfo| grep "processor"| wc -l
原创不易，转载请分割作者。如果我的文章对您有帮忙，请点赞/珍藏/关注激励反对一下吧❤❤❤❤❤❤