企业官网建设流程全解析

我从 Java 8 切到 Java 23 已经有小一年。当时不是头脑发热，而是手头一个跑了两三年的订单聚合服务，线程模型和中间处理链已经写得很难受了。抱着试试看的心态在几个非核心模块上做了验证，后来才慢慢把压测、灰度、重构整个流程过了一遍。这篇文章就是把我这半年多在 Java 23 新特性落地实战里真正用起来的东西，包括流收集器、字符串模板、结构化并发、作用域值、模块导入，以及底层 GC 和字节码方向的变化，都摊开讲。不是为了给你背一遍 JEP 清单，而是想聊聊哪些值得立刻上、哪些还得再观望、哪些坑我踩得特别疼。适合正在评估从 JDK 17/21 往上升级的同学，也适合想在老项目里逐步引入新写法的朋友。先给个总看法：Java 23 不是又一个平平无奇的版本号，它把 Java 21 以来开发方式的改变真正往前推了一步。

1. 这份 Java 23，到底什么值得上手？

1.1 快速扫一眼：JEP 名单和定位

很多老 Java 看到新版本的第一反应是“又强迫我学新东西”。我一开始也这么想，但把 JEP 看完之后发现，Java 23 真正改变日常编码习惯的其实就集中在几块。我按“值不值得现在追”的顺序整理了一张表，方便你快速定位。

表格里的排序不是按 JEP 编号，而是按我个人踩坑后的推荐优先级。你如果时间有限，就先把 Stream Gatherers、结构化并发、作用域值、字符串模板这四块看明白，其他内容知道概念，遇到场景能想到就行。

1.2 我为什么把“并发三件套”放在第一优先级

我见过太多项目升级 JDK，只盯着语法糖和代码风格，一上来就高喊“要用新特性”。但 Java 23 真正改变服务端开发方式的，是并发模型这一套东西：虚拟线程、结构化并发、作用域值。虚拟线程在 Java 21 已经转正，Java 23 里依然是最底层的基础设施。结构化并发和作用域值虽然还在预览期，但已经足够把一个大任务拆成多个子任务、统一管理成功和失败，代码的清晰度和可靠度比 CompletableFuture 硬拼回调好太多。

举一个典型的场景：订单详情页要聚合订单、用户、库存、优惠券四个来源的数据。以前是用线程池并发提交四个 Callable，再 countDownLatch 等结果，异常处理乱成一团。到了 Java 23，一个请求开一个虚拟线程，里面再用结构化并发 fork 四个子任务，谁失败就把其他任务取消，主线程拿到结果后统一返回。这套模型对服务端同学来说，是真的能把代码结构改到“一眼看懂”的程度。所以我后面专门用一个章节来讲这几个 API 怎么配合，而不是把它们拆开单独看。

2. 流收集器 Stream Gatherers：把 map/flatMap 的“收纳”能力补齐了

2.1 先说痛点：为什么 limit、skip、distinct 不够用

流式编程用久了，你会发现一个特别尴尬的事：中间操作里能用的“收纳型”操作太少。map 是把一个元素变成另一个，filter 是挑元素，limit 是截断，distinct 是整体去重。可实际业务里很多需求是这样的：每 100 个元素凑一批、按某个业务键去重但保留顺序、把连续窗口里的元素拿出来做窗口计算。这些用原生 Stream 写起来不是不行，但很别扭，往往要么先 collect 成 List，再手动写循环，要么强行用 Collectors 的奇技淫巧。

Stream Gatherers 就是来解决这个问题的。它让你自定义中间操作，管你叫“收集器”，但这不是终端 Collectors 那种东西，而是可以在流中多次出现、按顺序处理元素、并且可以携带状态的自定义中间操作。Java 23 里它还在预览期，对应 JEP 473，但 API 已经相当完整，完全可以拿来写业务代码。

下面这个例子是我在某个 B2C 项目里做增量同步时写的。订单明细表里有上万条记录，直接从数据库读取后需要按每 100 条一组提交到下游接口。以前我会写一个计数器加循环，现在写起来就是一行的感觉：

List<Order> orders = loadOrders(); List<List<Order>> batches = orders.stream() .filter(o -> o.getStatus() == Status.PENDING) .gather(Gatherers.windowFixed(100)) .toList(); for (List<Order> batch : batches) { syncService.syncBatch(batch); }

windowFixed(100) 会把流切成固定大小的窗口，最后一个窗口如果不足 100 条也会正常返回。这里要留意的是，窗口里的元素是 List，不是原元素类型，所以 gather 之后的流类型会从Stream<Order>变成Stream<List<Order>>。还有一个兄弟方法叫 windowSliding，它做的是滑动窗口，比如每次挪一步、窗口长度 3，适合做时间序列的移动平均一类的计算。

2.2 自定义 Gatherer：两分钟实现一个“按业务键去重保序”的收集器

distinct 只能按对象整体去重，实际业务里更常见的是按某个字段去重。比如从多个渠道捞回来的用户列表，同一个 userId 可能出现好几次，但你只想保留第一次出现的那条。很多人的第一反应是用Collectors.toMap(key, item, (a, b) -> a, LinkedHashMap::new)转一下再取 values。能跑，但代码读起来绕。

用 Gatherer 自定义一个 distinctBy 就清晰得多。先看完整实现：

import java.util.HashSet; import java.util.Set; import java.util.function.Function; import java.util.stream.Gatherer; public static <T, K> Gatherer<T, ?, T> distinctBy(Function<? super T, ? extends K> keyExtractor) { return Gatherer.ofSequential( HashSet::new, (state, element, downstream) -> { K key = keyExtractor.apply(element); if (state.add(key)) { downstream.push(element); } return true; } ); }

使用方式：

List<User> validUsers = rawUsers.stream() .filter(u -> u.getStatus() == Status.ACTIVE) .gather(distinctBy(User::userId)) .toList();

真正理解这个 API，要看懂四个组件：Initializer 负责创建状态容器，这个例子里就是 HashSet；Integrator 是核心处理器，每次流里来一个元素就调用它，我们拿到元素后提取 key，如果 HashSet 里没有就加入并推向下游；Combiner 用于并行流场景的状态合并；Finisher 在流结束时做收尾。我这个例子是顺序流，直接用ofSequential就行，省得处理并行合并。

我实际测试过，这段去重逻辑在百万级用户流上跑，内存占用比Collectors.toMap那套小不少，因为状态里只存 key，不用把整条元素都留着。而且它是个中间操作，后面还能继续接 filter、map，灵活性比一次性终端操作强。

2.3 实战要点：Stream 只能消费一次，别在收集器里搞副作用

Gatherer 看起来很灵活，但越灵活就越容易用歪。我在测试阶段踩过一个坑：在 Integrator 里直接调外部接口，比如每来一个元素就去查一次数据库，然后在 downstream.push 之后向后端发一条日志。看起来像流水线，实际上把流量全部串进去了，而且 Gatherer 是惰性求值，如果流最终没有被终端操作触发，Integrator 里的代码其实不会执行。这就导致你以为是同步操作，结果数据没推出去，排查起来特别像“玄学问题”。

我后来定了一个原则：Gatherer 只做纯状态转换，所有外部副作用放到流结束之后，或者至少放到终端操作之后用 forEach 处理。如果你确实需要边遍历边批量写入，那就和第一节的 windowFixed 配合，先把批量窗口切出来，再在 for 循环里真正执行写库，这样每一步都看得见摸得着。

3. 用字符串模板拼日志、拼 SQL，比你想的更稳

3.1 对比旧方案：加号拼接、StringBuilder、formatted 的缺点

你说 Java 拼字符串真的难吗？不难，就是丑。"a" + b + "c"写多了眼睛疼，StringBuilder 在方法里写两行就嫌长，String.format又要记占位符。更关键的是，这三种方式都没有安全处理能力，拼接 SQL 有注入风险，拼接 JSON 有转义风险，拼接日志有时还会把 null 打成一个陌生的字符串。

Java 23 里的字符串模板终于把“表达式嵌入”和“模板处理器”两件事合并了。最简单的用法是 STR 模板处理器：

String name = "某用户"; String message = STR.""" 用户 \{name} 已经登录 """;

这个\{name}就是一个嵌入表达式，你可以写方法调用、三元表达式、甚至是\{order.getAmount() * 1.2}这种计算。多行文本用"""包起来，读起来就像一份填好值的模板。FMT 处理器还能带格式，比如FMT."%8.2f\{amount}"控制小数点位数，用于生成报表文本时非常省事。

3.2 用自定义 TemplateProcessor 拼 SQL，如何避免注入

字符串模板真正让我放下戒心的地方在于，它允许你把“模板”和“处理策略”解耦。默认的 STR 就是简单的字符串替换，但你可以写一个自定义的 TemplateProcessor，在替换之前先做转义，这样嵌入的变量再也不是裸拼进 SQL 了。

我写了一个简易的 SQL 安全模板处理器，核心思路就是遍历模板片段和值，把所有字符串值做转义，数字值做强校验：

TemplateProcessor<String> SQL = fragments -> { StringBuilder sb = new StringBuilder(); List<String> frags = fragments.fragments(); List<Object> vals = fragments.values(); int i = 0; for (String frag : frags) { sb.append(frag); if (i < vals.size()) { Object v = vals.get(i); sb.append(escapeSql(v)); } i++; } return sb.toString(); }; static String escapeSql(Object v) { if (v instanceof Number) return String.valueOf(v); return "'" + String.valueOf(v).replace("'", "''") + "'"; }

然后就能这样写：

String name = "张三'; DROP TABLE user;--"; String sql = SQL.""" SELECT * FROM user WHERE name = \{name} """;

因为所有字符串值都被escapeSql处理过，注入内容会被转成普通字符串，不会再威胁到 SQL 结构。这个能力才是字符串模板比加号拼接高级的本质：模板只决定结构和位置，处理器决定值怎么落地。

3.3 一个更稳妥的实践：字符串模板的局限与兼容性

开心归开心，还是得泼盆冷水。字符串模板在 Java 23 依然处于预览状态，也就是说要用它必须开--enable-preview。这就带来几个问题：

• 编译和运行都要带同样的参数，任何一个环节漏了都会报错；
• 预览特性的 API 在后续版本可能调整，你不能指望这些代码跨版本原样兼容；
• 日志框架、MyBatis 这类第三方工具目前不会主动去解析你的字符串模板，你只能在业务代码里自己处理；
• 团队协作时，只要有人没开预览配置，整个项目的构建就会挂。

我的实际建议是：可以在小工具、独立模块、内部项目里用它写 SQL 和报表模板，体验确实好。但如果你想把它铺到一个几十人的核心业务仓库里，一定先确认全链路 JDK 版本和 IDE 配置都统一，否则上线前一天同事说编译不过，那个场面会很难看。

4. 并发能力再进化：虚拟线程配套的结构化并发和作用域值

4.1 虚拟线程在 Java 23 的实际体验

虚拟线程在 Java 21 已经正式转正，Java 23 里它已经是服务端开发的基本盘。我自己在订单聚合服务里做过一个真实切换：原来用固定大小线程池newFixedThreadPool(50)去并发调下游，切到虚拟线程后，每个请求动态开一个虚拟线程，代码还更简单了。

最直观的变化是，你可以把线程数量从“强制池大小”变成“按需创建”，因为虚拟线程非常轻。我把线程池替换成直接提交 Runnable 到虚拟线程 ExecutorService 后，单机峰值 QPS 稳定提升，线程数再也不是瓶颈。注意，虚拟线程并不是免费的火箭，它特别适合 I/O 密集场景，对 CPU 密集计算没有帮助。你要是拿它去死循环算圆周率，反而会因为调度开销变慢。

这里有一个特别重要的红线：不要在synchronized代码块里做阻塞操作。虚拟线程遇到 synchronized 时，如果发生阻塞，可能会发生 pinning，也就是把平台线程顶住不动，一旦平台线程全被 pin 住，你的虚拟线程调度就退化成普通线程池。项目里如果有老代码用了很多 synchronized 锁内做远程调用，还是先把锁改成 ReentrantLock 再上虚拟线程更稳。

4.2 用结构化并发把异步任务编排得明明白白

虚拟线程解决的是“轻量”问题，结构化并发解决的是“可读可维护”问题。以前我们用 CompletableFuture 做并行编排，代码一复杂就是一堆 thenCompose、exceptionally、handle，读起来脑壳疼。Java 23 的StructuredTaskScope用了一种更朴素的思路：在一个作用域内 fork 子任务，所有子任务生命周期绑定在作用域 block 里，用一个 try-with-resources 就能统一关闭。

我写一个真实场景的代码。订单详情页需要并行查订单、用户、库存三样东西，任何一个失败直接取消其他两个，并且向上抛错：

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) { Future<OrderInfo> orderFuture = scope.fork(() -> orderService.queryOrder(orderId)); Future<UserInfo> userFuture = scope.fork(() -> userService.queryUser(userId)); Future<StockInfo> stockFuture = scope.fork(() -> stockService.queryStock(orderId)); scope.join(); // 等待所有子任务完成，或者其中一个失败 scope.throwIfFailed(); // 如果有失败，取消其他任务并抛出异常 return new OrderDetail( orderFuture.resultNow(), userFuture.resultNow(), stockFuture.resultNow() ); }

这套代码的好处是：所有子任务的生命周期都在 try-with-resources 范围内，即使抛异常也不会出现子任务在后台乱飘的情况。ShutdownOnFailure是当某一个子任务失败时，自动关闭作用域并取消还没跑完的任务。还有ShutdownOnSuccess，谁先成功就取消其他任务，适合做“多个数据源谁先返回用谁”的容灾场景。

要提醒的是，结构化并发还在预览期，编译运行都要--enable-preview。但它配合虚拟线程的效果确实好，我建议你在非核心服务里先验证一套，等到转正后再全面铺开。

4.3 用 ScopedValue 替代 ThreadLocal 的时机

服务端代码里最常见的 ThreadLocal 用途就是传 traceId、userId 这种请求上下文。ThreadLocal 用久了问题不少：随手忘记 remove，就会在线程池复用的线程上残留脏数据；跨线程传递又得用 InheritableThreadLocal，代价是每个子线程都要复制一份；虚拟线程出现之后，ThreadLocal 的语义就更尴尬了，虚拟线程成千上万，每个 ThreadLocal 都成了潜在的内存占用大头。

ScopedValue 的思路是“只在某个作用域里有效”，值绑定到一段代码，运行完自动清理。用法如下：

static final ScopedValue<RequestContext> REQUEST = ScopedValue.newInstance(); // 请求入口 void handle(Request req) { var ctx = new RequestContext(req.getTraceId(), req.getUserId()); ScopedValue.where(REQUEST, ctx).run(() -> doHandle(req)); } // 任意深浅方法中读取 void doHandle(Request req) { RequestContext ctx = REQUEST.get(); log.info("traceId {}", ctx.traceId()); }

ScopedValue 和结构化并发天然能配合起来。在 StructuredTaskScope 里 fork 子任务时，子任务会继承父任务的 ScopedValue 绑定，而且不需要复制，只是共享只读引用。这比 InheritableThreadLocal 的“每个子线程复制一份”优雅太多。不过它也是预览 API，命名空间在 jdk.incubator.concurrent，用的时候注意模块导入。

我现在的选择是：新写的服务端代码统一用 ScopedValue，老代码里除非这轮搬不动，否则不新增 ThreadLocal。

4.4 预览 API 的四个大坑，别在关键服务里乱开

结合我在项目里看到的真实情况，预览 API 的坑和应对方式可以整理成四个关键点。

• 编译和运行参数必须完全一致。javac 加了--enable-preview，运行 java 也一定要加，并且--release版本要写对。漏一个就会在启动时报UnsupportedClassVersionError或class file has wrong version。
• 预览 API 的包名和类名以后可能变。我吃过亏，前期在某内部工具里用了预览版 ScopedValue，切到下一个 JDK 时发现包路径调整了，虽然能迁移，但改起来又得动一堆 import。
• 不要在关键链路上压上“预览”两个字。虚拟线程转正了可以随便用，但结构化并发、Stream Gatherers、字符串模板这三个我是放在非核心模块或独立服务里的。核心计费、风控链路慎用，因为预览特性一旦变，你没法保证线上快速热修。
• 团队协作时要在 README 里写明 JDK 和编译选项。这个看起来是小事，但真实发生过的坑就是：新同学拉代码编译报错，不关 IDE 的 preview 配置，把错误当成项目损坏，浪费一晚上排查。

5. 几个让我写代码更顺手的小改动：隐式类、模块导入、变量作用域

5.1 无类启动：隐式类和实例主方法

Java 的 main 方法从public static void main(String[] args)一路演进到 Java 23，终于可以不写类和 static 了。现在你写一个最简单的文件：

void main() { System.out.println("Hello Java 23"); }

直接java Hello.java就能跑。第一次看到这个语法时，我第一反应是：以后写小工具、写算法验证、写临时脚本的体验会好很多。不用再包一个 PublicClass，也不用记String[] args。对新手友好的程度直接拉满。这个特性目前是第二次预览，正式转正我估计就是下一两个版本的事。

5.2 从import java.util.*到模块导入声明

模块导入声明的预览特性对老手来说可能觉得花哨，但我却觉得它才是解决“工具代码里 import 爆炸”的答案。以前写一个小工具类，开头恨不得二十多行 import，全是import java.util.List;、import java.util.Map;、import java.time.LocalDateTime;之类的。

现在可以写：

import module java.base; void main() { var list = List.of(1, 2, 3); var map = Map.of("a", 1); System.out.println(list.stream().mapToInt(Integer::intValue).sum()); System.out.println(LocalDateTime.now()); }

一条 import 语句把整个 java.base 模块里导出的包都带进来了。听起来挺暴力，但对 demo、原型、脚本类代码非常合适。大项目里不建议这么干，显式 import 才能让人知道你到底依赖了什么。我的建议是：模块导入声明只放在那种不需要长期维护的临时文件里，别在业务源码里图省事。

5.3 lambda 和匿名类的变量捕获更宽松了

Java 23 更新了匿名类和 lambda 的变量作用域规则，这个改动的感觉像是“把编译器管得太宽的手松开了一些”。以前在 lambda 表达式里声明和外部局部变量同名的变量，编译器会直接报错，非逼着你改名。现在规则更贴近普通方法，只要语义正确，重名问题不再变成一个硬性阻断。

我遇到过最典型的场景：在一个 for 循环里往流管道里写 lambda，lambda 参数想叫item，但外面已经有一个局部变量叫item。以前只能改成it或者别的名字，现在能更自由地命名，代码读起来不那么“因为编译器而别扭”。属于细节体验，但能减少无谓的纠结。

5.4 说下我改完之后的真香场景

这些东西单独看都显得小，组合起来就很香。我最近写一个内部数据核对工具，整个文件就是：

import module java.base; void main() { var loaded = FileIO.loadLines("data.txt"); var result = loaded.stream() .gather(distinctBy(line -> line.split(",")[0])) .map(String::trim) .toList(); result.forEach(System.out::println); }

没有类，没有长串 import，没有一堆样板代码。虽然现在正式转正还需要等一等，但它已经提前改变了我写工具类的方式。

6. 这些藏在底层的改动，比语法糖影响更大

6.1 分代 ZGC 带来的现实收益

多数应用开发者平时不太注意 GC 默认值，但 Java 23 把分代 ZGC 设成了默认，这背后是有实际收益的。之前 ZGC 默认是非分代模式，整个堆一个代，GC 时要扫描和移动的东西范围较大。分代 ZGC 把年轻代和老年代分开，短命对象在老年代之前就被处理掉，长命对象留在老年代，整体 GC 停顿时间依然保持很低，同时吞吐量更稳定。

我在一个 64GB 堆的服务上观察过，切换到 Java 23 默认的分代 ZGC 后，大促期间的 GC 停顿时间没有恶化，内存分配峰值反而略有下降。如果你已经在用 ZGC，升级到 Java 23 后什么都不用改，直接继承默认的-XX:+ZGenerational。如果你想对比老行为，可以用-XX:-ZGenerational关掉，但我不建议你留在非分代模式上，新默认值经过官方调优，基本可以直接信任。

6.2 别再把 sun.misc.Unsafe 当万能钥匙

Java 23 里有一个影响库开发者的重要动作：sun.misc.Unsafe里的内存访问方法被标记为弃用（对应 JEP 471）。很多老框架和中间件当年为了绕过 Java 的类型系统、做高性能内存操作，会直接调 Unsafe 的 allocateMemory、freeMemory、putInt 这一类方法。现在官方正式表态，这些方法将来是要移除的。

对于普通应用开发者，我的建议很直接：不要在业务代码里碰sun.misc.Unsafe，你大概率用不到，而且用了就是在给未来的迁移埋雷。对于自己维护公共库、ORM、缓存组件的同学，趁 Java 23 这个版本把 Unsafe 的内存访问替换成VarHandle或标准的MemorySegmentAPI，强烈建议现在就启动改造。这不是一个月能做完的事，但越晚做，存量代码越多，越被动。

6.3 Class-File API：未来字节码处理的官方答案

还有一个方向值得关注，就是 Class-File API。以前我们要做字节码增强，几乎都是引第三方库，比如 ASM。Java 23 里正式推出了官方版的 Class-File API（JEP 466，还是预览），它的目标就是把“解析、生成、转换 class 文件”这件事标准化。

这个 API 对框架作者是有吸引力的，因为以后不需要在项目里捆绑一堆字节码处理库。举个例子，读取一个类的所有方法名和描述符：

ClassFile cf = ClassFile.of(); ClassModel cm = cf.parse(Paths.get("SomeClass.class")); cm.methods().forEach(m -> { String name = m.methodName().stringValue(); String type = m.methodType().stringValue(); System.out.println(name + " : " + type); });

如果你的项目里只是写业务代码，那这个 API 目前离你很远，知道有这么回事即可。但如果你维护 Spring 一类的底层框架、做 APM 插件、写代码生成器，就要开始提前熟悉它了。预览 API 通常过几个版本转正，等到转正再临时学，会有点赶。

7. 常见问题与排查技巧实录

7.1 开启预览特性后编译“乱报错”怎么办

这是我在内部培训里被问到最多的问题。如果你已经加了--enable-preview但还是报错，先按下面几步排查：

• 确认编译器版本：javac -version必须是 23。如果你机器上有多个 JDK，ide默认用的可能还是 21。
• 确认 release 参数：编译时用javac --release 23 --enable-preview Foo.java，运行用java --enable-preview Foo。只加 release 不加 enable-preview，会明确报“预览特性未启用”。
• Maven 项目里，要在 pom 里同时设置maven.compiler.release=23和maven.compiler.enablePreview=true。如果只设其中一个，编译时经常出现“无效的标记: --enable-preview”这种误导性错误。
• IDE 里也要单独开启 Preview 选项。IDE 默认跟随项目配置，但经常因为你手动改了 pom 后不同步，需要检查。

7.2 Stream Gatherers 踩过的坑：collect 之后流不能复用

用 Stream Gatherers 最常见的报错就是java.lang.IllegalStateException: stream has already been operated upon or closed。这不是 Gatherer 的锅，而是 Stream 本身的特性。很多人封装一个方法返回一个带 gather 的 Stream，然后业务代码里先用它做了一次遍历，后面又把这个 Stream 拿去做第二件事，就会卡在这里。

正确的做法是不要尝试复用流，每次都要新建。如果中间的 gather 计算特别贵，可以先toList()把结果落成一个普通 List，再从这个 List 重新生成流做后续处理。我自己的准则是：业务代码里，Stream 管道最多在一个方法里从头用到尾，绝不出方法后再次被消费。

7.3 字符串模板的处理器坑：STR、FMT、RAW 别搞混

字符串模板里，STR 是最常用的，它做的就是原生字符串替换。FMT 支持格式化，和String.format的格式规则类似，可以处理小数位、宽度、对齐。RAW 返回一个尚未处理的 StringTemplate 对象，一般只有你想自定义嵌套处理器的时候才会用到。

一个容易出错的地方是：FMT 处理器如果格式符和嵌入表达式的顺序没对上，结果会比预期少或多几个空格。类似FMT."%8.2f\{price}元"，价格少于 8 位时会补空格，这在生成报表文本时可能是你要的，但如果是拼接普通消息，就不要用 FMT，直接用 STR，避免出一堆奇怪空格。

7.4 虚拟线程迁移后线程池“炸了”的故障

迁移到虚拟线程后，很多人第一反应是把原来的线程池全部直接替换成虚拟线程池。这本身没错，但有个隐藏问题：虚拟线程数量没有上限，你等于把并发控制的闸门拆了。以前线程池大小 50，系统再怎么突发流量，同时执行的线程最多 50 个。现在每次请求都开一个新虚拟线程，如果下游接口变慢，虚拟线程会快速堆积，整体并发直接打到下游，下游接不住就开始连环超时。

正确做法是保留一层并发限流，比如用信号量控制Semaphore同时运行的任务数，或者用网关限流。把线程池大小从“并发上限”的身份里解放出来，用专门的限流组件控制系统容量，虚拟线程才能发挥真正的轻量优势。这算是我这一轮升级里补的一堂架构课：线程池以前是万能的，在虚拟线程时代，它不再等于限流器。

最后再分享一条自己摸索出来的经验：升级 Java 23 别急着一口气吃成胖子。我实际走的路线是，先把非核心服务升到 Java 23，只把虚拟线程用上；第二波引入 Stream Gatherers 重构掉几段恶心的窗口批处理；等团队习惯之后，再考虑字符串模板和结构化并发。每个特性上线前都过一次压测和灰度，确认没炸再继续。别小看这个节奏，能把踩坑成本摊薄到最低。说到底，Java 23 的新特性不是让你秀语法，而是让代码在高并发和高可维护性之间找到一个更舒服的平衡点，这种东西只有动手压过一遍，才能真正体会到。