起源:juejin.cn/post/6948034657321484318
可能很多人都看到过一个线程数设置的实践:
- 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 解释参考 scoutapm.com/blog/unders…),阐明此时 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 状态的关系,来简略总结一下:
- 一个极其的线程(不停执行“计算”型操作时),就能够把单个外围的利用率跑满,多外围 CPU 最多只能同时执行等于外围数的“极其”线程数
- 如果每个线程都这么“极其”,且同时执行的线程数超过外围数,会导致不必要的切换,造成负载过高,只会让执行更慢
- I/O 等暂停类操作时,CPU 处于闲暇状态,操作系统调度 CPU 执行其余线程,能够进步 CPU 利用率,同时执行更多的线程
- I/O 事件的频率频率越高,或者期待 / 暂停工夫越长,CPU 的闲暇工夫也就更长,利用率越低,操作系统能够调度 CPU 执行更多的线程
线程数布局的公式
后面的铺垫,都是为了帮忙了解,当初来看看书本上的定义。《Java 并发编程实战》介绍了一个线程数计算的公式:
Ncpu=CPU 外围数 Ncpu=CPU 外围数 Ncpu=CPU 外围数
Ucpu= 指标 CPU 利用率,0<=Ucpu<=1Ucpu= 指标 CPU 利用率,0<=Ucpu<=1Ucpu= 指标 CPU 利用率,0<=Ucpu<=1
WC= 等待时间和计算工夫的比例 \frac{W}{C}= 等待时间和计算工夫的比例 CW= 等待时间和计算工夫的比例
如果心愿程序跑到 CPU 的指标利用率,须要的线程数公式为:
Nthreads=Ncpu∗Ucpu∗(1+WC)Nthreads=NcpuUcpu(1+\frac{W}{C})Nthreads=Ncpu∗Ucpu∗(1+CW)
公式很清晰,当初来带入下面的例子试试看:
如果我冀望指标利用率为 90%(多核 90),那么须要的线程数为:
外围数 12 利用率 0.9 (1 + 50(sleep 工夫)/50(循环 50_000_000 耗时)) ≈ 22
当初把线程数调到 22,看看后果:
当初 CPU 利用率大略 80+,和预期比拟靠近了,因为线程数过多,还有些上下文切换的开销,再加上测试用例不够谨严,所以理论利用率低一些也失常。
把公式变个形,还能够通过线程数来计算 CPU 利用率:
Ucpu=NthreadsNcpu∗(1+WC)Ucpu=\frac{Nthreads}{Ncpu*(1+\frac{W}{C})}Ucpu=Ncpu∗(1+CW)Nthreads
线程数 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 的资源。
所以受环境烦扰下,单靠公式很难精确的布局线程数,肯定要通过测试来验证。
流程个别是这样:
- 剖析以后主机上,有没有其余过程烦扰
- 剖析以后 JVM 过程上,有没有其余运行中或可能运行的线程
- 设定指标
-
- 指标 CPU 利用率 – 我最高能容忍我的 CPU 飙到多少?
- 指标 GC 频率 / 暂停工夫 – 多线程执行后,GC 频率会增高,最大能容忍到什么频率,每次暂停工夫多少?
- 执行效率 – 比方批处理时,我单位工夫内要开多少线程能力及时处理完毕
- ……
- 梳理链路关键点,是否有卡脖子的点,因为如果线程数过多,链路上某些节点资源无限可能会导致大量的线程在期待资源(比方三方接口限流,连接池数量无限,中间件压力过大无奈撑持等)
- 一直的减少 / 缩小线程数来测试,按最高的要求去测试,最终取得一个“满足要求”的线程数 **
而且而且而且!不同场景下的线程数理念也有所不同:
- Tomcat 中的 maxThreads,在 Blocking I/ O 和 No-Blocking I/ O 下就不一样
- Dubbo 默认还是单连贯呢,也有 I / O 线程(池)和业务线程(池)的辨别,I/ O 线程个别不是瓶颈,所以不用太多,但业务线程很容易称为瓶颈
- 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
感谢您的浏览,也欢迎您发表对于这篇文章的任何倡议,关注我,技术不迷茫!小编到你上高速。
近期热文举荐:
1.1,000+ 道 Java 面试题及答案整顿 (2021 最新版)
2. 别在再满屏的 if/ else 了,试试策略模式,真香!!
3. 卧槽!Java 中的 xx ≠ null 是什么新语法?
4.Spring Boot 2.5 重磅公布,光明模式太炸了!
5.《Java 开发手册(嵩山版)》最新公布,速速下载!
感觉不错,别忘了顺手点赞 + 转发哦!