JDK21虚拟线程

虚拟线程是JDK21最重要的、可能会成为JDK8的lambda这样标志性的特性。这里对虚拟线程做原理级别的系统性分析。

虚拟线程的设计动机

对于后台服务器开发，一个请求对应一条处理线程，是最容易理解的服务器应用编程思路。但是，线程的数量会受到物理资源限制：比如默认Java线程会占用1MB内存，就会受到物理内存大小的限制；比如线程切换涉及内核态-用户态转换，需要频繁保存上下文，浪费CPU时间进行数据复制，受到CPU和带宽的限制。在海量请求到达时，线程资源会很快耗尽，成为主要的性能瓶颈。

早期的一个通常解法是：提高线程的利用率。一方面利用池化技术，减少线程创建销毁的开销，多余任务排队执行减少线程的数量；另一方面利用异步编程API（比如Future），在等待I/O时让出资源。但这样的后果是，一个请求的处理逻辑会被切分成很多段，执行-阻塞-回调-执行-阻塞-回调……这些段可能运行在不同的线程上，导致代码理解困难、调试困难。即使利用JDK8的CompletableFuture对并发编程逻辑做了编排，也只是治标而已。

而解决“线程数量限制”、“线程切换开销大”等问题的一个常用方案，就是构建用户态运行的“协程”。因此，Project Loom项目发起和推进Java的并发编程模型优化，其愿景为“write sync run async”，即“写同步代码，跑异步逻辑”。Loom提出了“纤程（Fiber）“的概念，并认为“纤程”由“续体（Continuation）”和“调度器（Scheduler）”两部分组成。而“纤程”在提供给用户的操作入口，称为“虚拟线程（Virtual Thread）”。“虚拟线程”资源几乎是无限的，每个请求都可以使用一个“虚拟线程”来执行业务逻辑。