Java on Renxin's Blog

第十六话｜SSE 是什么？为什么它会用在 AI Agent 开发中

Fri, 28 Aug 2026 00:00:00 +0000

前面把 Agent 的循环、状态、记忆和工具接起来之后，用户仍可能面对一个黑盒。

他发出“帮我检查这个仓库的测试为什么失败”，页面却在几十秒内没有任何变化。Agent 也许正在生成，也许正在调用工具，也许已经失败；用户无从分辨。

问题出在传输方式上：普通 HTTP 是一问一答——客户端发一个请求，服务端算完最后一次性返回完整响应。Agent 干活要几十秒，响应就空白几十秒。要让 Agent 不再像黑盒，前端不只需要最终答案，还要持续接收文本增量、工具状态和 Run 的终态。

SSE（Server-Sent Events）就是把这类服务端到浏览器的连续事件放进 HTTP 的一种标准方式。结论先说：SSE 不负责让 Agent 变聪明；它负责把 Agent 已经发生的事，按事件边界可靠地呈现给 UI。

一、旧方案为什么看不见

“给我一个答案”用普通 HTTP 正合适：提交命令，取回结果，一次交互结束。但“让我看着你干活”不行——服务端在没有完整结果前不会返回响应，浏览器也就拿不到任何进度。

要让用户看见进度，服务端必须在计算完成前就开始输出，并且持续输出。这正是 SSE 站在 HTTP 上的理由：一个响应保持打开，服务端不断写入“有边界的小段文本”。

这里有个经常被混在一起的概念要拆开说清楚。HTTP 持久连接（persistent connection / Keep-Alive）指的是底层连接可以复用、承载多次请求响应，它降低建连成本，但服务端不会在没有新请求时主动推送业务消息。RFC 9112 §9.3 长轮询是应用层写法：服务端先不立即返回，等到有数据或超时才结束响应，浏览器收到后再发起下一次请求。它们都不等于“一个持续打开、服务端主动下推的响应”。

四种常用方式的层次差别，一张表就能看明白：

方式	它解决什么	通信方向	一次交互是否持续	Agent 中合适的职责
普通 HTTP	提交命令、取得一次结果	双向，但一问一答	否	创建 Run、提交用户输入、取消任务、确认敏感工具调用
HTTP 持久连接	复用底层连接，减少建连成本	仍是多次 HTTP 请求/响应	否	通常由客户端、网关和连接池处理，不是事件通道方案
SSE	服务端持续发送有边界的文本事件	服务端 → 浏览器	是	文本增量、工具进度、Run 状态、最终结果
WebSocket	持续的双向消息	双向	是	协同编辑、高频客户端指令、双方都需随时发消息的交互

WebSocket 与 HTTP 的关系也要说准确：它用 HTTP Upgrade 完成开场握手，握手成功后双方交换的是 WebSocket 帧，而不是继续交换 HTTP 响应体。RFC 6455 §4

关键洞察：持久连接是连接复用策略；SSE 是 HTTP 上的事件流格式；WebSocket 是经 HTTP 握手切换出的双向协议。它们不在同一抽象层。

二、亲眼看：SSE 在线上传了什么

浏览器用 EventSource 发起请求，服务端以 Content-Type: text/event-stream 返回响应，并持续写入按行组织的 UTF-8 文本。每个事件以空行结束。WHATWG HTML Standard §9.2

下面是一个完整事件，不是一段“随便输出的文本”：

id: 42
event: text.delta
data: {"runId":"run_123","delta":"正在读取测试报告…"}

四个常用字段的职责如下。

字段	协议层含义	在 Agent 流中的用法
`data`	事件数据；可以多行，浏览器会按规范合并	放 JSON payload，例如文本增量或工具结果摘要
`event`	事件类型；省略时是默认 `message`	区分 `text.delta`、`tool.started`、`run.completed`
`id`	更新浏览器保存的最后事件 ID	用作断线续传的游标；服务端仍需校验 Run 归属
`retry`	建议浏览器下一次重连前等待的毫秒数	仅调整重连等待，不解决事件去重或业务恢复

注意最后一行的空行不是装饰。它是事件边界：如果连接在空行前结束，尚未完成的事件不会被分发。WHATWG HTML Standard §9.2.5–9.2.6

浏览器端不需要自行解析每一行：

const source = new EventSource(`/runs/${runId}/events`);

source.addEventListener("text.delta", (event) => {
 const { delta } = JSON.parse(event.data);
 appendAssistantText(delta);
});

source.addEventListener("run.completed", () => {
 source.close();
});

EventSource 对断开连接具备重连处理，并在已有事件 ID 时把 Last-Event-ID 带回服务端。它提供的是恢复的协议钩子，不是“消息恰好一次送达”的保证；应用仍要定义续传、去重和终态行为。WHATWG HTML Standard §9.2.3–9.2.4

三、事件的形状由业务决定：Agent Run 事件契约

只把模型 token 一段段传到 UI，用户会看到“它在说话”，但仍不知道它是否在行动。

对一个会调用工具的 Agent，更有用的做法是把 Run 生命周期投影成一组应用层事件：

例如，“检查测试为什么失败”这个 Run 在客户端看来可以是这样一串事件：

event: text.delta
data: {"runId":"run_123","delta":"我先运行测试。"}

event: tool.started
data: {"runId":"run_123","tool":"run_tests","callId":"call_7"}

event: tool.completed
data: {"runId":"run_123","callId":"call_7","summary":"3 个测试失败"}

event: run.completed
data: {"runId":"run_123"}

这些名称不是 SSE 规定的字段值，而是本文建议的业务事件契约。SSE 只规定如何分帧、如何指定事件类型、如何传递最后事件 ID；tool.started 是否存在、数据结构是什么、是否向用户展示工具结果，都由你的 Agent 产品和安全策略决定。

这和 Java 微服务中的“领域事件”和“Kafka 的传输记录”很像：Kafka 不替你定义订单状态机；SSE 也不替你定义 Agent Run 状态机。先定义业务状态和权限边界，再选择传输通道。

四、动手：跑通一条本地 Agent Run 事件流

这一节的 demo 不调用真实模型，避免让 API Key、模型费用或网络问题遮住协议本身。服务端固定模拟一个 Run：它先发送文本增量，再报告工具开始、工具完成，最后发送 Run 完成事件。

配套代码有两份等价实现：Python 位于 GYA 的 c16-sse-agent-stream/，Java 位于 GYA-Java 的同名 Gradle 子模块。正文以 Python 为主，Java 版用于验证同一协议不依赖语言或 Spring 框架。

Python：标准库即可启动

前置环境：Python 3.9+ 与 curl，无第三方依赖、无 API Key。

终端一启动服务：

git clone git@github.com:renxin2024/GYA.git
cd GYA/c16-sse-agent-stream
python3 main.py --once

终端二订阅：

curl -N http://127.0.0.1:8765/events

我在本机实际收到的输出如下：

id: 1
event: text.delta
data: {"runId":"run_demo","delta":"我先运行测试。"}

id: 2
event: tool.started
data: {"runId":"run_demo","tool":"run_tests","callId":"call_1"}

id: 3
event: tool.completed
data: {"runId":"run_demo","callId":"call_1","summary":"3 个测试失败"}

id: 4
event: run.completed
data: {"runId":"run_demo"}

这里最重要的不是 sleep(0.1)，而是每次写完一帧后立刻 flush，并且用最后那个空行完成事件。把空行删掉，再用浏览器 EventSource 接收时，读者会发现它不会把这一帧当作完成的事件。

Java：同一事件流，不换协议

前置环境：JDK 21 与 curl。GYA-Java 使用仓库自带的 Gradle Wrapper；首次运行会按仓库配置下载 Gradle 和 Jackson。

终端一启动：

git clone git@github.com:renxin2024/GYA-Java.git
cd GYA-Java
./gradlew :c16-sse-agent-stream:run --args="--once"

终端二订阅：

curl -N http://127.0.0.1:8766/events

Java 版构建通过，并按相同顺序输出 text.delta、tool.started、tool.completed、run.completed。核心的分帧代码和 Python 同构，只是把字符串拼接换成了 Jackson 序列化 payload：

private static byte[] encode(Event event) throws IOException {
 // SSE 是 UTF-8 的按行协议。最后的空行是事件边界；删除它会让
 // EventSource 持续等待，而不是把前面的字段作为一条完整事件分发出去。
 String frame = "id: " + event.id() + "\n"
 + "event: " + event.type() + "\n"
 + "data: " + JSON.writeValueAsString(event.data()) + "\n\n";
 return frame.getBytes(StandardCharsets.UTF_8);
}

Event 是一个只保存 id、type、data 的 record；EVENTS 里和 Python 一样放着四个固定事件。既然协议的“形状”完全由分帧代码决定，换语言、换框架都不会改变这条事件流的语义——这正是把协议层与业务层分开的价值。

如果 Java 版本因 toolchain 无法启动，先运行 java -version 确认实际环境是 JDK 21。这个 demo 故意保持 Java 21，不为了迁就本机默认 JDK 而降低系列约束。另外，不要把 Python 与 Java 输出的 JSON 键顺序当作正确性标准：JSON 字段顺序不属于 SSE 契约。

五、能连通 ≠ 体验到好：三个坑

连得上、有输出，不代表体验是对的。下面是三个最常见的“能连通、但体验很差”的问题。

1. 服务端在发，用户却最后一次性看到

SSE 需要端到端按事件及时传输。规范明确提醒：不恰当的块缓冲可能延迟事件分发。WHATWG HTML Standard §9.2.5

因此排查顺序不该从“模型为什么这么慢”开始，而应沿着浏览器 → CDN/网关 → 反向代理 → 应用服务器逐跳确认：响应类型是否正确、是否有缓冲、应用是否真的在事件产生时写出。curl 先关掉客户端缓冲（curl -N）；如果 curl 能一帧帧出来、浏览器不行，问题大概率在中间层。具体关闭何种缓冲取决于网关产品和部署方式，不能从一段通用配置照抄。

2. 断线后重复显示，或者漏掉关键状态

浏览器会携带 Last-Event-ID 重连，但服务端必须决定这个 ID 的语义：它是某个 Run 内单调递增的序号，还是全局事件 ID？事件保留多久？补发窗口过期时如何回退？

一个可维护的最小约定是：runId + eventId 唯一；客户端按该组合去重；服务端只允许已授权的主体按 runId 查询或续传。这里的授权检查不能因为客户端带了一个事件 ID 就被跳过。

3. Run 已结束，连接和资源还在等待

run.completed、run.failed、run.cancelled 这类终态应有清晰语义：服务端发送终态事件后结束流，客户端收到后关闭 EventSource 并更新界面。心跳注释可以帮助发现中间链路的空闲超时，但心跳不应伪装成业务进度。MDN SSE 指南

关键洞察：SSE 解决“事件怎样流到浏览器”；事件是否可恢复、可授权、可解释，仍是 Agent Run 模型的责任。

六、回到开场：黑盒变成了可见的事件流

现在回头看开头的那个 Run。“帮我检查这个仓库的测试为什么失败”在 demo 里变成了一条可见的时间线：先是“我先运行测试。”的文本增量，然后是工具开始、工具完成（3 个测试失败），最后 Run 完成。用户不再对着空白页面猜 Agent 是不是卡死了——他能看到 Agent 正在做什么、做到哪了、结果如何。

这就是这一话真正改变的东西：“它在动”从结论变成了过程。 SSE 不负责让 Agent 变聪明，它负责把 Agent 正在做和已经做的事，按事件边界可靠地送到浏览器；之后要不要展示工具结果、要不要拒绝敏感调用，仍然是产品与安全决策。

七、选型：什么时候选 SSE，什么时候不选

如果 UI 的主要需求是“服务端持续告诉用户发生了什么”，SSE 是很自然的第一候选：浏览器有原生 EventSource，协议有事件类型和重连语义，接入普通 HTTP 基础设施的成本通常较低。

如果客户端也需要高频、低延迟地主动发消息，例如多人协同编辑、实时控制面板或双向交互游戏，再评估 WebSocket。若只是提交用户问题、取消 Run 或同意执行高风险工具，普通 HTTP 往往更直观，也更容易把请求、权限校验和审计记录放在清晰的命令边界上。

不要用“WebSocket 更实时”替代选型分析。对 Agent 来说，最关键的问题是：消息主要朝哪个方向流？是否需要浏览器原生重连与事件 ID？你的 Run 是否有可恢复的状态模型？

八、下一步

这一话放在 GYA 的生产级补充位置：它不增加 Agent 的推理能力，却决定用户能否看见、理解和恢复一次正在运行的 Agent 任务。

从开场那个 Run 继续往后走，下一步应把同样的事件契约接到真实的 Run 状态存储、鉴权与可观测性中——而不是继续往 SSE 帧里塞业务判断。

参考资料

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

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增强等，这里不多做介绍。