线程池不再乱配线程数了

021efa2360c963006c0e1271adc987ec.jpeg来源:juejin.cn/post/7390689983789924367

👉 欢迎加入小哈的星球,你将获得: 专属的项目实战 / 1v1 提问 / Java 学习路线 / 学习打卡 / 每月赠书 / 社群讨论

  • 新项目:《从零手撸:仿小红书(微服务架构)》 正在持续爆肝中,基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17..., 点击查看项目介绍

  • 《从零手撸:前后端分离博客项目(全栈开发)》 2期已完结,演示链接:http://116.62.199.48/;

截止目前,累计输出 54w+ 字,讲解图 2330+ 张,还在持续爆肝中.. 后续还会上新更多项目,目标是将 Java 领域典型的项目都整一波,如秒杀系统, 在线商城, IM 即时通讯,Spring Cloud Alibaba 等等,戳我加入学习,解锁全部项目,已有2000+小伙伴加入

a7031b4634317ba57f4f9a05292613ca.gif

线程到底设置数量多少合适

网上有很多文章说设置线程数的理论(个人不信):

  • CPU密集型的程序 - 核心数 + 1

  • I/O密集型的程序 - 核心数 * 2

CPU利用率

在分析线程数之前,先说一个基本的理论:

一个CPU核心,单位时间内只能执行一个线程的指令

那么理论上,我一个线程只需要不停的执行指令,就可以跑满一个核心的利用率。

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

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

运行这个例子后,来看看现在CPU的利用率:

32426f2caea011193570ac407991f1a2.jpeg
图片

从图上可以看到,我的3号核心利用率已经被跑满了

那基于上面的理论,我多开几个线程试试呢?

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

此时再看CPU利用率,1/2/5/7/9/11 几个核心的利用率已经被跑满:

bd7c2f6835c8020deb1b6fd87d94889c.jpeg
图片

那如果开12个线程呢,是不是会把所有核心的利用率都跑满?答案一定是会的:

4de77ad8c0f5303f60f043135eba4cfd.jpeg
图片

如果此时我把上面例子的线程数继续增加到24个线程,会出现什么结果呢?

CPU利用率和上一步一样,还是所有核心100%,不过此时负载从11.x增加到了22.x,说明此时CPU更繁忙,线程的任务无法及时执行。

现代CPU基本都是多核心的,我们可以简单的认为是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(newRunnable(){
             @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();
     }
}}
b6b4d26bdf22f9d41decd0c399195c92.jpeg
图片

唯一有利用率的9号核心,利用率也才50%,和前面没有sleep的100%相比,已经低了一半了。现在把线程数调整到12个看看:

21783baeacfdec3c8db467b1c2c854f7.jpeg
图片

单个核心的利用率60左右,和刚才的单线程结果差距不大,还没有把CPU利用率跑满,现在将线程数增加到18:

e87518a0a2b93a0b1d0541ad27e158ac.jpeg
图片

此时单核心利用率,已经接近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 并发编程实战》中介绍了一个线程数计算的公式

18909dca042333eb705953c701353f9b.jpeg
图片

如果希望程序跑到CPU的目标利用率,需要的线程数公式为:

f563e82fa326ef4dd7819d500b260b17.jpeg
图片

公式很清晰,现在来带入上面的例子试试看:

如果我期望目标利用率为90%(多核90),那么需要的线程数为:

核心数12 * 利用率0.9 * (1 + 50(sleep时间)/50(循环50_000_000耗时)) ≈ 22

分析一下,W是等待时间比如IO等待的时间,C是计算时间即我完成那么多次循环一共耗时是多少

现在把线程数调到22,看看结果:

95fcb14f59e4eb14e056c3955a31857f.jpeg
图片

现在CPU利用率大概80+,和预期比较接近了,由于线程数过多,还有些上下文切换的开销,再加上测试用例不够严谨,所以实际利用率低一些也正常。

真实程序中的线程数是怎样的

那么在实际的程序中,或者说一些Java的业务系统中,线程数(线程池大小)规划多少合适呢?

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

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

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

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

流程一般是这样:

  • 分析当前主机上,有没有其他进程干扰

  • 分析当前JVM进程上,有没有其他运行中或可能运行的线程

  • 设定目标

  • 目标CPU利用率 - 我最高能容忍我的CPU飙到多少?

  • 目标GC频率/暂停时间 - 多线程执行后,GC频率会增高,最大能容忍到什么频率,每次暂停时间多少?

  • 执行效率 - 比如批处理时,我单位时间内要开多少线程才能及时处理完毕

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

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

很正常,不需要啥性能,稳定好用符合需求就可以了。那么我的推荐的线程数是:CPU核心数

👉 欢迎加入小哈的星球,你将获得: 专属的项目实战 / 1v1 提问 / Java 学习路线 / 学习打卡 / 每月赠书 / 社群讨论

  • 新项目:《从零手撸:仿小红书(微服务架构)》 正在持续爆肝中,基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17..., 点击查看项目介绍

  • 《从零手撸:前后端分离博客项目(全栈开发)》 2期已完结,演示链接:http://116.62.199.48/;

截止目前,累计输出 54w+ 字,讲解图 2330+ 张,还在持续爆肝中.. 后续还会上新更多项目,目标是将 Java 领域典型的项目都整一波,如秒杀系统, 在线商城, IM 即时通讯,Spring Cloud Alibaba 等等,戳我加入学习,解锁全部项目,已有2000+小伙伴加入

8771b75afdf071bdbb07d0c8e884c880.gif

ffae5bbacb9af13f51169b391b022993.jpeg

 
 

c8f1a907cc6c3c368d32aca5d24957eb.gif

 
 
 
 
1. 我的私密学习小圈子~
2. SpringBoot 物理线程、虚拟线程、Webflux 性能全面对比!
3. Redis 鸟枪换炮了
4. Java 线程池详解,图文并茂,还有谁不会?!
 
 
最近面试BAT,整理一份面试资料《Java面试BATJ通关手册》,覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。
获取方式:点“在看”,关注公众号并回复 Java 领取,更多内容陆续奉上。
PS:因公众号平台更改了推送规则,如果不想错过内容,记得读完点一下“在看”,加个“星标”,这样每次新文章推送才会第一时间出现在你的订阅列表里。
点“在看”支持小哈呀,谢谢啦
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值