目录
1 CPU密集型
2 IO密集型
3 总结
4 真实程序中的线程数
Java 获取CPU核心数
Linux 获取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状态的关系,来简单总结一下:
那么在实际的程序中,或者说一些Java的业务系统中,线程数(线程池大小)规划多少合适呢?
先说结论:没有固定答案,先设定预期,比如我期望的CPU利用率在多少,负载在多少,GC频率多少之类的指标后,再通过测试不断的调整到一个合理的线程数
比如一个普通的,SpringBoot 为基础的业务系统,默认Tomcat容器+HikariCP连接池+G1回收器,如果此时项目中也需要一个业务场景的多线程(或者线程池)来异步/并行执行业务流程。
此时我按照上面的公式来规划线程数的话,误差一定会很大。因为此时这台主机上,已经有很多运行中的线程了,Tomcat有自己的线程池,HikariCP也有自己的后台线程,JVM也有一些编译的线程,连G1都有自己的后台线程。这些线程也是运行在当前进程、当前主机上的,也会占用CPU的资源。
所以受环境干扰下,单靠公式很难准确的规划线程数,一定要通过测试来验证。
流程一般是这样:
分析当前主机上,有没有其他进程干扰
分析当前JVM进程上,有没有其他运行中或可能运行的线程
设定目标
梳理链路关键点,是否有卡脖子的点,因为如果线程数过多,链路上某些节点资源有限可能会导致大量的线程在等待资源(比如三方接口限流,连接池数量有限,中间件压力过大无法支撑等)
不断的增加/减少线程数来测试,按最高的要求去测试,最终获得一个“满足要求”的线程数**
而且而且而且!不同场景下的线程数理念也有所不同:
所以,不要纠结设置多少线程了。没有标准答案,一定要结合场景,带着目标,通过测试去找到一个最合适的线程数。
可能还有同学可能会有疑问:“我们系统也没啥压力,不需要那么合适的线程数,只是一个简单的异步场景,不影响系统其他功能就可以”
很正常,很多的内部业务系统,并不需要啥性能,稳定好用符合需求就可以了。那么我的推荐的线程数是:CPU核心数
Runtime.getRuntime().availableProcessors()//获取逻辑核心数,如6核心12线程,那么返回的是12
# 总核数 = 物理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
文章转载自:别再纠结线程池池大小、线程数量了,哪有什么固定公式 | 京东云技术团队 - 掘金