Java 与后端 on Renxin's Blog

理解虚拟线程：从一次阻塞说起

Thu, 13 Aug 2026 00:00:00 +0000

你有没有遇到过这种情况——

一个典型的 Java Web 服务，Tomcat 默认线程池 200。请求处理逻辑很简单：查一下数据库，调一个远程接口，返回结果。每个请求从进入线程池到返回，大部分时间都在等数据库查询、等远程响应。

并发一上来，问题就出现了：200 个线程很快全部阻塞在 IO 等待上，新请求全部排队。

这时候你多半会想：线程池不够，加线程不就行了？

试了才知道这条路走不通。加到 1000，确实多撑了一会儿——但 1000 个线程照样会阻塞在 IO 上，第 1001 个请求照样排队。想靠加线程支撑真正的并发量？几万并发需要几万线程，每个线程 1MB 栈，就是几十 GB 内存；就算内存扛得住，操作系统调度几万个线程的开销也会把 CPU 吃光。

于是你看到一种奇怪的状况：CPU 大多是空闲的——因为线程都在等 IO，没有计算在跑；内存也没满——因为当前只有 200 个线程在跑，只占了 200MB 栈。但并发就是上不去，而且加线程这条路本身是死路。

这不是硬件问题，是线程模型问题：线程是稀缺的「重」资源，一个线程被 IO 阻塞时，它什么都没干，却把一个宝贵的线程占住了。而 JDK 21 的虚拟线程，就是来改这个的。

这篇文章用一条问题链讲透虚拟线程：平台线程为什么不够用 → 虚拟线程怎么解决 → 它适合什么、不适合什么。

%%{init: {'theme':'base'}}%%
graph LR
 A["核心结论：
虚拟线程让 Java 支持百万级并发"] --> B["平台线程
为什么不够用"]
 A --> C["虚拟线程
怎么解决"]
 A --> D["边界
适合什么"]
 style A fill:#d1fae5,stroke:#059669,color:#064e3b
 style B fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style C fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style D fill:#dbeafe,stroke:#2563eb,color:#1e3a5f

平台线程的四个瓶颈

Java 的传统线程（平台线程）和操作系统线程是一一对应的：Java 代码每创建一个线程，JVM 就调用操作系统 API 创建一个 OS 线程。

%%{init: {'theme':'base'}}%%
graph LR
 A["Java 线程"] --> B["OS 线程"]
 B --> C["内核调度
1:1 映射"]
 style A fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style B fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style C fill:#fef9c3,stroke:#ca8a04,color:#713f12

这种 1:1 模型在 Java 诞生时没问题，但放到现代高并发场景，四个瓶颈逐个暴露。

瓶颈	表现	根源
创建销毁贵	线程创建销毁涉及内核态切换	要操作系统参与
内存占用大	每个线程默认分配 1MB 栈空间	JVM 为每个平台线程预留栈
上下文切换贵	保存恢复大量寄存器、栈状态，CPU 缓存失效	内核调度，涉及用户态/内核态切换
可用数量有限	一个进程通常只能创建数千个线程	内存和调度成本双重限制

一句话总结：平台线程是「重」资源，不能随便创建。所以 Java 应用被迫用线程池复用线程——但线程池也有上限，并发一高就排队。

这就是为什么现代语言纷纷引入轻量线程：Go 的 goroutine、Kotlin 的协程。Java 直到 JDK 21 才正式端出虚拟线程（JEP 444，2023 年 9 月 19 日发布）。

虚拟线程：用户态轻量级线程

虚拟线程和平台线程最大的区别：它不由操作系统管理，由 JVM 管理。

维度	平台线程	虚拟线程
创建销毁	内核态，贵	用户态，JVM 完成，便宜
内存占用	默认 1MB 栈	几 KB 级
上下文切换	内核调度，保存大量状态	用户态，保存少量状态
可用数量	数千级	数百万级

数字对比很直观：平台线程 1MB 栈，虚拟线程只要几 KB——内存开销差两个数量级。这也是为什么虚拟线程能支撑「thousands or millions」级别的并发，而平台线程到几千就顶不住了。

但虚拟线程的核心价值不只是「轻」，而是它的调度机制——这才是它和 goroutine 一样优雅的地方。

虚拟线程如何工作：阻塞就挂起

理解虚拟线程，先理解一个词：carrier（载体线程）。

JVM 底层有一组平台线程专门用来运行虚拟线程（数量默认等于可用 CPU 核数），虚拟线程被调度器分配到这组 carrier 上执行。调度器是 JDK 内置的 work-stealing ForkJoinPool，FIFO 模式。

%%{init: {'theme':'base'}}%%
graph LR
 A["虚拟线程 1"] --> C["carrier 平台线程
（调度器分配）"]
 B["虚拟线程 2"] --> C
 D["虚拟线程 3"] --> C
 style A fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style B fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style D fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style C fill:#fef9c3,stroke:#ca8a04,color:#713f12

关键机制在阻塞发生时。看这个流程：

%%{init: {'theme':'base'}}%%
graph LR
 A["虚拟线程执行
调用阻塞 I/O"] --> B["JVM 识别阻塞调用
自动执行非阻塞 OS 调用"]
 B --> C["虚拟线程挂起
释放 carrier"]
 C --> D["carrier 去运行
其他虚拟线程"]
 D --> E["I/O 完成
调度器恢复虚拟线程"]
 E --> A
 style A fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style B fill:#d1fae5,stroke:#059669,color:#064e3b
 style C fill:#fef9c3,stroke:#ca8a04,color:#713f12
 style D fill:#d1fae5,stroke:#059669,color:#064e3b
 style E fill:#d1fae5,stroke:#059669,color:#064e3b

当虚拟线程调用阻塞 I/O 时，JVM 运行时自动把阻塞调用替换成非阻塞 OS 调用，然后挂起虚拟线程、释放 carrier。carrier 立刻去运行别的虚拟线程，不空等。

对比平台线程：一个平台线程阻塞在数据库查询或远程调用上，它只能空等，线程池里这个位置就被白白占用。200 个请求并发，200 个线程全在等 IO，第 201 个请求只能排队——这就是开篇那个场景。

JEP 444 把这层意思说得很直白：线程数往往在 CPU 或网络连接等资源耗尽之前，就先成为限制因素（“the number of threads often becomes the limiting factor long before other resources, such as CPU or network connections, are exhausted”）。阻塞的线程不消耗 CPU，但占着线程名额——所以你会看到资源有余、并发却上不去的怪象。

虚拟线程的思路是：我阻塞，但不占着茅坑。挂起时不消耗 carrier 资源，恢复后继续执行。这就是「thread-per-request」风格能跑通百万并发的根本原因——每个请求一个虚拟线程，阻塞时自动让位。

调度开销：虚拟线程省下的第二个大头

上面讲的是「阻塞时不占线程」，虚拟线程还省下另一笔大账——调度开销。

平台线程的调度由操作系统完成：切换线程时，内核要保存/恢复寄存器和栈状态，还可能导致 CPU 缓存失效，这是一笔昂贵的开销。线程越多，OS 花在调度上的时间比例越高，真正干活的 CPU 时间反而变少——这是平台线程并发数上不去的第二个原因，和内存占用并列。

虚拟线程的调度完全不同：它由 JVM 的 ForkJoinPool 调度到 carrier 上运行，挂起和恢复都在用户态完成，只保存/恢复少量状态，不触发 OS 级上下文切换。JEP 444 原话是虚拟线程「cheap to create and almost infinitely plentiful」（创建便宜，数量近乎无限）。

所以虚拟线程提高并发是双管齐下：

成本维度	平台线程	虚拟线程
内存成本	1MB 栈/线程，几万线程就几十 GB	几 KB/线程，支持百万级
调度成本	OS 上下文切换，保存大量状态，缓存失效	JVM 用户态挂起/恢复，保存少量状态

内存和调度两个大头都降下来，并发数才能从「数千」跳到「数百万」。这也是为什么说虚拟线程是低成本提高并发的手段——不是堆硬件，而是把每个并发单元的代价做小。

虚拟线程的边界：不是万能药

虚拟线程很强大，但有两个边界必须知道。

边界一：CPU 密集型任务没优势

虚拟线程解决的瓶颈是「大量任务等待 I/O」。对 CPU 密集型任务——任务本身在计算，不阻塞——虚拟线程没有帮助。

场景	虚拟线程效果	原因
IO 密集型（请求等待数据库/网络/文件）	✅ 巨大提升	阻塞期释放 carrier，并发数提升几个数量级
CPU 密集型（计算、加密、图像处理）	❌ 无优势	瓶颈是 CPU 核心数，不是线程数

CPU 密集场景的正确做法还是：合理分配任务到 CPU 核心，控制线程数。

边界二：pinning——虚拟线程被「钉住」

正常情况下，虚拟线程阻塞时释放 carrier。但如果虚拟线程执行到 synchronized 块或 native 方法 时发生阻塞，它会被「钉」在 carrier 上——因为 JVM 无法在这些场景下安全地挂起和切换。

%%{init: {'theme':'base'}}%%
graph LR
 A["虚拟线程执行
synchronized 块"] --> B["发生阻塞"]
 B --> C["被钉在 carrier 上
carrier 无法释放"]
 C --> D["carrier 被占用
其他虚拟线程排队"]
 style A fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
 style B fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
 style C fill:#fef9c3,stroke:#ca8a04,color:#713f12
 style D fill:#fee2e2,stroke:#dc2626,color:#7f1d1d

这不会导致应用错误（JEP 444 明确说 pinning 不使应用 incorrect），但会阻碍扩展性——被钉住的 carrier 不能服务其他虚拟线程。

高频遇到 pinning 的场景：基于 JDBC 的数据库驱动（MySQL Connector/J、PostgreSQL JDBC 等）和 synchronized 方法。这也是为什么「虚拟线程 + 传统 JDBC 连接池」不是好组合——数据库连接是稀缺物理资源，连接池大小远小于虚拟线程并发数，大量虚拟线程会阻塞在等连接上，而 synchronized 又可能引发 pinning。

回到开头

回顾整条问题链：

平台线程 1:1 映射 OS → 重资源 → 并发受限于线程数
 → 虚拟线程：用户态轻量级线程 → 阻塞就挂起，不占 carrier
 → IO 密集型受益巨大（百万级并发）
 → CPU 密集型无优势
 → synchronized/native 场景可能 pinning

下次遇到 Java 服务并发上不去，先想清楚两件事：

任务是 IO 密集还是 CPU 密集？ IO 密集才考虑虚拟线程，CPU 密集先优化计算本身
代码里有没有 synchronized / JDBC 阻塞？ 有的话，先解决 pinning 场景再上虚拟线程

虚拟线程不是银弹，但它确实把 Java 带进了「百万级并发」的赛道——前提是用对场景。

本文基于 JEP 444（openjdk.org/jeps/444）官方规范与 Java 版本历史（Wikipedia）的梳理，平台线程默认栈 1MB、虚拟线程数千万级等数据均来自该来源。

JDK21新特性

Mon, 21 Apr 2025 00:00:00 +0000

笔者在过去主要使用的JDK版本是JDK8，最近在学习最新的JDK长期支持版本——JDK21，本文将简要记录一下JDK21相比于JDK8的一些新特性，对于一些比较有意思的新特性也会在后续文章中逐步展开研究。

var 关键字局部变量推断

// 仅限局部变量
var name = "zhangsan";
var age = 18;
var isMan = true;
var list = new ArrayList<String>();
var map = new HashMap<String, String>();

switch 表达式增强


// 假设有枚举定义为
public enum Direction {

 EAST,
 SOUTH,
 WEST,
 NORTH,
 NORTHWEST,
 ;
}

// switch 表达式为变量赋值
var witchCity = switch (direction) {
 case EAST, NORTHWEST -> "成都";
 case WEST -> "上海";
 case SOUTH -> "广州";
 case NORTH -> "北京";
 default -> throw new IllegalArgumentException("Invalid direction: " + direction);
};
// yield 关键字返回值，并跳出switch表达式（相当于break）
var witchCity = switch (direction) {
 case EAST, NORTHWEST:
 System.out.println("成都");
 yield "成都";
 case WEST:
 System.out.println("上海");
 yield "上海";
 case SOUTH:
 System.out.println("广州");
 yield "广州";
 case NORTH:
 System.out.println("北京");
 yield "北京";
 default:
 system.out.println("未知");
 yield "未知";
};
// yield 关键字结合lambda表达式
var witchCity = switch (direction) {
 case EAST, NORTHWEST -> {
 System.out.println("成都");
 yield "成都";
 }
 case WEST -> {
 System.out.println("上海");
 yield "上海";
 }
 case SOUTH -> {
 System.out.println("广州");
 yield "广州";
 }
 case NORTH -> {
 System.out.println("北京");
 yield "北京";
 }
 default -> {
 System.out.println("未知");
 yield "未知";
 }
};

记录类（record class）

记录类的使用场景是存储数据，尤其是那些纯粹做数据传输的对象如DTO等，其每个字段都是不可变的。

// 定义一个记录类,标注了record关键字，同时指定了name和age两个字段，编译器已经自动为其生成了构造函数、字段访问方法name()和age()。
// 除字段不能被修改、不能继承其他类、不能添加实例字段之外其他的特性与普通类相同。
public record Student(String name, int age) {
 // 不能添加实例字段
 // private String teacher;

 // 构造器可以自定义
 public Student {
 if (age < 0) {
 throw new IllegalArgumentException("年龄不能小于0");
 }
 if (name == null || name.isEmpty()) {
 throw new IllegalArgumentException("姓名不能为空");
 }
 }
 // 可以定义方法

 // 可以实现接口
}

密封类（Sealed Classes）

密封类的使用场景是定义一个类的继承规则，只有指定的类可以继承该类，其他类不能继承该类。类之间耦合更紧了，但是也提升了类型安全。在编写三方库提供给别人用又不希望被使用者随意继承使用时这个特性会特别有用。

// sealed关键字定义一个密封类，同时permits关键字指定了可以继承该类的类
public sealed class Job permits Author, Teacher {

 public String name() {
 return "renxin";
 }
}

// 定义一个final类为密封类的子类，该类不能被继承
public final class Author extends Job {
 public String name() {
 return "renxin";
 }
}

// 定义一个non-sealed修饰的类为密封类的子类，该类放弃密封性可以被普通类继承
public non-sealed class Author extends Job {
}

子类必须与密封类处于同一个模块（或同一个包，如果没有模块系统）

子类必须显式继承密封类，否则编译不通过

密封类的子类必须被显式声明为final、sealed或non-sealed。这是密封类设计的核心原则。这样做有两方面的好处。

明确类的继承结构，防止继承链失控
与模式匹配结合可以在编译期做到穷举检查

 // Author类、Teacher被明确定义为final类，编译期可以知道该类被哪些子类继承，做到穷举检查
 public abstract sealed class Job permits Author, Teacher {}
 public final class Author extends Job {}
 public final class Teacher extends Job {}
 
 void handle(Job job) {
 switch (job) {
 case Author a -> System.out.println("Author");
 case Teacher t -> System.out.println("Teacher");
 }
// 编译通过，若缺失case Teacher分支，编译错误

虚拟线程（Virtual Threads）

虚拟线程是一种用户态的轻量级线程，类似于其他语言的协程，它的显著提高了Java程序的并发支持能力。细节请参考笔者另一篇文章：理解虚拟线程

新的HTTP客户端API

支持同步调用和异步调用，异步调用使用CompletableFuture来返回结果。

 // 同步调用
HttpClient client = HttpClient.newHttpClient();
HttpRequest request = HttpRequest.newBuilder()
 .uri(URI.create("https://httpbin.org/get"))
 .GET()
 .build();
HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());

// 异步调用
CompletableFuture<String> stringBodyCompletableFuture = client.sendAsync(request, HttpResponse.BodyHandlers.ofString())
 .thenApply(HttpResponse::body);

instance of 模式匹配

instance of 语法增强，可以省去类型转换步骤。


// jdk8写法
String obj = "read.renxinblog.cn";
 if(obj instanceof String){
String s = (String) obj;
 System.out.

println(s.length());
 }

// jdk21写法
var obj = "read.renxinblog.cn";
 if(obj instanceof
String s){
 System.out.

println(s.length());
 }

新一代GC：ZGC

相较于上一代的G1，ZGC的性能更加优秀，同时也更加稳定。

几乎所有GC阶段都并发进行，STW时间极短，这意味着GC暂停对应用程序造成的性能波动非常小。
能够支持更大的堆，最多达16TB，并且随着堆的增大，GC性能几乎没有降低，这对于数据密集型的大堆系统非常有用。
ZGC能够保证GC停顿时间可控，更容易实现系统的SLO要求。
更高的并发能力同时也意味着更高的CPU消耗。

总之，ZGC以复杂的技术实现换来了极低的延迟时间和大堆性能表现，是G1控制延迟的进化版。性能的提升也带来更高的CPU消耗，但这不是一个缺点，而是一个非常的选择。

其他

其他特性还包括Stream API的增强、集合工厂方法、文本块（字符串增强）、日期API增强等，这里不多做介绍。