目录

1.概述

2.虚拟线程是为了解决哪些问题

2.1.线程切换的巨大代价

2.2.哪些情况会造成线程的切换

2.3.线程资源是有限的

3.虚拟线程

4.适用场景


1.概述

你发任你发,我用JAVA8?JDK21可能要对这句话say no了。

现在Oracle JDK是每4个版本,推出一个长期支持版本,JDK21就是前段时间发布的最新的长期支持版JDK。作为最新的长期支持版JDK,JDK21中集合了非常多的重要新特性,其中最为重要,最有意义,最吸引人的莫过于——虚拟线程。虚拟线程虽然不是JDK21才引入的,但是是在该版本中才得以稳定的,所以我们建议要用虚拟线程的话,最好还是使用JDK21。

本文将用一个清晰的思路抽丝剥茧,层层递进的去探讨:

1.虚拟线程是为了解决哪些问题

在虚拟线程出现之前,传统线程模型中线程切换存在的问题,即线程切换的代价。

然后去思考哪些情况下线程会切换?有哪些可以优化的地方?

2.虚拟线程是怎么解决这些问题的

然后是虚拟线程是怎样工作的?是怎样进行任务调度的?

3.虚拟线程的实际应用价值

虚拟线程的适用场景。

2.虚拟线程是为了解决哪些问题

2.1.线程切换的巨大代价

虚拟线程是为了解决哪些问题?自然是为了解决之前传统线程模型存在的一些问题。如果对计算机的线程模型不是很熟悉的同学博主之前有一篇文章,有兴趣可以看一下:

【进程与线程】最好懂的讲解-CSDN博客

所以传统的线程模型存在哪些问题喃?这就要从线程切换的巨大代价聊起。

先给出结论——线程的切换可能会引起CPU上下文的切换,从而造成巨大的CPU资源的浪费。接下来我们聊聊具体原因。

CPU的读写速率是要远远高于内存的读写速率的,为了配平CPU和内存之间速率的差距,CPU和内存之间存在着一个由寄存器组成的中间层,寄存器种会存放着CPU接下来要执行的指令,以及后续可能要执行到的指令以及可能要用到的数据。只有预先装载进去这部分可能要用到的东西才能抹平CPU和内存之间的速率差距,不然每次都要去内存取内容,可能是会拉低CPU的效率的。

但该预先装载哪些内容进寄存器种喃?这里遵循了程序的局部性原理。

程序的局部性原理:

程序在执行的时候呈现出局部性规律,在一段时间内,整个程序的执行仅限于程序中的某一个部分,相应的,执行所访问的存储空间也局限于某个内存区域。局部性又分为时间局部性和空间局部性。时间局部性指的是,如果程序中的某条指令一旦执行,则不久后可能会被再次执行,执行指令时访问的数据单元在不久后会被再次访问。空间局部性指的是,一旦访问了某个存储单元,不久后,其附近的存储单元也将被访问。

CPU上下文切换:

寄存器中存储着当前执行的指令、数据、以及下一条指令在内存中的地址等等事关程序正常运行的关键信息。所以寄存器中存储的内容合称为CPU的上下文。

线程切换就可能会存在这样的问题:CPU上下文中存放的是当前线程的要的东西,可能不是下个线程要用的东西。下个线程被执行的时候,可能CPU的上下文就要换一套。CPU上下文的内容本来就是来自于内存,也就是说切换上下文就是去内存中读取要的东西。CPU的读写速度是远远高于内存的读写速度的,在这个切换过程中CPU没啥事儿可干了,就会造成CPU的浪费。

2.2.哪些情况会造成线程的切换

前面我们已经说了线程切换的巨大代价,接下来我们就要想想,什么情况下线程会切换喃?常见的无非两种情况:

  1. 分给当前线程的时间片到了
  2. 线程阻塞了

我们分情况来讨论,首先是分给当前线程的时间片到了造成的线程切换。这类线程切换有问题吗?能被优化吗?很显然没问题,也不能去动它,因为进程和线程的出现本质上就是为了让多个程序能被交替执行,提升CPU的利用率,所以当前线程时间片到了,它就应该把CPU交出来,其它线程才有机会被执行。

至于第二种,线程阻塞引起的线程切换,就是值得我们进行优化的了。线程阻塞了,只是当前任务阻塞了,线程只是任务的载体,完全可以换个任务在上面继续执行。同理还有一种情况,就是时间片还没有用完,线程上面的任务跑完了,其实也该这样处理。

2.3.线程资源是有限的

除了上面线程切换的问题外,还有一点是值得注意的,就是线程资源是有限的,一台计算机上能开出来的线程是有上限的。

操作系统能够同时开启的线程数量是有限的主要有以下几个原因:

  1. 有限的系统资源:每个线程需要占用一定的系统资源,包括内存、CPU时间片、文件描述符等。系统的资源是有限的,因此开启过多的线程会消耗大量资源,可能导致资源耗尽或者性能下降。

  2. 调度开销:操作系统需要花费时间来管理和调度线程,包括线程的创建、销毁、切换等操作。如果线程数量过多,操作系统的调度开销会增加,降低系统的效率。

总结起来说人话就是,用来描述进程和线程的描述符(PCB或者TCP等)要存在内存中、内存是有限的,所以理论上线程自然是有上限的。

3.虚拟线程

前面罗嗦了这么多,总结起来无非就是计算机的线程资源是有限的,线程的切换会造成CPU资源的浪费。所以如果能复用线程资源,会提升多任务执行的效率。虚拟线程其实就是对线程资源的一种复用。

传统的JDK线程是每一条对应一条操作系统的线程,而虚拟线程是多个虚拟线程对应一条JDK的线程:

虚拟线程体系其实就是依赖于fork join pool来实现的,线程池中的每个JDK线程会对应一个任务列表,列表中会有多个虚拟线程,其实就是多个任务,由fork join pool的调度器来调度虚拟线程(任务)到各条平台线程上去。当有虚拟线程(任务)阻塞或者在时间片内提前执行完了等情况发生,调度器会去调度任务队列中的虚拟线程(任务)到这条平台线程上去继续执行:

ok,终于到虚拟线程的使用了,其实虚拟线程的使用本身反而还没有啥很多要说的。API的设计使用,当然是具有越极致的开闭性越好,所以作为线程的一个补充,虚拟线程的使用,在API层面是很简单的,和传统JDK线程的API语法几乎是一样的。

前置条件就不多说了,肯定是下载安装配置好JDK21,都在看JDK新特性的同学,这个肯定都是小问题,不赘述了。

手动开启虚拟线程:

Thread thread=Thread.ofVirtual().name("vittualThread").unstarted(new Task());
thread.start();

自动开启虚拟线程:

Thread thread=Thread.ofVirtual().name("virtualThread").start(new Task());

线程池:

ExecutorService executorService = Executors.newVirtualThreadPerTaskExecutor();
executorService.submit(new Task( ));
executorService.submit(new Task( ));
executorService.submit(new Task( ));

4.适用场景

虚拟线程采用协作式调度,线程主动放弃 CPU 控制权,而不是由操作系统强制切换。这种调度模型对于 IO 密集型任务非常适用,因为在等待 IO 操作完成的时候,线程可以主动让出 CPU 控制权,允许其他任务继续执行,提高了系统的吞吐量。

然而,在 CPU 密集型计算任务中,线程需要持续占用 CPU 资源进行计算,不适合频繁地放弃 CPU 控制权。虚拟线程的协作式调度可能导致任务在进行计算时频繁地让出 CPU,从而降低了计算密集型任务的执行效率。

虚拟线程对于IO密集型任务的友好,从tomcat11主动去拥抱JDK11,可见一斑:

tomcat作为一个web server,面对网络IO时,使出一手虚拟线程,毫无疑问可以大大拉高系统的吞吐量。

Logo

开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!

更多推荐