虚拟线程原理及性能分析｜得物技术

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<ServerResponse> 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<Object> callSlowServer(){    return restTemplate.getForEntity("http://127.0.0.1:8000"， Object.class);}

• 传统的线程池模式效果差强人意，可以通过提高线程数量可以提升吞吐，但是需要考虑到系统容量和资源限制，但是对于大部分场景来说使用线程池去处理阻塞操作仍然是主流且不错的选择。
• WebFlux 的效果非常好，但是考虑到需要完全按照响应式风格进行开发，成本及难度较大，同时 WebFlux 与现有的一些主流框架存在一些兼容问题，例如 Mysql 官方 IO 库不支持 NIO、Threadlocal 兼容问题等等。现有应用的迁移基本要重写所有代码，改动量和风险都不可控。
• 虚拟线程的效果非常好，最大的优势就是我们没有修改代码或采用任何反应式技术，唯一更改是将线程池替换为虚拟线程。虽然改动较小，但与使用线程池相比，性能结果得到了显著改善。

过去很长时间，在编写服务端应用时，我们对于每个请求，都使用独占的线程来处理，请求之间是相互独立的，这就是 一请求一线程的模型这种方式易于理解和编程实现，也易于调试和性能调优。

然而，一请求一线程风格并不能简单地使用平台线程来实现，因为平台线程是操作系统中线程的封装。操作系统的线程会申请成本较高，存在数量上限。对于一个要并发处理海量请求的服务器端应用来说，对每个请求都创建一个平台线程是不现实的。在这种前提下，涌现出一批非阻塞 I/O 和异步编程框架，如 WebFlux ，RX-Java。当某个请求在等待 I/O 操作时，它会暂时让出线程，并在 I/O 操作完成之后继续执行。通过这种方式，可以用少量线程同时处理大量的请求。这些框架可以提升系统的吞吐量，但是要求开发人员必须熟悉所使用的底层框架，并按照响应式的风格来编写代码，响应式框架的调试困难，学习成本，兼容问题使得大部分人望而却步 。

在使用虚拟线程之后，一切都将改变，开发人员可以使用目前最习惯舒服的方式来编写代码，高性能和高吞吐由虚拟线程自动帮你完成，这极大地降低了编写高并发服务应用的难度。

参考文档

1. https://openjdk.org/jeps/444

2. https://zhuanlan.zhihu.com/p/514719325

3. https://www.vlts.cn/post/virtual-thread-source-code#%E5%89%8D%E6%8F%90

4. https://zhuanlan.zhihu.com/p/499342616

   
   

关注得物技术，每周一、三、五更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞~
未经得物技术许可严禁转载，否则依法追究法律责任。

“

扫码添加小助手微信

如有任何疑问，或想要了解更多技术资讯，请添加小助手微信：

线下活动推荐

主题：得物技术沙龙- SRE稳定性工程探索与实践

时间：2023年11月25日（周六）14:00-18:00

地点：杭州 · 西湖区学院路77号得物杭州研发中心12F

活动亮点：本次得物技术沙龙主题为SRE稳定性工程探索与实践，将在杭州（线上同步直播）为你带来五个令人期待的演讲话题：

《得物C端核心链路稳定性保障实践》

《阿里集团系统稳定性运营管理》

《腾讯游戏SRE在复杂异构业务中的云原生服务实践》

《蚂蚁集团混沌工程技术理论与实践》

《资损防控技术体系简介及实践》

相信这些话题将对你的工作和学习有所帮助，期待与你共同探讨最前沿的技术趋势和实践经验！欢迎线下参与，如果没办法到现场，也可以锁定我们的“得物Tech”视频号哦~

快快点击下面图片报名吧~