章节导读

本章定位：JDK 18-21 这五个版本将 Java 带入了一个全新的时代——虚拟线程让百万级并发成为常态，模式匹配从 instanceof 扩展到 switch 和 record 解构，序列集合填补了集合框架二十年的历史空白。本章以"飞翔科技高并发架构升级"为实战主线，剖析这些将深刻影响未来十年 Java 生态的里程碑特性。

为什么需要学习 JDK 18-21？

2023 年 9 月，JDK 21 LTS 发布。这是继 JDK 17 之后最新的长期支持版本，也是目前 Spring Boot 3.2+ 的推荐基线。如果教程停留在 JDK 17，学员将错过以下改变游戏规则的能力：

• 百万级并发不再是神话：虚拟线程（Virtual Threads）让创建 100 万个线程的内存占用从 2GB 降到 20MB
• 类型判断进入模式时代：Switch 模式匹配正式转正，一个 switch 块同时完成类型判断、变量绑定和值提取
• 数据解构像呼吸一样自然：Record 模式匹配让 record Point(int x, int y) 可以在 instanceof 和 switch 中直接解构为 x 和 y
• 集合框架终于对称了：序列集合（Sequenced Collections）给 List/Deque/SortedSet 统一增加了 first()、last()、reversed()
• 代码可以更少噪声：未命名模式与变量用 _ 占位，让"只关心部分字段"的模式匹配更简洁

白歌（飞翔科技架构师）："JDK 21 不是一次普通的版本升级。虚拟线程重构的是我们对并发的认知——以前'一个请求一个线程'是奢侈品，现在它是默认配置。模式匹配重构的是我们对类型处理的认知——以前类型判断是一堆 if-else 和强制转换，现在是一行模式表达式。这两个特性组合在一起，Spring Boot 应用的并发处理能力可以提升一个数量级。"

本章知识图谱

五大核心特性一览

学习路径建议

学习顺序不是按版本号，而是按认知曲线：先学立即可用的 API 增强（序列集合、未命名变量），再学改变编码方式的模式匹配（Switch、Record），最后学颠覆并发模型的虚拟线程。虚拟线程放在最后，因为它需要你对传统线程模型有清晰的理解才能体会其革命性。

实战场景：飞翔科技高并发架构升级

大翔在 Q4 技术规划会上宣布：飞翔科技的订单核心系统将从 JDK 17 升级到 JDK 21。这不是简单的版本号升级——这意味着：

• 网关层用虚拟线程重构：Tomcat 线程池从 200 平台线程改为 10000 虚拟线程，I/O 等待不再阻塞 OS 线程
• 消息路由用 Switch 模式匹配：Kafka 消费者接收多种事件类型，switch (event) 直接按类型和字段值路由
• 订单 DTO 用 Record 模式匹配解构：record OrderEvent(String orderId, BigDecimal amount, Instant time) 在审计日志中直接解构提取字段
• 历史订单查询用序列集合：LinkedHashMap 的排序结果直接 reversed() 展示最新订单
• 监控指标聚合用未命名变量：只关心异常数量的统计，不关心的字段用 _ 忽略

环境要求

重要：本章所有特性在 JDK 21 中均为正式特性（非预览），无需 --enable-preview 参数即可编译运行。但如果你使用 JDK 21 之前的版本（如 JDK 17-20），虚拟线程和模式匹配可能需要启用预览参数。

预备知识自检

开始本章学习前，请确认已掌握以下前置内容：

• [x] JDK 8 Lambda 表达式与函数式接口
• [x] JDK 8 Stream API（中间操作与终止操作）
• [x] JDK 16 Records（不可变数据载体）
• [x] JDK 16 instanceof 模式匹配（基础用法）
• [x] JDK 14 Switch 表达式（箭头语法、yield、穷尽性检查）
• [x] JDK 17 密封类 Sealed Classes（sealed + permits）
• [x] Java 多线程基础（Thread、Runnable、ExecutorService）

面试分值分布

2024 年起，大厂 Java 面试中 JDK 21 新特性的占比快速上升。虚拟线程是必考点——面试官不再问"线程池参数怎么调"，而是问"虚拟线程和平台线程的本质区别是什么"。模式匹配相关的问题也在增加，尤其是与密封类、Records 的组合使用。2025 年后这一趋势只会加速。

面试考点

面试官常问的三个问题：

问题一："JDK 21 中最值得升级的三个特性是什么？为什么？"

答案：虚拟线程（重构并发模型，百万级线程内存占用从 GB 级降到 MB 级）、Switch 模式匹配（一个语法结构同时完成类型判断、变量绑定和守卫条件，消灭冗长的 if-else + cast 链）、Record 模式匹配（让数据解构成为语言原生能力，配合 Records 和密封类实现代数数据类型的完整表达）。这三个特性的共同点是：它们不是语法糖，而是范式转变——虚拟线程改变的是运行时模型，模式匹配改变的是类型处理范式。

问题二："虚拟线程和平台线程的本质区别是什么？使用虚拟线程需要注意什么？"

答案：本质区别在于调度层级：平台线程（Platform Thread）是操作系统线程的 1:1 映射，上下文切换由 OS 内核完成，内存占用约 1-2MB（栈空间）；虚拟线程是 JVM 在用户空间调度的轻量级线程，由 JVM 的 ForkJoinPool 承载，内存占用仅约几百字节到几 KB。虚拟线程遇到阻塞 I/O 时会自动"卸载"（yield），让载体线程去执行其他虚拟线程，而不是阻塞 OS 线程。注意事项：第一，虚拟线程不是更快的线程——计算密集型任务不会加速，反而可能因为调度开销略降；第二，虚拟线程不应被池化（ThreadPoolExecutor 不适合），应随用随创建；第三，synchronized 关键字和 Object.wait() 会"钉住"（pin）载体线程，降低虚拟线程效率，应优先使用 ReentrantLock 和 LockSupport。

问题三："Switch 模式匹配、Record 模式匹配、instanceof 模式匹配三者是什么关系？"

答案：三者是 Java"模式匹配"大特性在不同场景下的实现。instanceof 模式匹配（JDK 16）解决的是"类型判断+转换"场景：if (obj instanceof String s)。Switch 模式匹配（JDK 21）解决的是"多分支类型路由"场景：switch (obj) { case String s -> ... }。Record 模式匹配（JDK 21）解决的是"数据结构解构"场景：case Point(int x, int y) -> ...。三者可以组合使用——在 switch 的分支中同时做类型判断和 record 解构：case OrderEvent(String id, BigDecimal amount, var time) when amount.compareTo(LIMIT) > 0 -> ...。这是 Java 向"数据导向编程"演进的核心语言特性。

大翔："从 JDK 8 到 JDK 11，我们学会了删 pom.xml。从 JDK 11 到 JDK 17，我们学会了删代码。从 JDK 17 到 JDK 21，我们要学会换脑子——不是写更少的代码，是用完全不同的方式思考并发和类型。虚拟线程让'一个请求一个线程'从反模式变成最佳实践，模式匹配让类型系统从负担变成助手。这才是 JDK 21 真正的意义。"