来源：得物技术

JDK21 在 9 月 19 号正式发布，带来了较多亮点，其中虚拟线程备受瞩目，毫不夸张的说，它改变了高吞吐代码的编写方式，只需要小小的变动就可以让目前的 IO 密集型程序的吞吐量得到提升，写出高吞吐量的代码不再困难。

在讲虚拟线程之前，我们先聊聊为了提高吞吐性能，我们所做的一些优化方案。

在当前的微服务架构下，处理一次用户/上游的请求，往往需要多次调用下游服务、数据库、文件系统等，再将所有请求的数据进行处理最终的结果返回给上游。

为了解决串行调用的低性能问题，我们会考虑使用并行异步调用的方式，最简单的方式便是使用线程池 +Future 去并行调用。

为了降低 CPU 的阻塞等待时间和提升资源的利用率，我们会使用CompletableFuture对调用流程进行编排，降低依赖之间的阻塞。

• 线程资源浪费瓶颈始终在 IO 等待上，导致 CPU 资源利用率较低。目前大部分服务是 IO 密集型服务，一次请求的处理耗时大部分都消耗在等待下游 RPC，数据库查询的 IO 等待中，此时线程仍然只能阻塞等待结果返回，导致 CPU 的利用率很低。
• 线程数量存在限制， 为了增加并发度，我们会给线程池配置更大的线程数，但是线程的数量是有限制的，Java 的线程模型是 1:1 映射平台线程的，导致 Java 线程创建的成本很高，不能无限增加。同时随着 CPU 调度线程数的增加，会导致更严重的资源争用，宝贵的 CPU 资源被损耗在上下文切换上。

在给出最终解决方案之前，我们先聊一聊 Web 应用中常见的一请求一线程的模型。

• 扩大服务最大线程数，简单有效，由于存在下列问题，导致平台线程有最大数量限制，不能大量扩充。
• 系统资源有限导致系统线程总量有限，进而导致与系统线程一一对应的平台线程有限。
• 平台线程的调度依赖于系统的线程调度程序，当平台线程创建过多，会消耗大量资源用于处理线程上下文切换。
• 每个平台线程都会开辟一块大小约 1m 私有的栈空间，大量平台线程会占据大量内存。

• 垂直扩展，升级机器配置，水平扩展，增加服务节点，也就是俗称的升配扩容大法，效果好，也是最常见的方案，缺点是会增加成本，同时有些场景下扩容并不能 100% 解决问题。
• 采用异步/响应式编程方案，例如 RPC NIO 异步调用，WebFlux，Rx-Java 等非阻塞的基于 Ractor 模型的框架，使用事件驱动使得少量线程即可实现高吞吐的请求处理，拥有较好的性能与优秀的资源利用，缺点是学习成本较高兼容性问题较大，编码风格与目前的一请求一线程的模型差异较大，理解难度大，同时对于代码的调试比较困难。

操作系统线程（OS Thread）：由操作系统管理，是操作系统调度的基本单位。

JDK 中 java.lang.Thread 的每个实例都是一个平台线程。平台线程在底层操作系统线程上运行 Java 代码，并在代码的整个生命周期内独占操作系统线程，平台线程实例本质是由系统内核的线程调度程序进行调度，并且平台线程的数量受限于操作系统线程的数量。

Thread vt = Thread.startVirtualThread(() -> {    System.out.println("hello wolrd virtual thread");});

Thread.ofVirtual().unstarted(() -> {    System.out.println("hello wolrd virtual thread");});vt.start();

ThreadFactory tf = Thread.ofVirtual().factory();Thread vt = tf.newThread(() -> {    System.out.println("Start virtual thread...");    Thread.sleep(1000);    System.out.println("End virtual thread. ");});vt.start();
方法四：Executors.newVirtualThreadPer
-TaskExecutor()









ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();executor.submit(() -> {    System.out.println("Start virtual thread...");    Thread.sleep(1000);    System.out.println("End virtual thread.");    return true;});

虚拟线程是由 Java 虚拟机调度，而不是操作系统。虚拟线程占用空间小，同时使用轻量级的任务队列来调度虚拟线程，避免了线程间基于内核的上下文切换开销，因此可以极大量地创建和使用。

• 当任务需要阻塞挂起的时候，会调用 Continuation 的 yield 操作进行阻塞，虚拟线程会从平台线程卸载。
• 当任务解除阻塞继续执行的时候，调用 Continuation.run 会从阻塞点继续执行。

• 它是 java.util.concurrent.Executor 的子类。
• 虚拟线程框架提供了一个默认的 FIFO 的 ForkJoinPool 用于执行虚拟线程任务。

• 调度器（线程池）中的平台线程等待处理任务。

• 一个虚拟线程被分配平台线程，该平台线程作为载体线程执行虚拟线程中的任务。

• 虚拟线程运行其 Continuation，Mount(挂载)平台线程后，最终执行 Runnable 包装的用户实际任务。

• 虚拟线程任务执行完成，标记 Continuation 终结，标记虚拟线程为终结状态，清空上下文，等待 GC 回收，解除挂载载体线程会返还到调度器（线程池）中等待处理下一个任务。

 ReentrantLock lock = new ReentrantLock();        Thread.startVirtualThread(() -> {            lock.lock();            });        // 确保锁已经被上面的虚拟线程持有        Thread.sleep(1000);          Thread.startVirtualThread(() -> {            System.out.println("first");            会触发Continuation的yield操作            lock.lock();             try {                System.out.println("second");            } finally {                lock.unlock();            }            System.out.println("third");        });        Thread.sleep(Long.MAX_VALUE);    }

• 虚拟线程中任务执行时候调用 Continuation#run() 先执行了部分任务代码，然后尝试获取锁，该操作是阻塞操作会导致 Continuation 的 yield 操作让出控制权，如果 yield 操作成功，会从载体线程 unmount，载体线程栈数据会移动到 Continuation 栈的数据帧中，保存在堆内存中，虚拟线程任务完成，此时虚拟线程和 Continuation 还没有终结和释放，载体线程被释放到执行器中等待新的任务；如果 Continuation 的 yield 操作失败，则会对载体线程进行 Park 调用，阻塞在载体线程上，此时虚拟线程和载体线程同时会被阻塞，本地方法，Synchronized 修饰的同步方法都会导致 yield 失败。

• 当锁持有者释放锁之后，会唤醒虚拟线程获取锁，获取锁成功后，虚拟线程会重新进行 mount，让虚拟线程任务再次执行，此时有可能是分配到另一个载体线程中执行，Continuation 栈会的数据帧会被恢复到载体线程栈中，然后再次调用Continuation#run() 恢复任务执行。

• 虚拟线程任务执行完成，标记 Continuation 终结，标记虚拟线程为终结状态，清空上下文变量，解除载体线程的挂载载体线程返还到调度器（线程池）中作为平台线程等待处理下一个任务。

ContinuationScope scope = new ContinuationScope("scope");Continuation continuation = new Continuation(scope， () -> {    System.out.println("before yield开始");    Continuation.yield(scope);    System.out.println("after yield 结束");});System.out.println("1 run");// 第一次执行Continuation.runcontinuation.run();System.out.println("2 run");// 第二次执行Continuation.runcontinuation.run();System.out.println("Done");

单个平台线程的资源占用：

• 根据 JVM 规范，预留 1 MB 线程栈空间。
• 平台线程实例，会占据 2000+ byte 数据。

• Continuation 栈会占用数百 byte 到数百 KB 内存空间，是作为堆栈块对象存储在 Java 堆中。
• 虚拟线程实例会占据 200 - 240 byte 数据。

private static final int COUNT = 4000;
/** *  -XX:NativeMemoryTracking=detail * * @param args args */public static void main(String[] args) throws Exception {    for (int i = 0; i < COUNT; i++) {        new Thread(() -> {            try {                Thread.sleep(Long.MAX_VALUE);            } catch (Exception e) {                e.printStackTrace();            }        }， String.valueOf(i)).start();    }    Thread.sleep(Long.MAX_VALUE);}

private static final int COUNT = 4000;
/** * -XX:NativeMemoryTracking=detail * * @param args args */public static void main(String[] args) throws Exception {    for (int i = 0; i < COUNT; i++) {        Thread.startVirtualThread(() -> {            try {                Thread.sleep(Long.MAX_VALUE);            } catch (Exception e) {                e.printStackTrace();            }        });    }    Thread.sleep(Long.MAX_VALUE);}

• 虚拟线程存在 native 方法或者外部方法 (Foreign Function & Memory API，jep 424 ) 调用不能进行 yield 操作，此时载体线程会被阻塞。
• 当运行在 synchronized 修饰的代码块或者方法时，不能进行 yield 操作，此时载体线程会被阻塞，推荐使用 ReentrantLock。
• ThreadLocal 相关问题，目前虚拟线程仍然是支持 ThreadLocal 的，但是由于虚拟线程的数量非常多，会导致 Threadlocal 中存的线程变量非常多，需要频繁 GC 去清理，对性能会有影响，官方建议尽量少使用 ThreadLocal，同时不要在虚拟线程的 ThreadLocal 中放大对象，目前官方是想通过 ScopedLocal 去替换掉 ThreadLocal，但是在 21 版本还没有正式发布，这个可能是大规模使用虚拟线程的一大难题。
• 无需池化虚拟线程 虚拟线程占用的资源很少，因此可以大量地创建而无须考虑池化，它不需要跟平台线程池一样，平台线程的创建成本比较昂贵，所以通常选择去池化，去做共享，但是池化操作本身会引入额外开销，对于虚拟线程池化反而是得不偿失，使用虚拟线程我们抛弃池化的思维，用时创建，用完就扔。

• 大量的 IO 阻塞等待任务，例如下游 RPC 调用，DB 查询等。
• 大批量的处理时间较短的计算任务。

• Thread-per-request (一请求一线程)风格的应用程序，例如主流的 Tomcat 线程模型或者基于类似线程模型实现的 SpringMVC 框架 ，这些应用只需要小小的改动就可以带来巨大的吞吐提升。

在下面的测试中，我们将模拟最常使用的场景-使用 Web 容器去处理 Http 请求。

• Jmeter 开启 500 个线程去并行发起请求。每个线程将等待请求响应后再发起下一次请求，单次请求超时时间为 10s，测试时间持续 60s。
• 测试的 Web Server 将接受 Jmeter 的请求，并调用慢速服务器获取响应并返回。
• 慢速服务器以随机超时响应。最大响应时间为 1000ms。平均响应时间为 500ms。

吞吐量和平均响应时间，吞吐量越高，平均响应时间越低，性能就越好。

默认情况下，Tomcat 使用一请求一线程模型处理请求，当 Tomcat 收到请求时，会从线程池中取一个线程去处理请求，该分配的线程将一直保持占用状态，直到请求结束才会释放。当线程池中没有线程时，请求会一直阻塞在队列中，直到有请求结束释放线程。默认队列长度为 Integer.MAX。

默认线程池

默认情况下，线程池最多包含 200 个线程。这基本上意味着单个时间点最多处理 200 个请求。对于每个请求服务都会以阻塞的方式调用平均 RT500ms 的慢速服务器。因此，可以预期每秒 400 个请求的吞吐量，最终压测结果非常接近预期值，为 388 req/sec。

WebFlux 跟传统的 Tomcat 线程模型不一样，他不会为每个请求分配一个专用线程，而是使用事件循环模型通过非阻塞 I/O 操作同时处理多个请求，这使得它能够用有限的线程数量处理大量的并发请求。

@Beanpublic WebClient slowServerClient() {    return WebClient.builder()            .baseUrl("http://127.0.0.1:8000")            .build();}
@Beanpublic RouterFunction routes(WebClient slowServerClient) {    return route(GET("/")， (ServerRequest req) -> ok()            .body(                    slowServerClient                            .get()                            .exchangeToFlux(resp -> resp.bodyToFlux(Object.class))，                    Object.class            ));}

与平台线程相比，虚拟线程的内存占用量要低得多，运行程序大量的创建虚拟线程，而不会耗尽系统资源；同时当遇到 Thread.sleep()，CompletableFuture.await()，等待 I/O，获取锁时，虚拟线程会自动卸载，JVM 可以自动切换到另外的等待就绪的虚拟线程，提升单个平台线程的利用率，保证平台线程不会浪费在无意义的阻塞等待上。

@Beanpublic TomcatProtocolHandlerCustomizer protocolHandler() {    return protocolHandler ->            protocolHandler.setExecutor(Executors.newVirtualThreadPerTaskExecutor());}

private final RestTemplate restTemplate;
@GetMappingpublic ResponseEntity