目录

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.哪些情况会造成线程的切换

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

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

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

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

2.3.线程资源是有限的

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

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

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

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

总结起来说人话就是，用来描述进程和线程的描述符（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时，使出一手虚拟线程，毫无疑问可以大大拉高系统的吞吐量。