虚拟线程在生产系统中的并发治理

摘要

Project Loom 让 Java 在高并发 I/O 场景下重新获得了“同步代码也能高并发”的工程可能性。它真正降低的是阻塞等待时占用平台线程的成本，而不是直接提高数据库容量、远程 API 配额、CPU 算力、磁盘带宽、消息队列分区数或者任何下游服务的硬容量。很多团队第一次接触虚拟线程时，最容易犯的错误不是 API 用错，而是心智模型没有切换：过去系统被平台线程成本强迫着显式做线程池治理，所以大家天然知道资源是稀缺的；现在虚拟线程让“每个请求一个任务”变得非常便宜，反而会让人误以为“并发本身不再需要治理”。这是 Part 3 必须纠正的第一个误区。

从架构视角看，虚拟线程不是对线程模型的一次语法糖增强，而是把 Java 并发设计的主要矛盾从“线程太贵”转移到“资源保护是否显式”。在传统平台线程时代，开发者往往把线程池大小既当作并发度限制器，又当作资源隔离器，还当作容量规划的粗粒度阀门。这个模型虽然笨重，但它至少强迫所有人承认系统有上限。到了 Loom 时代，如果仍然沿用“线程池大小等于系统容量”的旧思路，就会出现两种对立但同样危险的做法：一种是过度保守，明明可以用虚拟线程把同步代码写清楚，却依旧套上层层 CompletableFuture 和反应式回调，导致维护成本居高不下；另一种是过度激进，把原来靠线程池隐式限制住的数据库、缓存、HTTP 下游、消息处理、磁盘 I/O 和第三方 API 调用全部放大，最终把“线程不够用”的问题升级成“下游被打穿、排队时间失控、尾延迟飙升”的事故。

因此，本文不把虚拟线程当作“更快的线程”，而把它视为一种新的并发治理边界：阻塞等待可以更便宜，代码可以更直白，但吞吐模型、队列策略、超时预算、取消传播、资源池上限、回滚路径、可观测性和版本边界必须写得比过去更清楚。读完之后，读者应该能够回答以下问题：什么时候虚拟线程适合成为默认执行模型，什么时候平台线程池或反应式管线仍然更合理；为什么数据库连接池、HTTP 连接池、限流器、bulkhead、消息消费者并发和超时仍然是系统容量的真正闸门；如何识别 pinning、长临界区、原生调用和下游阻塞带来的吞吐退化；如何用结构化并发把一个请求内部的并发 fan-out 变成可取消、可超时、可聚合的任务树；以及如何在 Spring、Servlet、JDBC、RPC、批处理和混合架构中渐进迁移，而不是用一把梭的方式把风险放大。

本文的生产口径保守处理快变事实。虚拟线程在 JDK 21 进入 GA；结构化并发在本文撰写时仍处于 preview 线，需要按目标 JDK 版本和 --enable-preview 状态谨慎使用；synchronized 与 pinning 的关系在 JDK 24 之后相较于 JDK 21 到 23 已有显著变化，因此任何“monitor 一定会 pin”或者“所有 synchronized 都必须替换”的说法都应视为不可靠的过度结论。对所有版本状态、行为边界和性能判断，本文一律以“适用版本、适用前提、适用工作负载”三个维度来表达，避免把设计方向写成稳定能力，也避免把局部 benchmark 写成普适事实。

这篇文章的读法也有意区别于很多 Loom 入门材料。入门文档喜欢从“创建一百万个虚拟线程”开始，因为这能立即展示内存和等待成本的变化；但生产系统真正需要的是第二层问题：当你真的能同时挂起很多任务时，哪些资源会先撑不住，哪些指标会先失真，哪些事故会先发生，哪些治理动作必须前置。换句话说，Loom 的价值不在于展示 API 的新鲜感，而在于帮助 Java 重新用同步代码表达复杂 I/O 业务，同时把并发治理显式化、证据化、可回滚化。下面的结构就是围绕这个目标展开。

1. 虚拟线程的生产问题：为什么“线程更便宜”反而要求更强的治理

1.1 线程成本下降，系统容量不等于同步放大

虚拟线程进入生产讨论后，最常见的误读是把它等同于“无限并发”。这类误读往往源于两个心理捷径。第一个捷径是把线程数量误当成系统容量。很多工程师长期在固定大小线程池的环境里工作，于是潜意识中把“线程数”当作“系统可承载的最大请求数”。当虚拟线程让线程数不再成为第一瓶颈时，他们就误以为系统容量也一起放大。第二个捷径是把演示场景误当成生产场景。一个睡眠 1 秒的示例程序确实可以轻松承载几十万甚至更多虚拟线程，但生产请求不是只做 sleep，它会占用数据库连接、HTTP socket、TLS 会话、序列化缓冲、缓存客户端、日志吞吐、配额、事务上下文和业务对象内存。这些才是线上容量真正先爆掉的地方。

所以，要理解虚拟线程带来的生产问题，必须先把“线程成本”和“系统容量”拆开看。线程成本回答的是：一个等待中的任务在 JVM 和操作系统里需要付出多少管理成本。系统容量回答的是：整个业务链路在当前资源预算下能接受多少并发请求而不显著恶化尾延迟、错误率和下游稳定性。Loom 主要改善前者，不会自动改善后者。它把 Java 从“线程很贵，所以被迫先做线程池治理”的世界带到“线程便宜了，但你必须用更明确的机制治理资源”的世界。

1.2 过去线程池在偷偷扮演 admission control

这会在生产系统里引出一组新的治理问题。第一， admission control 要放在哪里。过去一个 200 大小的 Tomcat 线程池天然就是粗糙的 admission gate，请求多到一定程度就开始排队甚至拒绝。用虚拟线程之后，请求更容易被接纳进来，如果没有额外的限流、队列和 bulkhead，就可能把排队从入口转移到数据库、RPC 客户端、缓存或者消息系统。第二，背压信号怎么表达。平台线程池拥塞时，大家至少还能从活跃线程数、队列长度和拒绝数看出问题；虚拟线程时代，线程本身几乎不会立刻变成告警信号，反而需要更关注连接池等待时间、下游超时比例、请求级 fan-out 数量、取消失败比例和 carrier 线程占用。第三，故障传播怎么控制。同步代码写法变简单后，开发者更愿意在一个请求里直接并发访问多个依赖，这提升了表达能力，也提升了“一个上游请求引发多个下游请求”的爆炸风险。

过去的线程池常常以一种不够优雅但很真实的方式替团队兜底。只要线程池满了，入口自然就慢下来或拒绝流量，下游获得了一层粗糙保护。Loom 取消了这种偶然的保护层，因此 admission control 必须回到真正对用户价值和依赖预算负责的位置，比如网关限流、服务内 queue、租户配额或请求级 bulkhead。

1.3 组织协作也会被虚拟线程改变

从组织角度看，虚拟线程还会改变团队协作边界。过去是否采用 WebFlux、Netty 或 CompletableFuture 往往是架构层面的显式决策，一旦决定了，大家会知道系统在异步语义上有额外复杂度。用了 Loom 以后，很多业务工程师会觉得“我只是用普通同步代码写逻辑”，于是更容易绕过原本只在异步设计评审中才会被认真讨论的超时、取消、预算和幂等问题。换言之，Loom 降低了编码门槛，也降低了风险暴露的表面信号。如果治理规范不跟着升级，团队会更晚意识到并发策略发生了变化。

另一个必须正视的问题是，虚拟线程并不会自动带来更好的架构抽象。它只是让一些原本因为线程昂贵而不得不异步化的代码，重新可以以同步形式表达。可维护性的提升取决于你是否趁机把任务边界、失败策略、上下游预算、日志关联和取消语义一起收拢。如果只是把原本的“线程池包同步代码”改成“每个请求一个虚拟线程”，而数据库访问、缓存访问、第三方 API 调用仍然没有超时，没有并发上限，没有熔断，也没有降级，那么系统只是从“线程不足导致拒绝”变成“下游资源耗尽导致级联失败”。后一种事故在用户体验和恢复复杂度上通常更糟，因为它发生得更深、更隐蔽，而且不一定会在入口处立刻暴露。

1.4 读者真正要学的是预算治理，不是 API 名称

因此，Part 3 的起点不是虚拟线程 API，而是一个判断：当阻塞等待变便宜后，系统的主要治理对象从线程转向了预算。预算包括 CPU 预算、连接预算、调用预算、重试预算、排队预算、超时预算、错误预算、内存预算和运维预算。虚拟线程的生产问题，表面上看像是“线程模型升级”，本质上是“容量治理显性化”。只有接受这个前提，后面的并发模型对比、吞吐模型、pinning、结构化并发和迁移策略才有真正的落点。

1.5 为什么入口看起来更稳了，下游却可能更早崩

Loom 在许多服务上的第一个表象，是入口层看起来比以前从容。因为平台线程池不再那么早成为瓶颈，网关和应用服务器也更少出现“线程耗尽”的直接症状。很多团队会误把这种从容当作容量提升本身。实际上，这更像是把原先暴露在入口层的拥塞，转移到了更深层的依赖位置。入口不再明显排队，不等于数据库不再排队；应用线程不再饱和，不等于 HTTP 客户端连接、RPC 连接池、缓存命令、消息系统确认链路和第三方 API 配额也一起变松。对事故响应来说，这种“表面平稳、深层紧绷”的形态比旧式线程池爆满更危险，因为它会让一线值班工程师更晚注意到真正的过载已经发生。

更具体地说，平台线程时代的很多故障具有非常直观的外形：线程池活跃数触顶、队列持续增长、拒绝请求增加、容器 CPU 被频繁唤醒、线程 dump 里大量阻塞线程集中在入口处理器上。Loom 时代的故障外形往往变成：入口仍能持续接收流量，虚拟线程数量上升但未必立即异常，CPU 看上去没有被压满，真正先恶化的是连接池借用时间、下游请求 RTT、超时率、重试比率、单请求 fan-out 深度和错误传播链路。也就是说，故障不再被一个粗糙但显眼的入口闸门截住，而是更容易沿着依赖链向后蔓延。

这类事故之所以常常恢复更慢，是因为它们会同时制造多个次生问题。数据库连接等待升高会拉长事务持有时间，事务持有时间变长又会增加锁竞争；第三方 API 超时上升会触发更多重试，重试又进一步放大下游压力；消息消费线程在等待外部依赖时积压，会把 consumer lag 和业务补偿延迟一起拉高；上游请求还没被明显拒绝，用户侧只看到“系统越来越慢”，而不是“立即失败”。如果没有清晰的预算和降级策略，Loom 只会让这种放大更容易发生。

因此，判断 Loom 是否真的改善了系统，不能只看入口可承受的虚拟线程数量，也不能只看 QPS 有没有在某个窗口提高。真正应该追踪的是：是否更早暴露了真实资源瓶颈，是否把预算定义得更清楚，是否让系统在高峰下更容易快速失败而不是深层排队，是否让取消传播和 deadline 更有效地减少无价值工作。只有这些问题的答案都朝正确方向走，入口“更稳”才是健康信号，而不是一层更平滑的假象。

1.6 并发治理责任如何在团队里重新分配

虚拟线程带来的另一个深层变化，是治理责任从少数“并发框架专家”重新分配到更广泛的业务开发者、平台团队和架构评审流程。过去，当团队决定使用 Reactor、WebFlux 或高度异步的执行模型时，所有人都会默认这是一个需要专门知识和严格设计的区域，因为代码形态本身就明显不同。Loom 让代码重新看起来像“普通同步逻辑”，这会产生一种危险舒适感：业务工程师觉得自己只是写了几个顺序调用，平台团队以为没有引入新框架就不需要新规则，架构师也可能低估执行模型切换带来的容量后果。

正确的组织应对，不是限制大家使用 Loom，而是让责任边界同步更新。业务团队要对请求级 fan-out、幂等、降级和 deadline 负责；平台团队要提供可复用的 budget 组件、统一的 timeout 约定、连接池监控模板、JFR 采集约定和回滚开关；架构评审要增加“下游预算是否显式”“取消是否贯通”“虚拟线程是否掩盖了 CPU 或队列问题”“是否存在无价值工作放大”等新问题；值班和 SRE 团队则要把观察重点从旧式线程池迁移到资源等待与依赖健康上。

从长期看，Loom 最理想的组织结果，不是“所有人都会创建虚拟线程”，而是“所有人都知道 direct-style 并不意味着不需要预算”。如果团队文化还停留在“只要同步代码写起来简单，就是更安全”，那么 Loom 会降低表面复杂度，却提高系统性风险。反过来，如果团队能借 Loom 把并发治理写成更明确的接口、规范、指标和评审问题，那么 Java 的并发设计会比过去更透明，也更容易跨团队协作。

2. 并发模型转向：从 platform thread 和 reactive 到 virtual thread 的边界重划

2.1 platform thread 模型为什么在 I/O 密集服务中越来越昂贵

Java 在 Loom 之前并不是没有高并发方案。平台线程、线程池、CompletableFuture、反应式管线、Netty event loop、Actor 风格封装，这些都试图解决一个共同问题：如何在 CPU 核数有限、阻塞 I/O 普遍存在、业务逻辑又必须并发推进的前提下，让系统既能撑住流量，又不至于把代码变成无法维护的回调迷宫。Loom 的意义，不是宣告这些方案全部过时，而是重新划定它们各自的适用边界。

平台线程模式的优点在于语义直观。一个请求占一个线程，调用栈清晰，阻塞语义天然与开发者直觉一致，调试、profiling、异常栈和线程 dump 也都容易理解。它的问题在于，线程成本与等待时长强绑定。请求如果在数据库上等 100 毫秒，这 100 毫秒里一个平台线程和其 OS 线程就被长期占住。对于 I/O 密集、等待长、CPU 轻的服务，这是一种高昂浪费。线程池是平台线程模式下的折中：通过复用固定数量的平台线程减少创建成本，并用队列吸收瞬时波峰。但线程池也天然把两件事绑在一起了：执行资源和流量治理。你很难仅仅为了控制数据库并发把整个 Web 线程池降得很小，也很难仅仅为了接住入口流量把线程池无限放大。

2.2 CompletableFuture 改善了等待成本，却提高了控制流复杂度

CompletableFuture 和基于异步回调的设计试图把“等待”从平台线程中抽走，让线程只在真正执行计算时占用。这能显著提高 I/O 并发效率，但代价是业务控制流被拆散。线性的失败路径变成链式异常恢复，上下文传播和取消传播需要额外设计，日志、MDC、事务语义和调试体验都会变得更复杂。对于简单 fan-out 或单个远程调用，CompletableFuture 仍然是不错的工具；但当业务跨越多个异步阶段、多个 fallback 和多个重试策略时，代码可理解性会迅速下降。

这类复杂度并不是“团队再熟练一点就没事”，而是控制流表达方式本身在增加理解负担。很多企业代码的真正难点不是并发本身，而是异常路径多、调用链长、运维要求高。此时 direct-style 的回归会直接降低维护成本。

2.3 reactive 的价值在流语义和背压，而不是“更现代”

反应式模型进一步把并发语义系统化。它适合两类场景：一类是必须以流处理和背压为一等公民的系统，例如持续事件流、消息管线、长连接推送、无限数据集处理；另一类是团队已经深度投资于 Reactor/Netty 生态，并建立了完整的可观测性、调试和运维能力。反应式并不是“复杂但先进”的标签，而是一套与 direct-style 编程不同的系统设计语言。如果系统的核心问题本来就是流式处理和跨边界背压，那么 Loom 不会让这些问题消失；反之，如果系统主要是传统请求/响应型 I/O 聚合服务，反应式的额外认知成本就未必值得。

2.4 virtual thread 更适合做 direct-style I/O 编排层

虚拟线程把边界重新划成了下面这个更实用的版本。第一类，阻塞式请求/响应服务，如果主要做数据库、缓存、HTTP、文件、队列等 I/O 等待，且希望保留清晰同步代码，那么虚拟线程通常是默认优先项。第二类，CPU 密集型任务，例如压缩、图像处理、加密、规则计算、批量序列化或复杂本地推理，虚拟线程不会让 CPU 变多，仍然应交给受控的平台线程池或并行计算模型。第三类，流式和背压主导的系统，例如事件驱动管线、WebSocket 广播、长时间窗口聚合、无限数据流处理，反应式模型可能仍然更贴近问题本身。第四类，混合系统，入口请求可以采用虚拟线程，底层消息处理或局部流式阶段仍可保持 event-driven 或 reactive。

这意味着并发模型不再是全局二选一，而是可以按边界切分。一个支付服务完全可以入口层使用虚拟线程处理同步 HTTP 请求、在调用两个下游评分服务时使用结构化并发进行 fan-out、在 CPU 密集的风控模型打分阶段切换到有界平台线程池、在实时风控事件流上继续保留 Kafka/Reactive pipeline。这种切分的关键不在 API 兼容，而在你是否明确知道每一段边界真正治理的资源是什么。

2.5 架构评审的问题也必须改写

从架构评审角度，最需要被修正的旧问题是：“我们要不要把系统全量改成 reactive，才能扛高并发？”Loom 之后，问题应该改写成：“我们的瓶颈主要是等待成本、流处理语义还是 CPU 并行？如果是等待成本，能否用虚拟线程恢复同步代码可维护性；如果是流语义，就不要为了追新而放弃 reactive；如果是 CPU 并行，就不要用虚拟线程掩盖真正的核心数限制。”这个改写看似语义细微，实则决定了项目是否会在错误抽象上投入几个月甚至更久。

还有一个经常被忽略的组织问题：并发模型的选择会改变谁对故障负责。平台线程时代，线程池爆满通常是平台、网关或容器层很容易观察到的信号；反应式时代，背压和 event loop 饱和往往由框架专家来兜底；虚拟线程时代，很多并发故障会转化为“业务看起来是同步调用，只是下游慢了、池子满了、超时多了”。这要求业务团队自己承担更多资源治理责任，而不是把所有复杂度都留给底层框架。Loom 让 direct-style 更易用，也因此要求团队把 direct-style 里的资源边界写得更清楚。

2.6 混合模型比“全面拥抱某一种模型”更符合现实

很多技术讨论喜欢把并发模型做成宗教式二选一：要么“全部 reactive”，要么“全部线程池”，要么“现在开始全部 Loom”。真实企业系统很少按这种纯粹形态存在。一个成熟平台往往同时包含请求/响应接口、批处理作业、事件流处理、定时任务、后台补偿、实时通知、报表生成和第三方集成。它们面对的资源瓶颈与失败语义并不相同，因此最合理的并发模型也不应该强行统一。

Loom 真正带来的好处，恰恰是允许系统在需要的边界上恢复 direct-style，而不是强迫整个组织重新选边站。一个团队完全可以在入口聚合服务里用虚拟线程简化编排逻辑，在跨租户大批量导出时用有界平台线程池保护 CPU 与堆，在高吞吐事件处理链路上保持 Reactor 或消息驱动模型，在极端延迟敏感组件上继续使用更专门化的并发实现。只要每一段边界背后的资源约束、观测路径和回滚策略是清楚的，这种混合往往比全栈改写更稳妥。

架构师在这里的职责，不是追求“形式一致”，而是避免“责任不一致”。如果入口层用 Loom，内部库却偷偷假设自己总运行在小规模线程池中，问题迟早会暴露；如果 reactive 管线仍然负责跨边界背压，入口层却把 Loom 误当成能无限接流的理由，同样会出事故。混合模型不是权宜之计，而是现实系统对不同瓶颈和不同语义的合理响应。

2.7 选型问卷应该围绕瓶颈、语义和团队能力

并发模型选型最有效的方法，往往不是先比较 API，而是回答一组更接近架构现实的问题。当前路径的主要时间消耗在 CPU 还是 I/O？是否存在长生命周期流或无限数据流？背压是否需要跨组件、跨线程、跨服务传播？失败是否必须在一个请求内做强一致聚合？团队对现有模型的调试能力和 observability 能力是否成熟？下游预算是否容易被 direct-style 调用隐藏掉？如果这些问题不先回答，模型讨论很容易退化成“谁更先进”的口水战。

Loom 往往在这样一类问题上最占优：业务控制流本身是线性的，但等待非常多，且团队更看重代码可维护性、错误栈可读性和渐进迁移。它不那么适合只追求极端事件流吞吐、极端定制调度或超细粒度异步协议控制的场景。真正成熟的选型，不是把 Loom 说成万能，而是能清楚说出“为什么这个边界用 Loom 比继续使用现有模型更省认知成本，同时不会失去关键治理能力”。

3. 吞吐与容量模型：虚拟线程不能替代容量规划，只是改变了容量的主导瓶颈

3.1 请求的真实瓶颈从来不是“线程数”一个变量

理解虚拟线程最容易出错的地方，在于把“可同时挂起很多任务”误读成“系统吞吐会线性提高”。生产系统吞吐从来不是只由线程模型决定，它是由一串资源闸门共同决定的最小值。虚拟线程把线程栈和平台线程调度从这串闸门里往后移了，但不会移除数据库连接数、HTTP 连接数、消息消费并发、磁盘吞吐、CPU 核数、第三方 API 配额、缓存热点和 GC 预算这些更靠后的限制。

因此，讨论 Loom 的容量模型时，第一步不是问“能创建多少虚拟线程”，而是问“一个请求完整占用了哪些资源，它们的上限分别是多少”。例如一个典型的聚合型接口，会解析请求、查用户表、查订单表、访问缓存、调用推荐服务、调用风控服务、做少量业务计算，然后返回结果。这里真正控制系统可承载并发的，很可能是数据库连接池 64、推荐服务并发配额 120、风控服务并发配额 80、网关到下游的 HTTP 连接池大小、以及服务本机可用 CPU。平台线程模型下，这些限制有时被线程池粗暴掩盖了；虚拟线程把掩盖层拿掉后，你就必须显式把这些预算写出来。

3.2 等待时间与执行时间必须分开建模

一个更可靠的吞吐视角，是把请求分成“等待时间”和“执行时间”。虚拟线程主要优化等待阶段的承载成本，因此最适合等待长、CPU 轻的工作负载。比如一个接口平均 CPU 真正工作只有 5 毫秒，但要等待 80 毫秒数据库和 40 毫秒远程 API，这种场景下平台线程会把大量资源浪费在等待上，而虚拟线程能显著提高单位平台线程可承载的 in-flight 请求数。相反，如果一个任务本身就是 200 毫秒纯 CPU 计算，无论用多少虚拟线程，它们最终都要争抢同样的核心，吞吐不会凭空增加，反而可能因为调度开销和共享缓存竞争而更差。

在容量讨论里，把等待与执行拆开还有一个实际好处：你更容易知道该去优化哪里。如果等待占主要部分，重点应放在下游 budget、排队策略、超时和取消，而不是想着靠 CPU 扩容救火；如果执行占主要部分，平台线程池、任务分片、SIMD、JIT 优化、批处理策略才更相关。虚拟线程不会把后一类问题自动变成前一类。

3.3 入口并发和下游并发不是同一个数字

容量模型还必须区分“入口并发”和“下游并发”。入口并发是同时进入服务的请求数；下游并发是这些请求在某一时刻实际压在数据库、HTTP 客户端、缓存或者消息系统上的任务数。虚拟线程让入口并发提升得更容易，因为接受一个请求不再需要预占一个昂贵的平台线程；但如果不控制每个请求内部的 fan-out，下游并发会放大得更厉害。例如一个用户请求同时访问 5 个远程服务，入口 2000 QPS 不代表下游就是 2000 并发，而可能是几个关键依赖瞬时面对 10000 级别的竞争。这个放大效应在 Loom 之前就存在，只是常被线程池容量提前压制；Loom 之后，如果业务层不做预算，放大更容易穿透到深处。

3.4 请求级 fan-out 上限需要被写成规则

一个成熟的 Loom 容量模型，至少要包含以下几个维度。第一，请求级 fan-out 上限：一个请求最多同时开启多少个下游任务。第二，依赖级并发预算：数据库、缓存、HTTP、消息、文件系统、第三方 API 各自允许多少并发访问。第三，排队策略：预算不足时是立即失败、短暂等待、返回降级结果，还是切换缓存。第四，超时组合：每个调用自己的超时是多少，总请求 deadline 是多少，重试是否受总 budget 约束。第五，取消传播：父请求无价值后，下游是否继续白跑。第六，错误预算：允许多少超时、重试、fallback，而不会把系统拖入自我放大。

这个模型的关键不是“把每个参数都定死”，而是让每个预算都能被审核、被观察、被回顾。只要 fan-out 上限仍然是隐含在代码结构里的，而不是被团队显式知道的规则，那么 Loom 迁移后的风险就还没有真正被治理。

3.5 Little’s Law 仍然适用，但变量语义改变了

很多团队习惯用 Little’s Law 或简单的“并发数 = 吞吐 × 响应时间”来做粗估，这在 Loom 时代仍然成立，但要正确理解变量含义。并发数不是“线程数”，而是“同时在系统内占用资源的 in-flight 工作单元”；响应时间也不能只看平均值，而要重点看尾部，因为下游排队和资源争用几乎总是先反映在 p95/p99，而不是平均值。虚拟线程往往会让系统在低负载到中负载区间更平滑，因为不会被平台线程池太早限制住；但如果没有下游预算，系统一旦跨过某个点，尾延迟会比过去更快爆炸，因为更多请求已经被接纳并深入到了依赖层。

3.6 指标必须从线程转向资源等待

还要注意，虚拟线程会改变你观察系统的方法。以前你可能盯着“active thread 数”“线程池队列长度”“拒绝数”判断是否过载；现在这些指标的重要性下降了，必须把视线转移到“连接池等待时长”“HTTP 客户端连接租借等待”“数据库响应时间分布”“远程 API 超时率”“per-request fan-out 数量”“carrier 线程 CPU 利用率”“虚拟线程创建速率”“取消成功率”“入口和下游并发比值”。换句话说，Loom 不是让你少看指标，而是要求你看更靠近真实瓶颈的指标。

最稳妥的结论是：虚拟线程会把系统的第一瓶颈从线程切换到更真实的资源位置。这个转移本身是好事，因为它逼迫你面对系统真实容量，而不是让线程模型替你做一个粗糙但不透明的限制。但好事只在一个前提下成立：你的容量规划、压测设计、报警阈值和降级策略已经准备好接受这个新的瓶颈位置。否则，虚拟线程只是把问题从 JVM 内部搬到下游边界，让事故更晚、更深、更难解释。

3.7 用三层预算写出你的容量方程

很多团队说自己“做了容量规划”，其实只是记录了压测时的大致 QPS 和平均延迟。Loom 时代更需要把容量方程写成可讨论的三层结构。第一层是入口层：单位时间愿意接受多少请求、每个租户或每类操作的峰值配额是多少、在达到阈值时是排队、限速还是拒绝。第二层是请求内并发层：一个请求允许启动多少并发子任务，其中哪些是必需调用，哪些是可选调用，哪些是 fallback 路径，哪些是冗余竞速。第三层是依赖层：每个依赖允许多少同时活跃操作、每次操作的最大等待时间、重试和回退是否会继续消耗预算。只有三层预算一起写出来，系统才真正知道“流量增加一倍时，先触发的保护机制是什么”。

这种方程不要求极端精确，但必须足够真实。例如一个用户首页请求，如果最多并行访问两个数据库查询、一个缓存查询、两个远程服务调用，那么它的下游成本不是“一个请求”，而是“一组预算占用模式”。如果缓存 miss 后会回源数据库，或者远程服务失败后会切本地降级逻辑，这些路径都应该进入方程。Loom 让你更容易以同步代码表达这些流程，也因此更需要把它们在预算层面说清楚。

把容量写成方程还有一个文化收益：它迫使团队从“我们大概能扛住”转向“我们知道在哪些条件下会先拒绝、先超时、先降级”。这比单纯的吞吐数字更有生产价值，因为真正稳定的系统不是永远不失败，而是在预算被打满时仍然以可解释、可控、可回滚的方式失败。

3.8 压测、灰度和生产观察应该验证什么

Loom 引入后，压测目标也应该改变。过去很多压测只是为了看线程池顶不顶得住、CPU 会不会打满、内存会不会 OOM。现在这些仍然重要，但还不够。更关键的是验证入口并发增长时，连接池等待是否先于错误率恶化、是否存在某类请求异常放大 fan-out、取消传播是否真的减少了无价值调用、downstream budget 用尽时系统是否快速失败而不是深层排队、carrier 线程是否存在异常占用、retry 是否在高峰时放大了流量风暴。

灰度发布阶段则要特别注意“指标表面正常，但预算位置迁移”的情况。很多团队只看错误率和平均延迟，以为一切正常；实际上，数据库借连接等待或 HTTP 客户端连接获取等待可能已经显著增加，只是尚未外溢为用户可见错误。Loom 迁移后的灰度应重点观察这些更接近真实瓶颈的位置，而不是满足于“页面还能打开”“接口还能返回”。如果你只看最终结果，往往会错过最关键的预警窗口。

生产观察还应带时间维度。某些 Loom 问题不会在一分钟压测里显现，却会在高峰持续半小时后暴露，比如连接池持续抖动、无价值工作累计、下游缓存抖动后的回源放大、第三方限流与本地重试耦合等。一个成熟的验证计划不应只包含“瞬时峰值能否通过”，还要包含“长时间高峰是否产生预算漂移和排队外移”。

3.9 容量假设应该进入 ADR 和 runbook，而不是只留在旧压测报告里

Loom 迁移最容易遗失的资产，是容量假设本身。压测报告会记录某次环境下的 QPS、延迟和错误率，但如果没有把入口预算、下游预算、fan-out 上限、deadline、retry 策略和回滚信号写进 ADR 与 runbook，几个月后团队就只剩下一组失去上下文的曲线。到那时，新的依赖、新的租户、新的流量形态或新的 JDK 版本都可能让旧结论失效，而维护者却不知道当初结论依赖哪些前提。

因此，容量假设必须被当成生产契约维护。ADR 负责解释为什么选择 Loom、哪些隐式挡板被移除、哪些预算被显式化；runbook 负责说明当这些预算被打穿时先看什么、先保护谁、先回滚哪条路径。这样一来，压测不再是一次性证明材料，而会变成后续灰度、事故复盘和平台模板演进的共同语言。

4. 资源池与背压：为什么虚拟线程不能绕过连接池、限流器和 timeout

4.1 连接池不是历史包袱，而是真实容量闸门

资源池在 Loom 时代的重要性不是下降，而是上升。过去很多人把连接池、线程池和队列混在一起理解，仿佛它们都只是“限制并发”的工具。虚拟线程出现后，这种混淆必须被拆开。线程池在平台线程时代兼有执行资源复用和并发控制两种角色；虚拟线程把执行资源复用的重要性降低了，于是并发控制就需要回到真正对应资源的位置：数据库连接池保护数据库、HTTP 连接池保护远程服务连接、缓存客户端池保护缓存通道、消息消费者并发保护 broker 和业务幂等、限流器保护全链路预算、bulkhead 保护故障隔离、queue 保护短时突发吸收，timeout 保护无价值等待不被无限延长。

很多 Loom 试点项目失败，并不是虚拟线程本身有问题，而是团队下意识删掉了原本所有“看上去是为了线程池存在”的边界。比如把入口线程池换成 newVirtualThreadPerTaskExecutor() 之后，就把数据库访问改成“随便查”，认为平台线程不再是瓶颈；把 HTTP 客户端改成同步调用之后，就不再关心连接池和远端配额；把多个服务 fan-out 改得更容易写之后，也忘记限制每个请求最多能并发访问多少下游。这会迅速制造一种危险错觉：应用层吞吐似乎提升了，实际只是把排队和拥塞移动到了更昂贵的地方。

4.2 背压在 Loom 时代只是从协议层回到治理层

正确的做法，是把每类资源池视为“真实世界的闸门”，而不是“为了适配旧线程模型的历史遗物”。数据库连接池就是数据库真实并发能力的本地投影。它的大小不仅决定数据库端会面对多少同时活跃事务，也决定应用端在连接紧张时会如何排队。如果你把虚拟线程与 JDBC 一起使用，却不对连接池等待时间做监控，不对查询超时做限制，不对连接借用失败做降级，那么你只是在用更容易写的同步代码更猛烈地压榨同一个数据库。类似地，HTTP 客户端连接池不是“异步时代才需要”的概念，它是服务之间并发预算的核心表达；cache 客户端的并发限制和命令 timeout 也一样。

背压在 Loom 时代经常被误解为“既然用同步代码了，就不用像 reactive 那样谈背压”。实际上，背压不是 Reactor 专属概念，而是系统对过量需求的反馈机制。只要某个资源无法无限扩容，就需要背压。区别只是表现形式不同：在反应式流里，背压可以体现在 request(n) 这样的协议；在 Loom 风格的同步代码里，背压更常体现为 semaphore、bulkhead、有限队列、连接池借用超时、限流器、快速失败、降级和 deadline。它们都是在告诉上游：下游现在只能接受这么多，不要再无限涌入。

4.3 预算应该分成入口、服务内和依赖三层

一个成熟的虚拟线程系统，通常会把资源预算拆成三个层次。第一层是入口预算，例如 API 网关限流、租户配额、用户级速率限制、消息消费并发限制，这一层决定系统愿意接受多少工作。第二层是服务内部预算，例如每个请求最多允许并发多少个子任务，某类远程服务最多同时进行多少调用，某类数据库操作最多允许多少 in-flight 事务。第三层是依赖预算，例如连接池大小、客户端 timeout、服务级熔断阈值、重试预算。只有三层一起存在，虚拟线程带来的 direct-style 优势才不会转化成“更容易把所有边界绕开”。

4.4 预算耗尽时必须有统一失败语义

下游保护还必须与失败策略一起设计。连接池耗尽时应该等待多久？是 20 毫秒就失败还是允许等 200 毫秒？第三方 API 预算耗尽时，是返回缓存结果、降级结果，还是直接拒绝？如果父请求已经接近 deadline，下游 budget 即使还有余量，也不应继续发起新调用，因为这些结果大概率已经对用户无价值。虚拟线程使得同步代码组织这些逻辑更自然，但不减少任何决策本身的复杂性。

4.5 最危险的模式是“无限接收，深层等待”

背压设计中最危险的反模式，是只保留“无限接收 + 深层等待”的路径。也就是说，入口来一个请求就启动一个虚拟线程，虚拟线程再无条件尝试借连接、发请求、重试、等待，直到某处超时。表面上看，这种实现几乎没有编码摩擦；实际上，它把所有过载都留给最深层的依赖处理，用户会看到整体响应时间持续变差，监控系统会看到超时级联、连接池等待飙升、下游错误放大，而入口层却看不出明显拒绝。相比之下，一个明确的限流或快速失败策略虽然在表面吞吐上更“保守”，但常常能把整体 SLA 和下游安全保住。

所以，虚拟线程时代的工程纪律应该是：谁拥有资源，谁定义预算；谁会被打穿，谁拥有背压权；谁最接近用户价值判断，谁决定在预算不足时该失败、降级还是等待。不要把这些责任重新寄希望于“线程模型会替我们挡住一点”。Loom 的出现，恰恰意味着这种隐式挡板正在失效，而你必须把真正的资源池和背压策略前置为显式设计。

4.6 数据库、缓存、HTTP 和消息系统的预算写法并不相同

虽然都叫“资源预算”，不同依赖的治理方式并不一样。数据库更关心连接数、事务持续时间、锁竞争和慢查询；缓存更关心热键、命令超时、回源放大和客户端复用；HTTP 或 RPC 下游更关心连接获取、握手成本、租户配额、限流响应与重试幂等；消息系统则更关心消费者并发、ack 时机、重试队列和死信策略。Loom 不会把这些差异抹平，反而因为 direct-style 调用更顺手，要求你更清楚地区分它们。

如果把所有依赖都用同一个“线程池大小”来粗暴代理，问题很快会变得不可解释。数据库连接耗尽和第三方 API 被限流，看起来都像“调用变慢”，但处理方式完全不同。前者可能需要减 fan-out、收紧查询超时、优化 SQL 或降低入口 admission；后者可能需要限流、预算分级、缓存、租户隔离和按价值降级。生产决策必须建立这种差异化预算意识，而不是把一切都归结为“控制并发即可”。

4.7 timeout、retry 和 queue 的组合经常决定事故会不会被放大

另一个经常被低估的问题，是 timeout、retry 和 queue 的组合关系。很多系统在 Loom 迁移前后都分别有这些机制，但没有把它们当成一组互相作用的预算。举例来说，如果连接池借用 timeout 很长，请求总 deadline 又很松，那么入口会持续接纳大量虚拟线程深入排队；如果重试策略不受总 deadline 约束，下游一抖动就会把本来有限的问题放大成更大流量洪峰；如果 queue 没有按请求价值分层，高优先级请求会和低价值批量任务一起在深层等待。

在 Loom 时代，这种组合的后果往往比过去更明显，因为平台线程不再先行卡住入口。也就是说，你更必须把 timeout、retry 和 queue 看成一个统一系统，而不是三个各自独立的中间件参数。谁先超时、谁能重试、谁可以等待、谁必须立即失败，这些规则如果没有统一设计，就会在高峰时相互打架。

4.8 预算拒绝应该带业务价值判断，而不是只按技术队列先后

当预算耗尽时，系统不能只按“谁先来谁等待”处理。生产服务里的请求价值通常不同：用户主动操作、后台刷新、推荐预取、运营批量任务、低优先级报表和可延迟同步，对业务的即时价值并不相同。如果所有请求在虚拟线程里都能轻松等待，系统反而更容易把低价值工作和高价值工作一起拖进深层依赖，最后让真正重要的请求也被连带伤害。

因此，预算拒绝应该具备业务价值语义。入口限流可以按租户、用户动作和接口类型区分；请求内 fan-out 可以优先取消非关键子任务；fallback 可以优先保护主路径；批处理可以在在线预算紧张时主动让路。这些设计与 Loom API 本身无关，却决定了 Loom 是否能在企业系统中安全扩大 direct-style 的使用范围。

5. Pinning 与版本边界：carrier thread 为什么会被拖住，以及哪些说法已经过时

5.1 pinning 的本质是“等待时不能释放 carrier”

pinning 是虚拟线程进入生产后最容易被过度简化的话题之一。很多材料会把它概括成一句话：“在 synchronized 里阻塞就会把 carrier thread 钉住。”这句话在某些 JDK 版本和某些场景下是一个有用警告，但作为长期稳定结论已经不够准确。真正需要建立的是更精确的判断：pinning 发生在虚拟线程无法在期望的阻塞点安全卸载时，导致 carrier platform thread 被长期占住；其影响不是“程序马上错误”，而是调度效率退化、carrier 利用率下降、可承载等待任务数减少，严重时把 Loom 的收益吃掉。

理解 pinning 先要明确 carrier thread 的角色。虚拟线程不是魔法实体，它运行时仍然需要平台线程真正执行字节码。carrier 就是这个执行载体。理想情况下，虚拟线程只在需要运行少量 CPU 或推进少量逻辑时挂载到 carrier 上，一旦遇到可被 Loom 感知并处理的阻塞点，就把自己的 continuation 挂起，释放 carrier 去运行别的虚拟线程。pinning 破坏的，就是这条“等待时释放 carrier”的路径。

5.2 synchronized 的风险要按 JDK 版本讲，不要写成永恒禁令

在 JDK 21 到 23 的语境里，synchronized 内部的某些阻塞场景确实是最典型的 pinning 来源之一。因为 monitor 相关状态使虚拟线程难以像普通可卸载阻塞那样安全迁移，导致 carrier 无法被释放。JDK 24 之后，这个领域已有重要改进，尤其是围绕“虚拟线程在 synchronized 相关阻塞中释放 carrier”的能力发生了变化。因此，今天再写“所有 synchronized 都应该替换成 ReentrantLock 才能用 Loom”，已经属于过度甚至错误建议。正确做法是结合目标 JDK 版本、实际阻塞位置和 contention 模式来判断。

这并不意味着 synchronized 从此无须关注。首先，即使 monitor pinning 的主要路径在新版本中有所改善，长临界区本身仍然会限制并发，因为共享资源在逻辑上就只能有一个执行者。其次，很多系统真正危险的不是“用了 synchronized”，而是“在临界区里做远程调用、磁盘 I/O、大对象序列化、慢 SQL 或复杂业务等待”。这种设计即便不发生旧式 pinning，也依然会让共享资源和 carrier 一起被低效占用。第三，团队如果同时维护 JDK 21、22、23 与更高版本服务，就必须明确版本边界，不能把某个新版本的行为改善回填成所有环境的默认前提。

5.3 native、foreign call 和黑盒驱动仍然要重点验证

除了 monitor，native 和 foreign 调用也是 pinning 与 carrier 利用率治理的关键边界。虚拟线程对标准 JDK 阻塞原语的感知是渐进完善的，但对 JNI、某些本地库、某些外部驱动、某些 foreign call 场景，JVM 未必总能像处理普通 Socket 阻塞那样优雅卸载。这意味着，只要应用依赖本地压缩、图像处理、老式驱动、加密模块、FFM/native 互操作，或者任何包含潜在长阻塞 native 路径的库，都必须通过 JFR、压测和 targeted profiling 观察实际表现，而不是只凭“虚拟线程支持阻塞调用”这一宏观印象做判断。

5.4 修 pinning 之前先问：这是编码问题还是边界问题

生产治理上的正确姿势不是“见到 pinning 就恐慌”，而是给它建立一个诊断优先级。第一优先级，确认是否存在 carrier 明显被长时间占用、吞吐与等待任务数不匹配、池等待和 CPU 利用异常的症状。第二优先级，定位这些症状与哪些锁、哪些调用栈、哪些 native 路径、哪些版本相关。第三优先级，判断是必须重构，还是仅需缩短临界区、调整调用位置、升级 JDK 或替换局部依赖。大多数系统并不需要为了 Loom 全量清洗所有 synchronized，但必须知道哪里仍然会把 carrier 拖住，哪里只是普通锁竞争，哪里只是业务逻辑过长。

还有一个常见误区是，把 pinning 当成纯粹的局部编码问题。实际上，它往往是架构边界问题的症状。如果一个临界区里必须执行远程调用，通常说明共享状态与外部等待被放在了同一个边界内；如果一个请求要在持锁期间完成多个依赖访问，通常说明状态机设计不清；如果本地/native 路径承担了过多不可观测的等待，说明系统关键依赖没有被当作容量边界治理。因此，pinning 的修复不总是“把锁换成别的锁”，更常见的是重划任务生命周期和共享状态边界。

5.5 关于 pinning 的表述必须带版本、场景和结论三重限定

最后必须强调版本边界写法。对于 Loom 采用建议，凡是涉及 pinning 的断言，都至少要标注三个条件：适用 JDK 范围、适用阻塞类型、适用观察结论。比如“在 JDK 21 到 23 中，某些 synchronized 内阻塞等待会显著影响虚拟线程释放 carrier 的能力，因此应对持锁远程调用进行重点诊断”；这比“synchronized 会 pin，所以要全部换成 ReentrantLock”更加准确，也更符合生产决策应有的保守表达。

5.6 创建虚拟线程的最小示例

下面这段代码只服务一个读者任务：让读者看到虚拟线程的创建 API 与平台线程足够接近，因此迁移门槛低。原因是很多团队误以为 Loom 需要完全不同的编程接口，实际最重要的变化不在创建动作，而在后续资源治理。观察点是 isVirtual()、任务提交方式与 ExecutorService 兼容性。生产边界是：这个示例只证明 API 兼容，不证明系统可以无上限接纳请求，也不证明下游容量被自动放大。

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    Future<String> result = executor.submit(() -> {
        if (!Thread.currentThread().isVirtual()) {
            throw new IllegalStateException("expected a virtual thread");
        }
        return "handled by " + Thread.currentThread();
    });

    System.out.println(result.get());
}

5.7 诊断 pinning 的 runbook 应先从症状开始

实际排查 pinning 时，最重要的是不要见到“虚拟线程性能不如预期”就立刻假设根因一定是 pinning。更好的 runbook 是从症状倒推。先看吞吐与 in-flight 任务数是否明显不匹配；再看 carrier 相关 CPU 样本与等待分布是否异常；再查线程 dump 和 JFR 是否出现大量集中在同一锁、同一 native 路径或同一持锁调用链上的等待；最后才决定是否需要针对 monitor、JNI、FFM 或第三方库做更细检查。这个顺序能避免团队把所有慢问题都误判为 Loom 特性缺陷。

runbook 之所以重要，是因为 pinning 很少独立出现。它经常与长事务、锁设计粗糙、共享状态过大、驱动黑盒行为或 deadline 设计缺失一起出现。如果只把注意力放在“哪个 API 导致不能卸载”，就会错过更本质的架构根因。一个好的排查流程应该同时问：为什么会在持锁状态下做这件事、为什么这个本地调用没有更明确的隔离边界、为什么这个请求即便已经失去价值还在等待。

5.8 修复优先级通常是升级、缩短临界区、重构边界，而不是全量替换锁

当确实确认存在 pinning 或 carrier 被低效占用时，修复优先级也应有层次。第一层是版本升级与行为验证。如果问题主要出现在旧 JDK 版本已改进的路径上，升级并补充验证常比大规模重构更划算。第二层是缩短临界区或调整阻塞位置，把远程调用、磁盘 I/O、大对象处理从共享状态保护范围中移出。第三层是更彻底的边界重构，例如把状态机拆分成可并发阶段、引入更细粒度锁、改用消息串行化某些热点操作。只有在这些路径都不合适时，才考虑广泛替换同步原语。

这种优先级的意义在于控制总风险。很多 Loom 相关问题如果处理过猛，修复本身的风险会超过原问题。生产系统不是学术基准，它要同时考虑兼容性、发布窗口、回归成本和组织理解成本。架构师的职责不是“把并发理论做到最纯”，而是找到最小可验证改动，把真正高风险路径压下来。

6. 结构化并发：把请求内 fan-out 变成有所有权、可取消、可聚合的任务树

6.1 没有结构化并发，虚拟线程只会让“任务乱飞”更便宜

虚拟线程让“一个请求里并发做几件事”重新变得非常自然。你不再必须为了多个远程调用写嵌套 CompletableFuture，也不必为了 direct-style 牺牲并发性。这种便利如果没有结构化并发配套，会快速演变成另一类混乱：任务创建容易了，但谁负责取消、谁负责等待、谁负责失败聚合、谁负责超时传播、谁负责记录上下文，反而变得含混。结构化并发解决的不是“如何并发执行”，而是“这些并发任务的生命周期属于谁”。

6.2 scope 的价值在 owner、deadline 和 failure policy

从生产系统角度，结构化并发最有价值的地方在于把一个请求内部的任务树显式化。比如一个“加载用户首页”的请求，需要查用户资料、最近订单、营销推荐和风险提示。它们彼此独立，完全适合并发 fan-out。问题在于：如果“风险提示”服务超时了，营销推荐还要不要继续跑？如果父请求在 800 毫秒 deadline 后已经不可能再返回成功结果，后台查订单的任务是否还应该继续占用数据库连接？如果用户资料失败了，组合结果已经无意义，其他任务是否应立即取消？传统无结构方案当然也能做这些事，但往往需要大量手动样板和纪律，而纪律一松就会变成任务泄漏或无意义等待。

结构化并发把这些决策收拢到 scope。scope 的存在提醒读者：并发不是把事情扔给 executor 就结束，而是要给任务树定义统一的 owner、deadline 和 failure policy。这个思路与微服务中的“一个上游请求对应一个请求上下文”完全一致，只是现在扩展到了进程内并发层面。对于大量聚合型接口、并行校验、双写比对、竞速查询、冗余副本读取、并行 fallback 准备等场景，它都能提供比裸 Future 或裸 CompletableFuture 更清晰的生命周期边界。

6.3 结构化并发不等于必须所有子任务全成功

在文章里谈结构化并发，还必须讲清它与虚拟线程的关系。两者不是强绑定。虚拟线程解决的是轻量级等待和 direct-style 编码；结构化并发解决的是任务所有权和生命周期治理。理论上你可以只用虚拟线程不用结构化并发，但那样很容易重新走回“任务能起很多，但不知道谁来收尸”的老路。反过来，你也可以在别的并发模型里实践结构化思想，但 Loom 让这件事在 Java 里变得更顺手，因此生产上更值得认真推动。

很多团队在引入结构化并发时，最需要被修正的误解是“它只是另一个并发 API”。不，它更像一种请求内资源治理纪律。只要一个父任务发起了多个子任务，就应该回答：子任务在什么条件下必须全部成功、什么条件下一个成功即可、什么条件下允许部分失败、什么条件下必须统一取消、什么条件下应该继承统一 deadline、什么条件下必须把错误信息带回父请求日志和 tracing 上下文。结构化并发帮助你表达这些规则，但不会替你发明规则。

6.4 它会直接改善可解释性和资源回收

从运维视角看，结构化并发还有两个附加价值。第一，它改善了可解释性。任务树清晰后，日志、trace span、错误聚合和请求超时更容易归因。第二，它改善了资源回收。无价值的子任务更容易被及时取消，从而减少“用户已经走了、下游还在忙”的浪费。在 Loom 时代，这是很关键的，因为 cheap waiting 会让人更愿意开很多并行子任务，如果没有取消传播，浪费会比过去更大。

6.5 结构化并发的概念性示例

下面示例的场景是请求内的双下游聚合：读取用户信息和订单信息，并在任一失败时整体失败。原因是这种 fan-out 是虚拟线程在生产服务中最典型的受益点。观察点是 scope 的 join、失败聚合和统一生命周期，而不是 preview API 的细节名称。生产边界是：结构化并发在本文撰写时仍处于 preview 线，具体类名、方法名和编译参数需要按目标 JDK 校验，不应把示例当成无条件稳定 API。

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    var userTask = scope.fork(() -> userClient.fetch(userId));
    var orderTask = scope.fork(() -> orderClient.fetchRecent(userId));

    scope.join();
    scope.throwIfFailed();

    return new AccountView(userTask.get(), orderTask.get());
}

结构化并发真正要传达给团队的，不是“scope.fork 的写法挺优雅”，而是请求内并发也要像数据库事务、HTTP 超时和消息确认一样，拥有统一的生命周期治理。任何在 Loom 时代变得更容易写的并发 fan-out，都应该配套这层纪律，否则只是把编程成本省下来，却把运行风险放大。

6.6 deadline 传播和取消传播，决定虚拟线程是否真的省资源

结构化并发如果没有与 deadline 传播结合，收益会打折。许多系统会给入口请求配置总超时，但子任务各自仍按默认超时运行，甚至发生多个重试，最终导致父请求早已失败，子任务还在后台继续消耗数据库连接和远程配额。Loom 让 direct-style fan-out 更容易写，也让这种浪费更容易被忽视。只有把父请求剩余 budget 传递给所有子任务，并在父作用域结束时取消无价值工作，虚拟线程带来的“等待更便宜”才会真正转化成“资源浪费更少”。

取消传播同样不只是用户体验问题，也是容量问题。某个依赖已经不可能影响最终结果时，越早停止，越能把预算让给真正有价值的请求。结构化并发把这种责任从分散代码中拉回到统一 scope，这是它在生产治理中的核心价值之一。

6.7 “部分失败可接受”必须先设计，不要靠调用端临时 patch

不是所有 fan-out 都要求强一致成功。有些页面允许推荐信息缺失但用户基本资料必须成功，有些后台流程允许审计补充数据延后返回，有些竞速查询允许最先成功者胜出。结构化并发的意义之一，是把这些差异化策略前置设计。否则，团队很容易在不同调用端临时加各种 catch、fallback 和忽略逻辑，最终形成一套无法推导、难以测试、也难以监控的失败语义。

Loom 时代 direct-style 让这种临时 patch 更有诱惑，因为“顺手在这里 try/catch 一下”非常容易。真正成熟的做法，是在任务树层面决定哪些子任务必须成功、哪些可以降级、哪些要在 deadline 到达时统一终止，并把这些策略变成可测规范，而不是零散编码习惯。

7. 可观测与诊断：线程 dump、JFR、metrics、tracing 在 Loom 时代该怎么看

7.1 thread dump 还重要，但看法不能停留在线程数量

虚拟线程进入生产后，可观测性的难点不在“完全没有工具”，而在“旧工具仍可用，但关注点变了”。线程 dump 依然有价值，JFR 依然是核心，metrics 和 tracing 甚至比以前更重要，因为线程数量不再是一个足够接近根因的指标。你不能再仅凭“线程很多”或“线程池快满了”来判断系统是否健康，必须把诊断重心转向资源等待、carrier 占用、下游预算和请求级 fan-out。

先说 thread dump。它在 Loom 时代仍然重要，但它回答的问题变成了：当前有哪些虚拟线程在等待、在等待什么、是否存在大规模集中等待某个依赖、是否存在长时间持锁、是否存在某类请求模式下大量挂起任务积压。过去你可能主要关心固定线程池中的那几百个工作线程；现在你需要学会从更大量的虚拟线程快照中抽象模式，而不是逐个盯着线程名字看。线程 dump 对定位“所有请求都卡在同一个连接池借用”这类问题仍然非常强，但它必须与 metrics 和 JFR 结合，才能知道这种卡顿到底是 transient burst 还是系统性容量错配。

7.2 JFR 的重点是行为证据，而不是单一神奇事件

JFR 在 Loom 时代的价值反而更高，因为它能把“看上去只是同步阻塞”的运行行为拆成可分析事件。通过 JFR，你可以观察线程生命周期、锁竞争、I/O 等待、CPU 栈样本、异常、GC、socket 活动、文件访问以及某些与虚拟线程相关的调度行为。对架构师来说，JFR 最重要的不是某一个特定事件名，而是它能帮助回答下面这些生产问题：carrier 是否真的大部分时间在高效复用，还是被某类长等待拖住；是不是某个连接池借用时间突然成为尾延迟主因；是不是某个 remote call 的 timeout 过长导致无价值任务累积；是不是锁竞争放大了虚拟线程数量带来的调度噪声；是不是 CPU 其实才是主瓶颈，导致 Loom 本身并无明显收益。

7.3 metrics 必须围绕预算而不是围绕线程池

metrics 的设计也要升级。过去 Web 线程池的 active、queue、rejected 三件套在很多团队里几乎就是并发健康度的代名词；现在这些指标不够用了。至少要补上：数据库连接池借用等待时间分布、HTTP 客户端连接获取等待、下游按服务维度的 in-flight 请求数、semaphore/bulkhead 使用率、请求级子任务数量分布、超时总数和按依赖拆分的超时比例、取消请求数与取消成功数、carrier 线程 CPU 占用、虚拟线程创建速率与存活时间分布。如果你的监控仍然只会告诉你“QPS 上去了、线程也很多”，那么 Loom 时代的很多故障会在非常靠后的位置才被看见。

7.4 tracing 要回答“哪些并发工作已经没有用户价值”

tracing 在直连多个下游的聚合型服务里尤其重要。虚拟线程让同步代码里的 fan-out 变得自然，结果是一个请求更容易触发多个并行调用。没有 tracing，你很难知道哪个下游拖慢了整体 deadline，也很难知道一个请求里同时打开了多少子任务。更关键的是，tracing 应该和 cancellation 语义结合起来：父请求超时后，哪些子 span 还在继续；哪些 remote call 虽然最后成功返回，但结果对用户已无价值；哪些 fallback 或重试是“挽救成功率”，哪些只是“浪费下游资源”。这类洞察在 Loom 时代比过去更需要，因为代码变简单后，团队更容易低估 fan-out 带来的放大。

7.5 资源等待优先于线程等待，才是 Loom 时代的排查起点

可观测性的另一个新重点是“资源等待优先于线程等待”。例如一个接口 latency 突然从 120ms 涨到 800ms，平台线程时代你也许第一反应是线程池满了；虚拟线程时代，第一反应应该是：数据库连接借用是否显著等待、HTTP 连接池是否拥塞、第三方 API 是否抖动、retry 是否放大了无效流量、deadline 是否太松、bulkhead 是否失效。线程只是承载等待的容器，真正的根因更可能在等待的对象上。

还有一个被很多文章忽视的问题：虚拟线程会让某些“看起来很健康”的指标失去误导性。比如 CPU 只有 35%，线程数没有异常飙升，容器内存也没打满，你可能以为系统还有余量；但实际上连接池等待已经持续升高，尾延迟在 5 分钟内缓慢恶化，说明系统早已处于“入口还接得住、下游已经过载”的状态。这正是 Loom 时代典型的观测陷阱：应用层表面更从容，依赖层实际更紧张。所以，监控面板必须重新按依赖预算组织，而不是只按 JVM 本机资源组织。

7.6 用 JFR 记录 Loom 相关现象的起点

下面命令的场景是线上或预发环境做短时间证据采集，用于判断是否存在锁竞争、长等待、carrier 占用异常或下游阻塞。原因是很多 Loom 问题只靠静态代码审查不足以证明。观察点是录制窗口、profile 配置与输出文件，而不是追求某一项神奇事件。生产边界是：JFR 适合证据收集，不替代压测设计、依赖预算和业务级指标分析，录制参数也应按环境和时长谨慎设置。

jcmd <pid> JFR.start name=loom-profile settings=profile duration=120s filename=loom-profile.jfr

7.7 排查顺序应该是：先资源、再线程、再代码细节

很多性能故障排查一开始就沉到代码细节里，这在 Loom 时代尤其容易误导。更合理的顺序应当是：先确认哪个资源预算先恶化，例如连接池、HTTP 下游、消息 lag 或 CPU；再判断线程和 carrier 是否只是症状表现，还是已经成为独立瓶颈；最后才去看哪一段代码、哪一个锁、哪一条调用路径在放大问题。这个顺序能帮助团队避免“因为看见虚拟线程多，就以为虚拟线程本身有问题”的认知偏差。

这种排查顺序也更符合事故恢复现实。线上事故的第一目标通常不是找出最优理论解释，而是快速定位最可能的资源闸门，决定是限流、降级、扩容、缩小 fan-out、关闭某类调用还是回滚执行模型。资源优先的思路更容易得出可操作结论。

7.8 监控面板需要按依赖预算重构，而不是按线程层重构

传统面板常按 JVM 资源、线程池、GC、CPU 和错误率来组织。这些指标仍然要保留，但 Loom 服务更需要一类新的“预算视图”：按依赖服务展示连接租借等待、超时比例、in-flight 请求数、retry 次数、fallback 次数、取消次数、budget 拒绝数；按请求类型展示 fan-out 深度、deadline 消耗分布、子任务数量分布和无价值工作比例；按系统层展示 carrier CPU、虚拟线程存活时间分布以及入口与下游并发比值。没有这类视图，团队会继续用旧线程池时代的仪表盘看一个已经换了主瓶颈位置的系统。

更进一步，监控面板还应支持值班时的优先级判断。比如在同一页面上就能看见“入口 QPS 还稳定，但某个下游连接池等待连续上升”“deadline 触发取消数开始增长”“retry 进入高位”“fallback 成功率下降”。这类组合信息比单独看线程数更能反映 Loom 时代的真实健康状况。

7.9 早期预警信号通常是等待和取消失败，而不只是错误率

在很多 Loom 事故里，错误率是比较晚才出现的指标。更早出现的信号往往是等待位置变化：连接池等待变长、第三方 API RTT 轻微上移、request deadline 消耗更快、被取消的子任务仍在占用资源、fallback 路径调用次数增加、同一请求内 fan-out 实际数量高于设计值。如果平台只盯错误率和 CPU，就会错过这些更早的预算信号。

早期预警的目标不是制造更多告警，而是把“系统正在把压力推向更深位置”提前暴露出来。比如入口层看起来没有拒绝，但数据库连接等待已经持续升高；用户侧还没有大量超时，但取消后仍运行的子任务已经增加；平均延迟仍可接受，但 p99 的 queue wait 已经开始抬升。这些信号一旦被看见，团队就能在真正事故前收紧预算、关闭非关键 fan-out 或回滚迁移路径。

7.10 可观测性要覆盖上线前、上线中和上线后三个窗口

Loom 的可观测性不能只在事故中临时打开。上线前要确认 baseline：旧模型下入口并发、下游等待、线程池队列、连接池利用、JFR 事件和 tracing 关联是什么样。上线中要确认变化：同一批请求在虚拟线程路径下等待位置是否迁移，deadline 是否按预期传播，取消是否释放资源。上线后要确认稳态：峰值、低谷、批任务、租户偏斜和依赖抖动是否会产生不同结论。

这三个窗口缺一不可。只有上线前 baseline，没有上线中对照，就无法解释变化；只有上线中指标，没有上线后稳态，就容易被短窗口假安全感误导；只有事故后采证，没有迁移前证据，就很难证明问题是 Loom 引入、依赖变化还是流量变化导致。把可观测性按窗口设计，才能让 Loom 迁移从“看起来没事”变成“证据链完整”。

8. 迁移策略：Servlet、Spring、JDBC、HTTP client、RPC 与批处理如何渐进切换

8.1 迁移先选 I/O 重、边界清、可回滚的路径

Loom 最危险的迁移方式是“因为改起来很容易，所以全量替换”。最安全的迁移方式恰恰相反：只挑那些阻塞等待多、同步代码价值高、依赖边界清楚、回滚路径明确的局部路径先改。换句话说，虚拟线程迁移首先是风险控制工程，而不是语言特性追新工程。

第一类优先迁移对象，是典型的 I/O 聚合型请求路径。例如一个 BFF 或 API 聚合层，需要组合多个下游服务结果，但业务逻辑本身并不复杂。这类路径在平台线程时代常为了线程成本引入复杂异步写法，改用虚拟线程后，既能保留并发 fan-out，又能恢复线性可读的业务控制流，收益往往最大。第二类优先对象，是线程池数量已经很多、排查困难、但大部分线程都在等 I/O 的老式同步服务。第三类优先对象，是批处理或后台任务里大量串行调用下游、整体耗时受等待主导的流程。反过来，纯 CPU 任务、高吞吐流式处理、依赖大量 native/foreign 特性且尚未充分验证的系统，并不应该成为第一批试点。

8.2 迁移前必须做边界盘点，而不是只替换 executor

迁移时最重要的不是 executor 替换，而是“边界盘点”。每条候选路径都要先盘点：当前有多少线程池、每个线程池真实承担什么治理角色、数据库连接池多大、HTTP 客户端连接池多大、重试策略是什么、超时是全局还是分段、一个请求会触发多少下游调用、哪些调用可并行、哪些调用必须串行、哪些失败允许降级、哪些失败必须立即终止。这些信息如果不先梳理，迁移后的 direct-style 代码即便看上去更整洁，也可能只是把隐含约束丢失掉。

8.3 Servlet 和 Spring MVC 的收益最大，也最容易让人低估变更

Servlet 和 Spring MVC 是 Loom 受益最直观的场景之一，因为它们天生就是 direct-style 请求/响应模型。迁移策略通常不是重写控制器，而是验证底层服务器版本、JDK 版本、框架版本和线程执行模型支持，然后把请求执行切到虚拟线程，同时补齐依赖预算与 observability。这里需要格外警惕一种错觉：代码不怎么改，就以为没有架构变化。事实上，只要执行模型变了，连接池等待、下游 fan-out、超时策略和 rejection 策略都要重新看。

8.4 JDBC 的风险在于更容易把查询洪峰打进数据库

JDBC 迁移更要保守。虚拟线程与阻塞 JDBC 的组合是 Loom 最常被宣传的典型收益点，因为它让“阻塞数据库访问”不再必然拖住平台线程。但数据库从来不是因为线程贵才有限制，而是因为连接、锁、事务、IOPS 和 buffer pool 本来就有限。如果迁移后不收紧查询超时、不监控借连接等待、不限制每个请求内部的并行 SQL 数量，那么 JVM 线程成本下降只会鼓励更多请求更快打到数据库，最终让数据库成为更早、更猛烈的瓶颈。

8.5 HTTP client 与 RPC 更需要 request-level budget

HTTP client 与 RPC 客户端迁移同理。虚拟线程让同步调用写起来更舒服，但同步调用越舒服，团队越容易忘记连接复用、连接租借等待、TLS handshake 成本、远端配额、幂等重试和总 deadline 这些老问题。对多下游聚合服务，建议迁移时同步引入 request-level budget：例如同一类下游最多并发多少个调用、全局 deadline 如何切分到每个子任务、重试是否受总 budget 限制、某类调用是否有 bulkhead。这样 Loom 才是在“把代码写清楚”的同时“把资源预算也写清楚”，而不是只得到前者。

8.6 批处理与消息消费最怕“任务数量放大”

批处理和消息消费场景则要额外注意“任务数量放大”。过去很多 batch job 因为线程池限制，天然一批只会开有限数量任务；改成虚拟线程之后，如果把每个 record、每个消息、每个文件块都直接交给虚拟线程，又没有与数据库、对象存储、消息确认、下游 API 配额绑定的并发预算，就会很快把离线任务从“慢一点但稳定”变成“起得很猛、撞得很惨”。所以，批处理迁移的关键不是“并发越多越好”，而是“把每种外部资源预算化，然后让虚拟线程作为轻量执行单元去贴合这个预算”。

8.7 混合架构应当共存，而不是意识形态式替换

混合架构迁移时，还要明确哪些部分不该一起改。比如入口 HTTP 层先上虚拟线程，而内部高吞吐事件流仍保持 Reactor/Netty；或者业务编排层改成虚拟线程，计算密集子任务继续扔到有界平台线程池。Loom 最适合渐进共存，而不是意识形态式替换。一个成熟团队应当允许同一系统里存在多种并发模型，只要每一种都服务于清晰的资源边界。

8.8 用 semaphore 保护下游预算的最小模式

下面代码的场景是：业务想用虚拟线程保留同步代码，同时防止风险服务被并发洪峰打穿。原因是这类“每个请求都能很自然地多发几个下游请求”的模式最容易在 Loom 迁移中失控。观察点是并发预算由 Semaphore 显式表达，而不是由线程池大小隐式表达。生产边界是：semaphore 只是预算表达方式之一，实际系统还需要 timeout、deadline、metrics、拒绝策略和降级结果配套。

public final class RiskGateway {
    private final Semaphore budget = new Semaphore(120);
    private final RiskClient client;

    public RiskResult check(String userId) throws Exception {
        if (!budget.tryAcquire(100, TimeUnit.MILLISECONDS)) {
            return RiskResult.degraded("risk budget exhausted");
        }
        try {
            return client.fetch(userId);
        } finally {
            budget.release();
        }
    }
}

8.9 一个可执行的迁移顺序模板

对大多数企业团队而言，更容易成功的迁移顺序通常是这样的。先选一个边界清楚、主要做 I/O 聚合、回滚简单的路径；接着列出现有线程池、连接池、重试与 timeout 策略；然后把 direct-style fan-out 与依赖 budget 一起设计出来；之后在预发环境用压测验证入口并发增长时的连接等待、错误率、取消传播和 carrier 行为；再通过灰度发布观察一段时间的深层指标；最后才决定是否扩大到更多路径。这个顺序的重点不是快，而是让每一步都能明确回答“我们到底改善了什么、又把什么风险带进来了”。

如果团队一开始就试图把所有请求处理、所有后台任务和所有依赖一起迁移到 Loom，往往很难分辨收益与问题分别来自哪里。分阶段模板能把学习成本和事故范围控制在可接受边界内，也更容易让组织积累可复制经验。

8.10 回滚条件必须在迁移前就写好

Loom 迁移最怕的一种情况是：上线后发现尾延迟变差、下游预算被放大、深层排队增加，但团队并没有明确回滚条件，因为“功能看起来还是正常的”。真正成熟的迁移应在发布前就定义回滚触发条件，例如连接池借用等待持续高于某阈值、downstream timeout 比基线升高某比例、deadline 取消无效导致后台无价值工作激增、carrier 占用异常、某类关键接口的 p99 明显恶化而无业务收益。只要条件触发，就应快速关闭 Loom 路径或切回旧执行模型，而不是继续观察直到故障扩大。

回滚条件之所以要前置，是因为 Loom 带来的风险往往不是立即功能错误，而是预算位置迁移。如果没有前置触发器，团队很容易把“还能返回结果”误当成“迁移成功”，最终在更高流量窗口付出代价。

8.11 四类典型业务的迁移判断不应一刀切

为了让迁移建议更可执行，可以把常见业务粗略分成四类。第一类是 API 聚合与 BFF，这类业务通常 CPU 轻、I/O 多、控制流复杂度高，使用 Loom 的收益最大，但必须同步设计 request-level budget 和取消传播。第二类是事务型后端，例如订单、支付、库存、账户系统，这类业务虽然也做大量 I/O，但状态一致性和失败语义更敏感，迁移时重点不在“能不能并发更多”，而在“哪些调用适合并发、哪些必须串行、哪个阶段失败后必须立即停”。第三类是批处理与离线任务，这类系统更容易因为虚拟线程廉价而放大并发洪峰，因此应优先以依赖预算和批次粒度控制为中心，而不是追求表面任务并发数。第四类是消息驱动与事件处理系统，这类场景要先区分是“请求式拉取后处理”还是“持续事件流”。前者可能很适合 Loom，后者则往往仍需要显式背压和 event-driven 语义。

这种分类的价值在于，团队不必围绕某个框架标签做抽象争论，而可以直接问：当前路径属于哪类业务，它的主瓶颈和主要风险是什么，Loom 到底帮助我们降低哪一部分复杂度。如果一个路径既没有明显等待成本，也没有因异步写法造成的维护负担，那么为了“技术统一”而强推 Loom 往往收益有限。反之，如果业务本来因为等待成本被迫写出大量异步样板，且团队又需要更清晰的错误栈和 direct-style 代码，那么 Loom 的优先级就会明显上升。

8.12 平台层应提供哪些基础能力，业务团队才不会各写各的 Loom

很多 Loom 迁移最终失败，不是因为虚拟线程不好，而是因为组织把所有治理细节都留给了每个业务团队自己实现。这样一来，有的团队会做 semaphore 保护，有的团队只配 timeout，有的团队会做 deadline 传播，有的团队只是简单替换 executor，最终形成行为不一致、监控口径不一致、回滚开关不一致的局面。平台层如果真的要支持 Loom，至少应提供几类基础能力：统一的 request context 与 deadline 传播机制；标准化的下游预算组件，如 bulkhead、rate limiter、budget rejection metrics；统一的 JFR 采集建议和诊断模板；连接池、HTTP 客户端、消息消费等常见依赖的监控基线；以及可快速切换执行模型或关闭某类并发策略的配置开关。

当这些能力成为平台默认路径时，业务团队就不需要在每个服务里重新发明一遍“如何在 Loom 中保护数据库和下游”的轮子。更重要的是，事故发生时不同服务的行为更可预测，值班团队也更容易从统一指标和统一日志模式中快速判断问题。这正是 Loom 迁移能否从“少数团队的技巧”升级为“组织级可推广能力”的关键分水岭。

9. Benchmark：什么样的 Loom 测试有意义，什么样的结论不应驱动生产决策

9.1 先区分“表示成本”测试和“系统吞吐”测试

Loom 是非常容易被 benchmark 误导的主题。因为虚拟线程在演示程序中常常“好看得惊人”：创建数量巨大、内存占用小、等待成本低、示例代码短。这些结果都可能是真实的，但如果不说明工作负载、资源预算和依赖模型，就会把本来应该帮助架构判断的证据，变成误导决策的口号。

首先，要区分“表示成本 benchmark”和“系统吞吐 benchmark”。前者测试的是 JVM 维持大量等待中任务的能力，比如大量 sleep、大量等待 channel 或大量轻量阻塞；它可以证明虚拟线程确实比平台线程更适合表示海量等待任务。后者测试的是系统在完整业务链路下的吞吐、延迟和错误率，比如入口请求、数据库访问、远程 API 调用、序列化和业务处理一起参与。前者的结论不能直接外推到后者。你可以从“一个 JVM 能同时挂起几十万虚拟线程”得出“线程表示不再是首要瓶颈”，但不能直接得出“我们的订单系统吞吐可以放大十倍”。

9.2 benchmark 的第一前提是冻结依赖预算

其次，任何生产级 benchmark 都必须冻结依赖预算。数据库连接池大小、HTTP client 连接数、下游服务并发配额、超时、重试、缓存命中率、硬件配置、JDK 版本、框架版本，都必须保持可比。否则，一边是 64 连接池、另一边是 256 连接池，一边开了 aggressive retry、一边没开，这种测试无论结果多漂亮，都不是 Loom 本身的证据。尤其需要警惕的是，一些看似“虚拟线程吞吐更高”的结果，实际只是因为测试把更多请求压进了更深层排队，短时间内看似 RPS 上升，代价却是尾延迟和超时率变差。

9.3 p95/p99、error 和 queue wait 比平均值重要得多

第三，benchmark 必须强调尾延迟和错误率，而不是只报平均值。虚拟线程常常会让系统在低到中负载区间更平滑，因为入口不再被平台线程早早卡住；但这也意味着你更容易把系统推到依赖极限附近。平均延迟也许仍然很好看，p95/p99 可能已经显著恶化。若一个结论只写“RPS 从 4 万升到 7 万”，却不写 timeout、error、queue wait 和下游 saturation，那么它对生产判断的价值非常有限。

9.4 维护性和可解释性也是 benchmark 结果的一部分

第四，benchmark 还应衡量可解释性成本。Loom 的一个真实价值是 direct-style 代码维护更简单、异常栈更直观、排查路径更贴近业务。这类收益不容易用单个数字表达，却常常决定长期总成本。相反，如果一份测试只强调 microbenchmark 数值，却不说明代码复杂度变化、调试路径变化、observability 变化，就很容易把读者带回“只看性能排行”的旧思路。

9.5 所有结论都必须用边界语言书写

第五，benchmark 的结论必须用边界语言。比如更合理的写法是：“在当前测试环境、当前 JDK 版本和给定的下游预算下，虚拟线程版本在维持同等正确性和近似错误率的前提下，降低了平台线程占用，并在某个并发区间改善了 p95 延迟表现。”不合理的写法是：“虚拟线程比线程池快 X 倍。”前者是可审计 claim，后者往往是脱离上下文的 marketing 句式。

很多团队其实不缺压测工具，缺的是“测试前先定义问题”的纪律。Loom benchmark 的第一个问题应该是：我们要证明什么？是证明 direct-style 能否替代现有异步写法而不损失吞吐？是证明数据库连接等待是否成为主瓶颈？是证明 carrier 没有被长临界区拖住？是证明取消传播能减少无价值下游调用？不同问题对应不同测试设计。没有明确问题，再多结果也只是噪音。

9.6 生产前最好至少做三层验证：实验、灰度、长时间窗口

如果团队希望把 benchmark 真正转化成可发布证据，最好把验证拆成三层。第一层是实验室验证，用可控流量和固定依赖条件确认 direct-style 代码在正确性、资源占用和关键指标上与旧实现一致或更优。第二层是灰度验证，在真实流量和真实依赖抖动下观察预算位置是否迁移、哪些指标先恶化、是否存在旧监控看不到的新风险。第三层是长时间窗口验证，确保高峰持续半小时、一小时甚至更长时，不会因为无价值工作积累、重试放大或连接池慢性抖动把系统拖坏。很多 Loom 路径在第一层看起来都能过，但真正区分成熟方案和危险方案的，往往是后两层。

从治理角度看，这三层验证还有一个好处：它们会逼团队明确“我们到底接受什么样的收益与风险交换”。如果实验验证只证明代码变简洁，而灰度和长时间窗口显示下游预算更脆弱，那么这条迁移就未必值得继续扩大。把这一点提前说清楚，比在发布后继续用“性能好像还可以”模糊判断要可靠得多。

10. 生产清单与反模式：上线前必须确认什么，最常见的错法是什么

10.1 上线前检查清单必须覆盖版本、预算、失败语义和回滚

如果要把一条业务路径切到虚拟线程执行，最重要的不是“会不会用 API”，而是是否通过了一套生产前检查。第一组检查是版本与组件兼容。JDK 版本、应用服务器或容器、Spring/Servlet 支持、JDBC 驱动、HTTP 客户端、RPC 框架、Tracing 和监控库，是否都已在目标版本上验证。第二组检查是资源预算。数据库、缓存、HTTP、消息系统、第三方 API 是否都有明确上限和可观测性，预算耗尽时的策略是否定义清楚。第三组检查是失败语义。超时、取消、熔断、重试、降级和回滚是否串成了一致的策略，而不是各个库各自为政。第四组检查是观测证据。JFR、线程 dump、metrics、tracing、日志关联是否足以解释流量高峰、依赖抖动和故障演化。第五组检查是回滚能力。若虚拟线程路径在高峰中暴露未知问题，是否可以快速切回原有执行模型或关闭相关入口。

10.2 最常见的四类反模式

在反模式方面，最常见的一类是把虚拟线程当作“无限线程”来用。这类系统通常表现为入口无显式限流、每个请求 fan-out 缺乏约束、数据库查询无统一预算、第三方 API 无并发配额保护，开发者只看到“代码依然很直白，线程也没报错”，直到下游开始雪崩。第二类反模式是用 Loom 掩盖 CPU 问题。某些团队把 CPU 密集作业也交给海量虚拟线程，误以为“线程轻量就能更并行”，结果只是让调度更嘈杂、缓存更抖、排查更困难。第三类反模式是以为 direct-style 等于不再需要背压，于是把 reactive 模型里本来显式表达的流控全部丢失。第四类反模式是只改 executor，不改 observability，导致线上故障发生后仍然只能盯着旧式线程池指标，一时看不出真实瓶颈。

10.3 为了“避免 pinning”而大规模无差别重构，通常是错误方向

还有一种更隐蔽的反模式，是“为了避免 pinning 过度重构”。一旦知道 Loom 里有 pinning，团队可能会冲动地清洗全部 synchronized、替换大量成熟依赖、改写很多本来没有性能问题的同步段。这种做法会把一个本可渐进验证的特性升级，变成高风险重构项目。更稳妥的原则是：先测、先定位、先聚焦热路径，再决定是否重构。Loom 不是要求你重新发明所有并发抽象，而是要求你用新证据重新校正边界。

10.4 无价值工作削减，是 Loom 时代很容易被忽略的新重点

生产清单还应该特别包含“无价值工作削减”。因为虚拟线程让等待便宜后，系统更容易容忍“大量已经没有用户价值的等待”在后台继续存在。例如用户早已断开连接，但多个下游调用还在继续跑；父任务 deadline 已过，但部分子任务仍然借着连接池等资源；某个 fallback 已经确定返回，但竞速查询中的慢任务还在浪费容量。如果没有取消传播和结果无价值判断，Loom 时代这种浪费会比平台线程时代更普遍，因为它不再立刻体现为线程池爆满。

10.5 生产变更应该配套可审计证据包

最后，生产清单必须落在“证据包”上，而不是“感觉没问题”。一条合格的 Loom 上线证据，至少要包含：目标路径说明、适用 JDK 版本、依赖预算表、入口与下游并发模型、超时与重试策略、取消传播说明、压测对比结果、JFR 关键观察、监控面板更新项、回滚步骤和上线后观察窗口。没有这些材料，虚拟线程迁移仍然只是一个技术偏好，而不是一个经过工程审计的生产决策。

10.6 事故 runbook 一：虚拟线程数量很多，但 CPU 不高，延迟却在升

这类事故在 Loom 时代非常常见，因为它恰好体现了“等待成本便宜，不代表资源压力消失”。当你看到虚拟线程数量持续上升，但 CPU 没有同步打满，用户侧延迟却显著恶化时，第一步不要纠结线程数，而是立即检查连接池等待、HTTP 客户端连接租借、第三方 API RTT、消息 lag 和 retry 次数。第二步确认 deadline 与 cancellation 是否起效，避免无价值工作继续占用资源。第三步看是否有某类入口请求 fan-out 异常放大，或者某个 fallback 意外把流量打向更贵的依赖。只有当这些资源侧指标都排除后，才值得进一步怀疑 carrier 被 pin 或调度异常。

这个 runbook 的意义在于帮助值班人员快速摆脱“线程很多就是线程问题”的思维惯性。Loom 让大量等待中任务不再天然意味着平台线程危机，因此排查必须从等待对象开始，而不是从线程容器开始。

10.7 事故 runbook 二：下游突然被打穿，但入口没有明显拒绝

这种事故通常说明 Loom 把原来被线程池提前拦住的流量送到了更深位置。排查时应先看入口 admission 是否过宽，其次看 request-level budget 是否失效，再看下游连接池与客户端 timeout 是否导致深层排队。若系统对每个请求允许了过多并发子任务，即便入口 QPS 没有飙升，下游也可能因为 fan-out 放大而瞬时过载。恢复动作往往应优先从入口限流、收紧子任务并发、关闭非关键调用或 fallback 路径开始，而不是先盲目扩容数据库或第三方配额。

更重要的是，这类事故通常暴露了一个治理空洞：团队把 Loom 当作了提升入口承载能力的手段，却没有同步补齐依赖预算。因此，事故复盘里不应只写“下游容量不足”，而应明确记录“为什么入口能在没有更早保护的情况下持续放大对下游的压力”。

10.8 事故 runbook 三：代码变简单了，但可观测性反而变差

这听起来违反直觉，因为 Loom 常被宣传为“更易调试”。可一旦组织还在用旧线程池时代的仪表盘和告警体系，实际体验就会相反：代码确实更直白，但新的指标没有跟上，于是值班时只能看到“错误率上升”和“线程数很多”，却看不到真正的预算位置。处理这类问题时，重点不是回到旧模型，而是补足 Loom 时代的 observability：按依赖预算重构仪表盘、增加取消与无价值工作指标、把 request-level fan-out 与 deadline 消耗暴露出来、给 JFR 和线程 dump 建立统一的采集和分析流程。

如果一个团队在引入 Loom 后没有同步升级 observability，那么它获得的不是“更好调试”，而是“更易写代码但更难看见深层问题”。这类事故说明迁移是不完整的，而不是说明 Loom 本身不适合生产。

10.9 最终反模式：把 Loom 当成性能功能，而不是治理契约

所有前面的反模式，其实都可以收束到一个更大的总反模式上：把 Loom 当成性能功能，而不是治理契约。只要团队只关心“能开多少虚拟线程”“代码看起来是不是更简单”“某个 benchmark 数字是不是更高”，却不关心 budget、背压、取消、回滚和观测，那么 Loom 迟早会被误用。真正成熟的采用方式，应该把它视为一种新的契约：同步阻塞更便宜了，所以资源治理必须更显式；direct-style 回来了，所以失败语义和请求生命周期更需要前置设计；入口更从容了，所以深层预算更需要可见。这才是虚拟线程在生产系统中真正该被理解的位置。

10.10 一个简化决策矩阵：什么时候优先 Loom，什么时候先别动

为了把上面的判断压缩成真正可执行的团队对话，可以给出一个简化决策矩阵。若某条路径同时满足“以阻塞 I/O 为主、业务控制流线性但现有异步样板很多、下游预算可清点、框架与驱动版本可验证、回滚路径明确”，那么 Loom 通常是高优先级候选。若路径的主要成本在 CPU 计算、批量算法、序列化压缩或单机内存带宽，而不是等待，那么先优化 CPU 与执行模型边界比引入 Loom 更重要。若路径天然是长生命周期流处理、必须表达跨组件背压、依赖成熟 event loop 设施，那么 reactive 或消息驱动模型往往应保留。若路径包含大量 native 黑盒、未知驱动行为、老旧框架兼容性问题且当前又没有强迁移动机，则更适合先做小范围验证，而不是直接进入生产切换。

这个矩阵的关键不在于给出绝对答案，而在于把“为什么做或者为什么不做”变成可以复盘的工程判断。团队不应再用“别的公司都在上 Loom”或“看起来能省掉很多回调”这类理由推动迁移。真正可靠的推进逻辑应当是：当前边界的维护成本和等待成本确实高，且 Loom 可以在不削弱预算治理的前提下降低复杂度。没有后半句，前半句就不够。对于架构师来说，这个矩阵最大的意义不是帮助所有项目都得出相同结论，而是让不同项目能够在同一套问题框架下得到不同但自洽的结论。

10.11 三个常见生产场景的 Loom 价值完全不同

场景一，典型的用户主页聚合接口。这类请求要查用户资料、订单、优惠券、推荐、风控、客服入口等多个依赖，业务控制流很适合 direct-style，同时又天然存在 fan-out。Loom 在这里的价值很高，因为它能显著降低为了节省平台线程而引入的大量异步样板，前提是你把请求内并发上限、下游 budget、deadline 和降级策略写清楚。场景二，高频交易或极低延迟内部计算服务。这里主要成本也许根本不在等待，而在 CPU、缓存命中、锁竞争和对象分配；Loom 不是第一优先项，甚至可能不是收益项。场景三，企业集成或批量对接服务。它们通常调用链长、第三方接口多、失败路径复杂、夜间批任务常见，Loom 的收益在于更清晰的 direct-style 编排，但风险在于如果没有预算和回滚，夜间批量任务会非常容易放大对数据库和第三方的压力。

把这三个场景放在一起看，可以帮助团队避免一个典型偏差：把某个边界上的成功经验强行复制到所有边界。很多技术推广失败，不是技术本身无效，而是组织把“适合某一类问题的答案”误当成“适合所有问题的标准答案”。例如某个 BFF 团队在 Loom 下获得了明显收益，并不代表同样方式适合长期运行的消息处理器；反之，某个 CPU 密集型模块没有收益，也不代表 Loom 对 I/O 聚合服务没有价值。成熟组织应该把这种差异视为正常现象，而不是把它当成技术路线不统一的证据。

10.12 架构评审时最该追问的七个问题

如果要对一个 Loom 提案做评审，以下七个问题通常最能逼近实质。第一，这条路径的主要时间成本是等待还是 CPU？第二，迁移后最先被放大的下游预算是什么？第三，请求内最多会并发开启多少个子任务，这个数字是怎么来的？第四，父请求 deadline 如何传播到每个子任务，取消什么时候生效？第五，失败后哪些结果可以降级、哪些必须整体失败？第六，出现预算耗尽时，入口如何拒绝、降级或排队，而不是让深层依赖无限等待？第七，若迁移在高峰中出现问题，如何快速回滚。只要其中任意一个问题答不清，说明这个 Loom 提案更像技术尝试，而不是生产级变更。

这些问题的价值，在于它们能把讨论从“代码是不是更优雅”转成“系统是不是更可治理”。Loom 很容易在审美上得高分，因为 direct-style 确实比层层回调更自然；但生产评审不能只看审美，必须看预算、失败和证据。一个真正成熟的 Loom 评审，往往不会花太多时间争论 API，而会把大量时间放在“下游预算是否有定义”“deadline 是否真正贯通”“压测里有没有观察到预算位置迁移”“旧监控能否解释新模型中的故障”这些更不华丽但更关键的问题上。

10.13 复盘时要记录的是预算迁移，而不只是“哪里变慢了”

Loom 相关事故复盘，如果只记录“某接口 p99 变差了”“某连接池打满了”，价值通常不够。更重要的是记录预算迁移过程：以前由哪个线程池或队列隐式限制住的流量，在迁移后进入了哪个更深位置；哪些监控未能及时暴露风险；哪些 retry、fallback 或 fan-out 路径把问题放大；哪些 deadline 和取消本应生效却没有生效；回滚为何及时或为何没有及时发生。只有把这些迁移路径写清楚，组织下次才不会在另一条路径上重蹈覆辙。

这也是为什么本文反复强调 Loom 不是“更快线程”，而是“更显式治理责任”的原因。事故复盘如果仍然只从线程、CPU 或某个异常栈出发，就说明团队还没真正把治理对象从线程转移到预算。更进一步，预算迁移的复盘还能帮助平台团队识别哪些能力应该产品化。例如，如果多个服务都在复盘中提到“取消失效导致无价值工作放大”或“downstream budget 指标缺失”，那就说明这些问题不该继续留给单个业务团队各自解决，而应沉淀为平台默认能力。

10.14 长期治理目标不是“全面 Loom 化”，而是“让 direct-style 与预算治理并存”

一个成熟组织的长期目标，不应是统计“多少服务已经用上 Loom”，而应是确保 direct-style 与预算治理被一体化设计。某些服务可能永远不需要 Loom，因为它们主要问题不是等待成本；某些服务可能只在入口层使用 Loom；某些服务可能经过验证后发现下游预算不适合放大，最终决定维持原模型。这些结果都没有问题。真正有问题的是组织把 Loom 当作路线图 KPI，而不是把它当作解决特定复杂度与特定等待成本问题的工具。

因此，最好的推广指标不是“启用了多少虚拟线程”，而是“有多少 Loom 路径具备清晰的 budget、取消、超时、观测与回滚证据”。当组织开始用这套标准衡量成功时，虚拟线程才真正从一个新特性，变成可长期维护的工程能力。换句话说，Loom 的终局不是让所有服务统一成一种并发模型，而是让更多服务在最适合的边界上，用更低认知成本写出仍然受预算约束、仍然可观测、仍然可回滚的同步代码。这比任何一句“全面采用新特性”都更接近企业工程现实。

10.15 最终判断：Loom 让 Java 重新拥有了选择简单的资格，但不能替你完成治理

很多年里，Java 团队在高并发 I/O 服务里常常被迫接受一种妥协：如果要节省线程成本，就必须容忍更复杂的异步控制流；如果要保留同步代码的可读性，就必须为平台线程等待付出更高资源代价。Loom 打破了这组旧妥协，让团队重新拥有“选择简单”的资格。这里的“简单”不是指偷懒，而是指业务控制流、异常路径和任务边界可以更贴近人类直觉。

但资格不是结果。Loom 让你有机会用更简单的代码表达复杂等待，并不代表系统因此自动安全。真正把这个机会转化为生产收益的，仍然是预算定义、下游保护、结构化并发、取消传播、版本化诊断、观测升级和证据驱动发布。只要这些治理动作缺席，Loom 就会把过去由线程池粗糙掩盖的问题更真实地暴露出来；这未必是坏事，但如果团队没有准备好面对这些真实问题，它就会在错误的时机变成更昂贵的事故。

10.16 角色化交付：架构师、平台、业务与运维各自要交什么

要让 Loom 成为可持续能力，不能只要求业务团队“把 executor 换成虚拟线程”。不同角色必须交付不同的工程资产。架构师要交付的是边界判断：哪些路径适合 direct-style，哪些路径仍保留 reactive 或消息驱动，哪些依赖预算会被放大，哪些故障模式必须在上线前演练。平台团队要交付的是默认能力：统一的虚拟线程执行模板、request-level budget 组件、deadline 传播规范、JFR 采集建议、线程 dump 解读手册、dashboard 模板和一键回滚开关。业务团队要交付的是路径级证据：fan-out 上限、下游并发预算、失败语义、取消传播、压测数据、灰度观察窗口和回滚步骤。运维或 SRE 团队要交付的是运行证据：等待位置、拒绝位置、无价值工作、下游预算耗尽、重试放大和 cancellation 生效情况的告警规则。

如果这些交付物缺位，Loom 很容易变成“某个服务自己试用的新特性”。这类试用在局部看可能成功，但很难扩展成组织能力，因为每个团队都会重新发明 budget、timeout、dashboard 和 runbook。更糟的是，不同团队会形成互相矛盾的经验：有的说 Loom 很稳，有的说 Loom 会打穿数据库，有的说 pinning 很危险，有的说完全没问题。真正的差异并不一定来自 Loom 本身，而是来自各团队治理资产成熟度不同。角色化交付的意义，就是把运行时能力从个人经验变成平台契约。

10.17 平台模板不是封装 API，而是封装默认安全路径

很多平台在推广新能力时喜欢先做 starter 或示例项目，但 Loom 的平台模板如果只封装 API，就会遗漏最重要的安全边界。一个合格模板至少应该把入口并发、子任务并发、deadline、取消传播、下游预算、异常聚合、降级语义、JFR 事件、日志关联和指标命名一起纳入默认路径。业务团队当然可以按场景调整，但调整必须是显式的，而不是每个服务在复制示例后悄悄失去保护。

平台模板还应该避免制造假安全感。比如只提供“每个请求创建一个虚拟线程”的便利方法，却不提供 request fan-out 限制，就会把风险推给业务代码；只提供结构化并发示例，却不说明部分失败、超时和取消策略，就会让团队误以为 scope 本身自动解决治理；只在 README 里写“注意下游保护”，却没有对应指标和默认限流组件，最后仍然会在事故中失效。模板真正要封装的不是语法，而是默认安全路径。读者在不展开任何底层实现的情况下，也应该能理解：这个模板默认保护什么，故意不保护什么，哪些地方必须由业务自己填写。

10.18 上线分阶段：先影子验证，再小流量，再按依赖预算扩展

Loom 迁移不适合一口气覆盖整条业务链路。更稳妥的路径通常分三阶段。第一阶段是影子验证，目标不是证明性能提升，而是验证依赖兼容、上下文传播、日志链路、JFR 事件、取消语义和回滚开关是否能工作。第二阶段是小流量生产灰度，目标是观察真实流量下的等待位置迁移：旧线程池不再是瓶颈后，哪个下游预算最先紧张，哪些 timeout 组合会变得更显眼，哪些 retry 会把深层压力放大。第三阶段才是按依赖预算扩展覆盖面，目标是让每一次扩容都绑定下游容量证据，而不是只看入口服务是否还能接住。

这个分阶段流程有一个重要好处：它把“性能收益”从过早的争论中拿出来，先验证系统是否可控。很多失败迁移的问题并不是 Loom 没有收益，而是团队过早把讨论聚焦在吞吐和线程数，忽略了上下文、取消、观测和回滚。生产系统的真正顺序应该相反：先证明可控，再证明有益；先证明失败时能退，再证明成功时能扩；先证明依赖预算能承接，再证明入口能接更多请求。这样的顺序看起来保守，但它能防止一次运行时迁移演变成难以回滚的组织事故。

10.19 与 reactive、消息驱动和批处理共存，而不是互相替代

Loom 并不会让 reactive、消息驱动或批处理模型失去价值。Reactive 仍然适合需要显式表达长生命周期流、背压传播和事件组合的场景；消息驱动仍然适合削峰、异步解耦、重试缓冲和跨系统最终一致；批处理仍然适合面向数据窗口、批量吞吐和可重放任务的场景。Loom 的优势是让阻塞 I/O 编排重新变得可读、可调试、可维护，但它不是所有并发问题的统一答案。

更现实的企业架构通常是混合模型。入口聚合层可以用虚拟线程降低异步样板，事件流处理仍然保留 reactive 或消息队列，后台批处理继续按分片和作业窗口治理，极低延迟计算服务仍然围绕 CPU、内存布局和锁竞争优化。混合模型的难点不在技术名词，而在边界翻译：从 virtual-thread 请求进入消息队列时，deadline 如何转换成消息过期或消费预算；从 reactive 流进入同步服务时，背压如何转换成入口拒绝或降级；从批处理调用在线依赖时，批量并发如何受在线预算约束。只有这些翻译被设计清楚，模型共存才不会变成新的复杂度来源。

10.20 成功指标：少看“启用数量”，多看治理质量

如果一个组织用“多少服务启用了虚拟线程”衡量 Loom 推广成功，很容易走向错误方向。启用数量只说明 API 被使用，不说明系统更可靠、更易维护或更便宜。更好的指标应该包括：多少条路径具备 request-level budget，多少个下游有明确并发上限，多少个服务能在 dashboard 上看到等待位置，多少次灰度定义了回滚信号，多少个事故复盘记录了预算迁移，多少个服务能在 deadline 之后停止无价值工作，多少个模板把 JFR 与 tracing 证据纳入默认路径。

这些指标看起来没有“启用率”漂亮，却更接近企业工程现实。Loom 的长期收益不是让组织显得更快采用新特性，而是让更多服务用更低认知成本表达复杂 I/O，同时不降低预算治理、失败治理和可观测质量。换句话说，成功的标志不是“我们用了 Loom”，而是“我们在更简单的代码里仍然保留了系统边界”。如果这一点做不到，Loom 只会让代码表面变简单；如果这一点做到，它才会成为 Java 并发治理的一次真正升级。

10.21 ADR 应该记录“预算如何迁移”，而不只是“采用 Loom”

如果团队决定在某条路径上采用虚拟线程，ADR 不能只写“采用 Loom 以提升并发能力”。这样的记录几乎没有审计价值，因为它没有说明原来的瓶颈是什么、迁移后瓶颈会去哪里、系统如何知道自己没有把风险推深。更有用的 ADR 应该写清四件事。第一，原模型里的隐式挡板是什么，例如 Tomcat 线程池、业务 executor、reactive backpressure、消息队列消费并发或数据库连接池。第二，采用虚拟线程后，这些挡板哪些被保留、哪些被替换、哪些被上移到 request-level budget。第三，哪个下游或哪类资源最可能成为新的第一瓶颈。第四，出现风险时按什么信号回滚。

这种 ADR 还有一个重要作用：它让未来的维护者知道当初为什么没有“全面 Loom 化”。也许某个服务只在入口聚合层用了虚拟线程，因为消息消费侧需要保留批量背压；也许某个路径没有迁移，因为主要成本在 CPU；也许某个接口迁移后又回退，因为第三方 API 的配额无法承接更深并发。把这些决定记录下来，比单纯记录“使用 virtual thread”更有价值。长期看，组织真正需要的是可复盘的并发判断史，而不是一份启用清单。

10.22 平台评审要检查负例，不要只展示成功路径

Loom 提案最容易包装成功路径：代码变短、回调减少、压测吞吐看起来更好、线程数不再是瓶颈。但平台评审必须主动要求负例。比如：如果下游连接池耗尽会发生什么；如果父请求取消，子任务多久释放资源；如果某个依赖突然变慢，是否会产生无价值工作；如果 JFR 没有按预期记录 pinning 或等待，排查还有没有第二条证据链；如果灰度阶段 p99 变差但平均延迟变好，团队如何解释并决策。

负例评审的价值，在于提前暴露“看起来优雅但没有治理”的路径。很多 Loom 风险不是在 happy path 出现，而是在失败路径、取消路径、重试路径、fallback 路径和观测缺口里出现。一个成熟平台应该把这些负例做成评审问题，而不是指望每个业务团队靠经验想起来。只有当负例也能被解释，Loom 提案才从技术演示变成生产变更。

11. 结论：Loom 的价值在同步代码的可维护性，生产安全来自显式并发治理

Project Loom 为 Java 带来的最大现实价值，不是“终于也能像别的语言一样有轻量线程”，而是让大量传统同步 I/O 服务重新拥有了清晰、线性的业务表达方式，同时不必再为平台线程等待成本付出过高代价。这对于长期背负复杂异步样板、回调拼装、调试困难和上下文传播成本的 Java 团队来说，是一次重要的工程解放。

但任何把 Loom 描述成“线程成本问题已解决，所以高并发自然成立”的说法，都会把读者带向危险方向。生产安全从来不是由线程 API 直接保证的，而是由容量预算、资源池、背压、timeout、取消、隔离、版本边界、观测证据和回滚能力共同保证。虚拟线程只是把这些机制从过去的“部分被线程池粗暴代理”状态中解放出来，逼迫架构师更诚实地面对真实瓶颈。这是好事，因为它让系统治理更贴近真实资源；但前提是团队愿意接受资源治理必须显式化，而不是继续依赖隐式挡板。

因此，对 Java 架构师最稳妥的结论应该是：把虚拟线程视为 direct-style I/O 服务的首选执行模型之一，而不是唯一正确模型；把结构化并发视为请求内 fan-out 的生命周期纪律，而不是单纯的语法便利；把 pinning 视为需要版本化、证据化诊断的 carrier 利用率问题，而不是一句口号式禁令；把 benchmark 视为验证特定问题的证据，而不是宣传数字；把迁移视为资源边界重构，而不是 executor 替换。

当这些前提都成立时，Loom 的确能显著改善 Java 服务的可维护性、排查体验和阻塞 I/O 承载能力。否则，它只会把你从“线程池时代的粗糙约束”带到“资源治理缺失时代的深层过载”。Loom 不是并发治理的终点，而是一次把治理责任重新交还给架构设计本身的机会。抓住这个机会，Java 的同步代码会重新具备高并发时代的生命力；忽视这个机会，系统只会以更优雅的代码，制造更昂贵的事故。

如果要把这篇文章压缩成一句最值得带回团队的话，那就是：Loom 让 Java 重新获得了“用人能读懂的代码写高并发 I/O 服务”的能力，但它也迫使团队承认，真正决定系统安全性的从来不是线程名字，而是预算纪律。过去很多组织把并发治理外包给线程池、框架专家或历史偶然形成的配置，如今这些外包关系不再可靠。你必须重新回答那些一直存在、却常常被旧模型遮住的问题：一个请求最多能放大成多少下游调用，什么工作在 deadline 之后仍然值得继续，哪个依赖在高峰时最先需要保护，系统是在入口拒绝更可控，还是在深层排队更危险，平台是否已经给业务团队提供了统一的 budget 与 observability 基础设施。能把这些问题答清楚，Loom 就会成为生产力；答不清楚，它就只是让问题暴露得更真实。

从中长期平台建设看，Loom 最有价值的地方并不只是帮助单个服务减掉异步样板，而是为整个 Java 平台恢复一种更一致的工程语言。过去，一个服务的并发设计可能散落在 Tomcat 线程池、业务线程池、HTTP 客户端、缓存客户端、数据库连接池、异步回调、消息消费并发和临时脚本之中，团队需要跨越多套抽象才能理解系统如何在等待中前进。Loom 给了架构师一个重新整理这些抽象的窗口：把 direct-style 作为默认业务表达，把结构化并发作为请求内任务治理，把预算、取消、timeout、fallback、灰度和回滚作为统一的运行契约。这样做的收益不仅是代码更短，更关键的是架构判断、运行证据和事故复盘更容易在同一种语言里对齐。

这也是为什么本文始终把 Loom 放在“生产系统中的并发治理”而不是“Java 新线程特性”这个标题下。企业采用任何运行时能力，最终都要面对组织稳定性、人才交接、平台模板、升级策略、可观测性资产和事故恢复速度。虚拟线程只有在这些维度都被纳入设计之后，才配得上被称为生产级能力。对于真正负责系统长期演进的人来说，衡量 Loom 成败的标准不应是“我们把多少代码改成了 virtual thread”，而应是“我们是否让更多服务在预算可见、行为可解释、失败可降级、发布可回滚的前提下，用更低的复杂度表达原本很难维护的并发逻辑”。如果答案是肯定的，那么 Loom 不只是一次运行时升级，它就是 Java 并发工程学的一次范式修正。

参考资料

1. JEP 444: Virtual Threads. OpenJDK.
2. JEP 491: Synchronize Virtual Threads without Pinning. OpenJDK.
3. Project Loom. OpenJDK Project Pages.
4. JEP 453 / 462 / 480 / 499 / 505 / 525 对应的 Structured Concurrency preview 演进资料。
5. Oracle 与 OpenJDK 对 JDK 21 之后虚拟线程、JFR 与并发工具链的版本说明。