Spring Boot 3.2+ 虚拟线程支持：革命与局限

概述

前文详细剖析了 Servlet 容器中每请求一线程的并发模型，以及 WebFlux 基于事件循环的非阻塞模型。这两种模型各有优劣：前者编程简单但扩展性受限，后者性能卓越但学习和排错门槛高。Java 21 引入的虚拟线程从根本上改变了线程的创建成本和调度方式，使得“每请求一线程”可以变得既简单又极致扩展。Spring Boot 3.2 以极其简洁的配置开关拥抱了这一特性，本文将深度分析这一变革对整个 Spring Web 技术栈的深远影响。

虚拟线程是 OpenJDK 自 Lambda 以来最重大的语言级并发变革。它将开发者从线程池的精细调优中解放出来，使得为每个请求分配一个新线程变得廉价可行，同时保留了“请求-线程”模型的同步编程直观性。Spring Boot 3.2 的虚拟线程支持让 Tomcat、Jetty 等容器能够无感切换，@Async 方法也无需再担心线程池耗尽。然而，这种“无限制”的并发能力并非没有代价：线程固定（Pinning）可能导致平台线程耗尽，数据库连接池会成为新的瓶颈，而无控制地创建虚拟线程可能引发文件描述符耗竭。本文将客观审视虚拟线程在 Spring Boot 中的底层实现，对比其与响应式模型的真实边界，帮助读者在技术选型时做出理性的工程决策。

核心要点

• 虚拟线程的本质：JVM 内部调度的廉价用户态线程，堆栈可动态伸缩，一个平台线程可承载数千个虚拟线程。
• Spring Boot 的无缝集成：一行配置即可替换 Servlet 容器线程池和异步执行器，无需修改业务代码。
• 容器的质变：server.tomcat.threads.max 不再重要，但操作系统限制仍是天花板。
• 与 WebFlux 的抉择：虚拟线程解决的是并发连接问题，而响应式解决的是数据流背压与资源严格控制的底层问题。
• 隐藏的陷阱：Pinning、连接池耗尽、文件描述符上限是生产环境中必须直面的技术风险。

文章组织架构图

flowchart TD
    subgraph S1 ["1. 虚拟线程基本原理与并发模型变革"]
        A1["1.1 平台线程 vs 虚拟线程"] --> A2["1.2 Continuation 与调度"]
        A2 --> A3["1.3 线程池 vs 虚拟线程"]
    end

    subgraph S2 ["2. Spring Boot 3.2 集成：AutoConfiguration 与容器改造"]
        B1["2.1 VirtualThreadsAutoConfiguration 源码拆解"]
        B1 --> B2["2.2 Tomcat 虚拟线程改造"]
        B1 --> B3["2.3 Jetty 虚拟线程改造"]
    end

    subgraph S3 ["3. 异步任务与 @Async 的虚拟线程化"]
        C1["3.1 VirtualThreadTaskExecutor 原理"] --> C2["3.2 @Async 方法的行为变化"]
        C2 --> C3["3.3 RestTemplate 与 WebClient 的上下文"]
    end

    subgraph S4 ["4. 虚拟线程对数据库连接池与 ThreadLocal 的冲击"]
        D1["4.1 连接池：新的并发瓶颈"] --> D2["4.2 ThreadLocal：低成本下的高消耗"]
        D2 --> D3["4.3 MDC 与链路追踪的上下文传递"]
    end

    subgraph S5 ["5. 虚拟线程 vs WebFlux：简化并发的边界与取舍"]
        E1["5.1 编程模型简化 vs. 背压控制缺失"]
        E1 --> E2["5.2 百万并发下的资源消耗对比"]
        E2 --> E3["5.3 决策框架：何时选择何种模型"]
    end

    subgraph S6 ["6. Pinning、资源耗尽与性能陷阱"]
        F1["6.1 Pinning：并发性的无声杀手"] --> F2["6.2 文件描述符与堆外内存耗尽"]
        F2 --> F3["6.3 检测、调试与修复指南"]
    end

    subgraph S7 ["7. 生产事故排查专题"]
        G1["7.1 事故一：synchronized 导致的线程固定与服务假死"]
        G1 --> G2["7.2 事故二：数据库连接池耗尽引发的雪崩"]
    end

    subgraph S8 ["8. 面试高频专题"]
        H1["8.1 理论题"] --> H2["8.2 应用题与系统设计"]
    end

    S1 --> S2 --> S3 --> S4 --> S5 --> S6 --> S7 --> S8

    classDef topic fill:#f8f9fa,stroke:#333,stroke-width:2px,rx:5,color:#333;
    class S1 topic;
    class S2 topic;
    class S3 topic;
    class S4 topic;
    class S5 topic;
    class S6 topic;
    class S7 topic;
    class S8 topic;

架构图说明

• 总览说明：全文共 8 个模块，遵循从底层原理到工程集成的认知路径。首先剖析虚拟线程的 JVM 层调度原理（1），然后深入 Spring Boot 如何对嵌入式容器进行“无感”改造（2）。接着分析此改造对上层 @Async 和 HTTP 客户端的连锁反应（3），并着重探讨数据库连接池等瓶颈转移问题（4）。之后，将虚拟线程与 WebFlux 进行系统对比，明确决策边界（5）。最后，通过原理性陷阱分析（6）、真实生产事故复盘（7）和面试题拆解（8），形成完整的知识闭环。
• 逐模块说明：
  • 模块1：建立虚拟线程的基础认知，它是理解后续一切工程行为的基石。与前文的平台线程池模型形成鲜明对比。
  • 模块2：揭示 Spring Boot “一行配置”背后的魔法，是本文的技术核心。直接关联前文 Servlet 容器的线程模型。
  • 模块3：分析虚拟线程如何影响应用层的并发实践，特别是对习惯使用 @Async 的开发者带来的改变。
  • 模块4：剖析并发模型变革后，瓶颈如何从“线程数”转移到“连接数”，是生产实践中最关键的认知升级。
  • 模块5：解决架构师的核心困惑：有了虚拟线程，WebFlux 还有必要吗？基于前文 WebFlux 的背压机制知识进行深度对比。
  • 模块6：是“革命”的B面，揭示虚拟线程的局限性与暗坑，为生产落地的安全性提供保障。
  • 模块7：将模块6的理论风险实例化，通过真实案例传授排查方法论。
  • 模块8：从面试角度对知识体系进行提炼和巩固。
• 关键结论：虚拟线程极大地简化了高并发编程，但不是 WebFlux 的终结者。理解 Pinning 和资源瓶颈是在生产中稳定运行虚拟线程的关键。

---

1. 虚拟线程基本原理与并发模型变革

在深入 Spring Boot 的集成细节之前，我们必须先在 JVM 层面建立对虚拟线程的深刻认知。这是理解后续所有工程行为、性能特征和潜在陷阱的绝对基础。

1.1 用户态线程的回归：M:N 调度

传统 Java 平台线程（Platform Thread）是对操作系统线程的1:1 包装。当我们通过 new Thread(...) 或在池中复用一个平台线程时，JVM 会向操作系统请求一个轻量级进程。这带来了两个直接后果：创建成本高（需分配线程栈，默认约 1MB）和上下文切换代价大（涉及内核态与用户态切换）。我们的 Servlet 容器，无论是 Tomcat 还是 Jetty，其传统并发模型正是建立在这样一个有限的平台线程池之上，详细原理在前文“Servlet 线程模型”中已充分展开。

虚拟线程（Virtual Thread）则是一种用户态线程，由 JVM 而非操作系统负责调度。它与平台线程的关系是 M:N 映射：成千上万个虚拟线程可以挂载（Mount）在少量平台线程上运行。当虚拟线程遇到阻塞操作时，它会被卸载（Unmount），释放其所占用的平台线程，JVM 调度器会立即从挂载队列中取出另一个就绪的虚拟线程继续执行，平台线程便得到了近乎 100% 的利用。

这种调度模型，使得虚拟线程的创建成本极低（一个对象），阻塞成本极低（类似方法调用）。为我们彻底抛弃复杂的线程池提供了可能。

1.2 Thread.ofVirtual（） 与 Continuation 核心

创建虚拟线程的方式非常直观。

// JDK 21
Thread vt = Thread.ofVirtual()
                  .name(“virtual-worker-”， 1）
                  .start(() -> {
                       // 虚拟线程中执行的代码
                  });

这个看似简单的调用背后，是 JVM 底层两个关键机制的协作：

1. VirtualThread 对象：Thread.ofVirtual() 返回一个 Thread.Builder.OfVirtual，最终会构建一个 java.lang.VirtualThread 实例。它本身是一个普通的 Java 对象，占用很小的堆内存。它不持有操作系统线程栈，而是持有一个引用，指向一块堆外内存中可动态伸缩的栈区域。
2. Continuation（续延）：VirtualThread 内部封装了一个 java.lang.Continuation 实例。Continuation 是虚拟线程挂起与恢复的核心机制。它有 yield（） 和 run（） 两个关键操作。
   • run（）：当虚拟线程被挂载到平台线程上时，JVM 执行 Continuation.run（），其代码会从上次 yield 的点或开始处继续执行。
   • yield（）：当虚拟线程执行到阻塞点时，它会调用 Continuation.yield（）。这会保存当前线程的栈帧信息，并将控制权返回给调度器，然后调度器会将当前虚拟线程从平台线程上卸载。

这个挂起和恢复过程完全发生在用户态，无需系统调用，因此性能极高。这也是为何虚拟线程能支撑百万级并发的根本原因。虚拟线程的栈信息不再存储在主线程栈上，而是作为对象存储在 JVM 的堆内存和堆外内存中，大小可动态伸缩，初始通常只有几百字节。

1.3 编程模型的革命：从池化到抛弃

虚拟线程从根本上改变了 JVM 并发的编程范式。

• 平台线程模型（池化）：线程是昂贵的资源，必须放在池中（如 ThreadPoolExecutor）复用。这迫使我们思考：池多大？队列多长？拒绝策略是什么？任何一个请求的处理逻辑，如果阻塞了池中所有线程，服务就会停止响应。这是一种资源受限的编程模型。
• 虚拟线程模型（抛弃）：线程是廉价的一次性资源，可以为每个任务、每个请求创建一个新的虚拟线程。用完即弃，无需池化。这让我们回归到最直观的“每任务一线程”的同步编程方式。代码的可读性、可维护性和可观测性都大幅提升。

flowchart LR
    subgraph Traditional ["平台线程模型"]
        direction LR
        Task1["任务1"] --> PT1["平台线程1"]
        Task2["任务2"] --> PT2["平台线程2"]
        Task3["任务3"] -.->|"线程池已满，等待中"| Queue["等待队列"]
    end

    subgraph Virtual ["虚拟线程模型"]
        direction LR
        VTask1["虚拟任务1"] --> VT1["虚拟线程1"]
        VTask2["虚拟任务2"] --> VT2["虚拟线程2"]
        VTask3["虚拟任务3"] --> VT3["虚拟线程3"]
        VT1 -.->|"挂载"| CPT1["载体平台线程-A"]
        VT2 -.->|"挂载"| CPT2["载体平台线程-B"]
        VT3 -.->|"挂载"| CPT1
    end

    classDef queue fill:#ff99ff,stroke:#333,stroke-dasharray:5 5;
    classDef carrier fill:#add8e6,stroke:#333;
    class Queue queue;
    class CPT1,CPT2 carrier;

图表 1：平台线程模型与虚拟线程模型的并发处理方式对比

• 图表主旨概括：对比平台线程模型的池化和等待队列与虚拟线程模型“每任务一线程”及在少量载体线程上挂载调度的机制。
• 逐层/逐元素分解：
  • 平台线程模型（左）：展示任务（Task）如何被分配给有限数量的平台线程（PT1、PT2）处理。当一个新任务（Task3）到来时，由于平台线程池已满，它无法被立即处理，必须进入队列等待。
  • 虚拟线程模型（右）：展示三个任务（VTask1-3）分别被三个独立的虚拟线程（VT1-3）处理。这三个虚拟线程被动态挂载到两个载体平台线程（CPT-A、CPT-B）上。被阻塞的虚拟线程会被迅速卸载，释放载体线程去执行其他就绪的虚拟线程。
• 设计原理映射：左边是ThreadPoolExecutor的核心行为，资源有限，超出的请求排队。右边是JDK的VirtualThreadScheduler，它以ForkJoinPool为默认载体线程池，实现M：N调度，将阻塞任务的上下文切换到用户态对象队列，效率极高。
• 工程联系与关键结论：平台线程模型强制开发者进行复杂的池大小调优，而虚拟线程模型则从根本上消除了这一负担。理解两种模型的资源占用与调度差异，是构建稳定高并发系统的基础。

2. Spring Boot 3.2 集成：AutoConfiguration 与容器改造

理解了虚拟线程的底层原理，我们来看 Spring Boot 3.2 如何通过“一行配置”将这些能力注入到整个 Web 技术栈中。其设计的优雅之处在于，它没有修改 Servlet API，而是通过容器的扩展点，在协议处理层悄然完成了线程模型的替换。

2.1 VirtualThreadsAutoConfiguration：一行配置的背后

这一切的起点是 spring.threads.virtual.enabled=true。当在 application.yml 中设置此属性后，Spring Boot 3.2 的自动配置模块 spring-boot-autoconfigure 将激活 VirtualThreadsAutoConfiguration。

// 类： org.springframework.boot.autoconfigure.thread.VirtualThreadsAutoConfiguration
@AutoConfiguration
@ConditionalOnProperty(prefix = “spring.threads”， name = “virtual.enabled”， havingValue = “true”）
public class VirtualThreadsAutoConfiguration {

    // 注入Tomcat的定制器
    @Bean
    @ConditionalOnMissingBean
    @ConditionalOnClass（{ TomcatProtocolHandlerCustomizer.class }）
    public TomcatProtocolHandlerVirtualThreadsCustomizer tomcatCustomizer（） {
        return new TomcatProtocolHandlerVirtualThreadsCustomizer（）；
    }

    // 注入Jetty的定制器
    @Bean
    @ConditionalOnMissingBean
    @ConditionalOnClass（{ JettyThreadPoolCustomizer.class }）
    public JettyVirtualThreadsCustomizer jettyCustomizer（） {
        return new JettyVirtualThreadsCustomizer（）；
    }

    // 注入SimpleAsyncTaskExecutor定制的VirtualThreadTaskExecutorBuilder
    @Bean
    @ConditionalOnMissingBean
    public VirtualThreadTaskExecutorBuilder virtualThreadTaskExecutorBuilder（） {
        return new VirtualThreadTaskExecutorBuilder（）；
    }
}

• 源码解读：
  • @ConditionalOnProperty 是整个魔法的开关，确保了只有在明确声明 spring.threads.virtual.enabled=true 时才生效。
  • @ConditionalOnClass 确保只有在对应的容器（Tomcat、Jetty）存在时才创建其定制器，体现了优秀的兼容性设计。
  • VirtualThreadTaskExecutorBuilder 用于构建一个虚拟线程执行器，直接关联了 @Async 注解的执行器。

此配置类本身不执行任何任务，它的角色是一个“插件加载器”，向应用上下文注入了关键的 Customizer Bean。这些 Bean 将在容器的定制阶段被调用。

2.2 Tomcat：从 maxThreads 的禁锢中解放

传统 Tomcat 的核心线程模型基于 org.apache.tomcat.util.threads.ThreadPoolExecutor，其配置项 server.tomcat.threads.max 一直是 Tomcat 并发调优的核心。启用虚拟线程后，这一切被重构。

Tomcat 改造源码分析（TomcatProtocolHandlerVirtualThreadsCustomizer）

// 类： org.springframework.boot.autoconfigure.thread.TomcatProtocolHandlerVirtualThreadsCustomizer
public class TomcatProtocolHandlerVirtualThreadsCustomizer
        implements TomcatProtocolHandlerCustomizer<Http11Nio2Protocol> {

    @Override
    public void customize（Http11Nio2Protocol protocolHandler） {
        // 关键调用： 为ProtocolHandler设置一个虚拟线程执行器
        protocolHandler.setExecutor（Executors.newVirtualThreadPerTaskExecutor（））；
    }
}

当这个定制器被调用时，它会直接替换整个 ProtocolHandler 的执行器。

• Http11Nio2Protocol：这是 Tomcat 的 NIO 协议处理器，负责接收和管理网络连接。它的 setExecutor 方法允许开发者提供一个自定义的 java.util.concurrent.Executor。
• Executors.newVirtualThreadPerTaskExecutor（）：这是 JDK 21 提供的工厂方法，返回一个 ExecutorService，当调用其 execute（Runnable） 方法时，会为每个 Runnable 创建一个新的虚拟线程来执行。
• 设计意图与影响：标准线程池（StandardThreadExecutor）的 execute 方法是将任务提交给内部的平台线程池。替换后，Tomcat 的 Acceptor 线程收到 Socket 连接并封装为任务后，会直接调用这个新执行器的 execute 方法。这意味着每个 HTTP 请求都将在一个全新的虚拟线程中处理。server.tomcat.threads.max 配置对此执行器完全失效。

需要注意的是，尽管每请求一线程的并发度无上限，但 maxConnections 等连接层面的限制依然有效。当连接数超过此值时，新的 TCP 连接将被拒绝或等待，防止服务端被连接本身压垮。虚拟线程解决的是 已建立连接 的请求处理并发度问题。

2.3 Jetty：QueuedThreadPool 的虚拟化重生

Jetty 的线程模型由 org.eclipse.jetty.util.thread.QueuedThreadPool 主导。Spring Boot 的 JettyVirtualThreadsCustomizer 同样对其进行了手术式替换。

// 类： org.springframework.boot.autoconfigure.thread.JettyVirtualThreadsCustomizer
public class JettyVirtualThreadsCustomizer implements JettyThreadPoolCustomizer {

    @Override
    public void customize（QueuedThreadPool pool） {
        // 将原有的线程池包装，并设置为使用虚拟线程
        VirtualThreads virtualThreads = new VirtualThreads（pool）；
        pool.setVirtualThreadsExecutor（virtualThreads.getExecutor（））；
        pool.setThreadPoolBudget（null）； // 清理原有预算配置
    }
}

• 源码解读：
  • 它没有完全替换 QueuedThreadPool，而是通过 setVirtualThreadsExecutor 为其“植入”了一个虚拟线程执行器。
  • VirtualThreads 是 Jetty 内置的适配类，它会创建 ExecutorService，内部调用 Thread.ofVirtual（）。start（...）来执行任务。
  • pool.setThreadPoolBudget（null） 清空了对平台线程数量的预算控制，因为虚拟线程的创建成本极低，不再需要这种限制。

改造后的 Jetty 在内部任务调度时，会优先或完全使用虚拟线程执行器来运行请求处理逻辑，原有基于平台线程的 maxThreads 配置失去意义。与 Tomcat 类似，Jetty 的连接限制（如 acceptors、selectors）和 maxConnections 配置依然生效，是系统保护的真正防线。

sequenceDiagram
    autonumber
    participant C as 客户端
    box "Spring Boot 应用"
        participant AC as Acceptor (Platform Thread)
        participant P as 协议处理器 (Http11Nio2Protocol)
        participant VE as VirtualThreadPerTaskExecutor
        participant VT as Virtual Thread
    end

    C->>+AC: TCP连接请求
    AC->>+P: 建立连接，生成SocketProcessor任务
    P->>+VE: execute(SocketProcessor)
    VE->>+VT: 为SocketProcessor创建并启动新的虚拟线程
    Note over VT: 新虚拟线程挂载到某Carrier Thread上
    VT->>VT: 解析HTTP请求，调用Servlet
    VT-->>-VE: 请求处理完毕，虚拟线程结束
    VE-->>-P: 任务执行完毕

图表 2：虚拟线程环境下 Tomcat 处理 HTTP 请求的完全异步序列

• 图表主旨概括：此序列图完整展示了一个 HTTP 请求从TCP连接到被虚拟线程处理，再到虚拟线程消亡的全过程。
• 逐层/逐元素分解：
  • 客户端（C）与Acceptor（AC）：TCP连接到达，由运行在平台线程上的Acceptor接收并封装为SocketProcessor，此部分是标准Tomcat流程。
  • 协议处理器（P）与执行器（VE）：Http11Nio2Protocol 拿到 SocketProcessor 任务后，不再提交给有限的平台线程池，而是调用被植入的 VirtualThreadPerTaskExecutor。
  • 虚拟线程（VT）的创建与执行：执行器为这个任务瞬间创建一个全新的虚拟线程。此线程由JVM的调度器挂载到某个载体平台线程上运行，处理整个Servlet生命周期。任务完成后，虚拟线程生命期结束，被GC回收。
• 设计原理映射：核心是将Tomcat的任务执行点从“线程池排队”模式切换到“无限并发创建”模式。每个请求的隔离性更强，一个慢请求不再阻塞池中其他请求。代价是失去了线程池对并发度的反压控制。
• 工程联系与关键结论：在虚拟线程模式下，Tomcat处理请求的并发度理论上只受限于JVM堆内存和操作系统资源。传统的 server.tomcat.threads.max 参数完全失效，系统的保护机制前置到了 maxConnections。

3. 异步任务与 HTTP 客户端的虚拟线程化

容器层的线程模型变革会自然地传导至应用层。Spring Boot 3.2 在处理 @Async 这一常用异步注解时，也引入了对虚拟线程的深度支持。

3.1 VirtualThreadTaskExecutor：@Async 的零配置改造

在 Spring Boot 2.x 中，使用 @Async 需要手动配置一个 ThreadPoolTaskExecutor Bean，并精心设置核心/最大线程数、队列容量等参数，否则会使用默认的 SimpleAsyncTaskExecutor，它可能会为每个任务创建一个新线程，导致平台线程耗尽的高风险。

Spring Boot 3.2 及 Spring Framework 6.1 改变了这一局面。当开启虚拟线程后，spring-boot-autoconfigure 会为我们提供一个 VirtualThreadTaskExecutor。

// Spring Framework 6.1 中引入
// 类： org.springframework.core.task.VirtualThreadTaskExecutor
public class VirtualThreadTaskExecutor extends SimpleAsyncTaskExecutor {

    public VirtualThreadTaskExecutor（） {
        super（）；
        // 关键： 使用新的虚拟线程工厂替换SimpleAsyncTaskExecutor原有的工厂
        setThreadFactory（Thread.ofVirtual（）.factory（））；
    }

    @Override
    public void execute（Runnable task） {
        // 调用父类SimpleAsyncTaskExecutor的execute方法
        // SimpleAsyncTaskExecutor会使用其内部的ThreadFactory为每个任务创建一个新线程
        // 此处，工厂被设置为Thread.ofVirtual（）.factory（），所以创建的是虚拟线程
        super.execute（task）；
    }

    // submit等方法同理
}

• 源码解读：
  • 继承关系：它继承自 SimpleAsyncTaskExecutor。在传统模式下，SimpleAsyncTaskExecutor 是危险的，因为它为每个任务创建一个新的平台线程。
  • 质变点：VirtualThreadTaskExecutor 的构造器中，将 SimpleAsyncTaskExecutor 内部的 ThreadFactory 替换为了 Thread.ofVirtual（）。factory（）。这个工厂生产的不是平台线程，而是虚拟线程。
  • 化腐朽为神奇：这个简单的替换，解除了 “每任务一线程” 在成本上的诅咒。SimpleAsyncTaskExecutor “用完即弃” 的行为模式，反而成了虚拟线程最理想的实践方式。它无需池化，天然适配“为每个异步任务创建专用虚拟线程”的模型。

使用示例：

@Service
public class MyService {
    @Async
    public void asyncVirtualTask（） {
        String threadName = Thread.currentThread（）.toString（）；
        // 预期输出类似： VirtualThread[task-1，5，main]
        System.out.println（“执行中： ” + threadName）；
        // 模拟IO阻塞，此时虚拟线程被卸载，平台线程可另作他用
        Thread.sleep（Duration.ofSeconds（1））；
    }
}

在日志中，我们会看到线程名包含 VirtualThread 前缀，表明任务正运行在虚拟线程上。

3.2 RestTemplate 的受益与 WebClient 的“伪并发”

虚拟线程改变了上层 HTTP 客户端的行为模式。

• RestTemplate：它是一个同步阻塞的 HTTP 客户端。在平台线程模式下，一个 RestTemplate 调用就会阻塞一个平台线程。启用虚拟线程后，RestTemplate 的调用依然阻塞，但它阻塞的是廉价且动态度高的虚拟线程。此虚拟线程会被卸载，其占用的载体平台线程立即被释放去运行其他任务。因此，我们可以在同步编程范式下，轻松发起成千上万个并发 HTTP 调用而不耗尽服务器线程资源。RestTemplate 的基础设施，如 JdkClientHttpRequestFactory（基于 java.net.http.HttpClient），其内部的异步线程模型也会与虚拟线程更好地协作，或直接响应底层虚拟线程的阻塞动作。

• WebClient：它是响应式编程的产物，基于事件循环和非阻塞 IO。将其与虚拟线程结合使用时需要格外小心。

  • 错误实践：在一个虚拟线程中调用 webClient.get（）.uri（...）。block（）。这使得虚拟线程在处理一个本应是异步非阻塞的工作流时，被 block 操作强制挂起。虽然这不会阻塞平台线程，但凭空浪费了一个虚拟线程实例，并引入了不必要的上下文切换。这是一种“伪并发”，没有发挥出 WebClient 的优势。
  • 正确实践：要么全链路使用 WebClient 的响应式链，彻底摆脱线程阻塞；要么在固有同步的代码路径中使用 RestTemplate 以拥抱虚拟线程带来的便利。在一个以虚拟线程为主的应用中，混合使用非阻塞客户端并频繁调用 block（） 是一种反模式。

4. 虚拟线程对数据库连接池与 ThreadLocal 的冲击

当请求处理不再受线程数限制时，新的瓶颈迅速向下层资源转移。首当其冲的便是数据库连接池。

4.1 连接池：从线程瓶颈到连接瓶颈的雪崩

传统的性能调优经验中，有一条黄金法则：数据库连接池大小 ≈ 平台线程数。因为每个线程都可能因等待数据库连接而阻塞，太多线程争夺少量连接会造成大量阻塞和上下文切换。

在虚拟线程模型中，这条法则彻底被颠覆。假设我们有一个 maximumPoolSize=10 的 HikariCP 连接池，而由于流量突然涌入，Tomcat 同时激活了 10000 个虚拟线程来处理请求。这 10000 个虚拟线程很快都会执行到需要获取连接的业务逻辑，调用 HikariCP.getConnection（）。结果将是：10 个线程成功获取连接并执行，而剩下的 9990 个虚拟线程全部阻塞在 getConnection（） 的 Semaphore 或 Lock 上。

• 后果：虽然这些虚拟线程阻塞不占用平台线程，但它们作为 Java 对象，占用着堆内存和栈内存。短时间内创建数百万个这样的阻塞虚拟线程，会消耗大量内存，并可能引发 OutOfMemoryError。同时，请求的延迟会急剧升高，远超接受范围。
• 解决方案：
  1. 限流（Semaphore/Resilience4j）：这是最推荐的方案。在访问数据库的业务逻辑入口，引入一个 java.util.concurrent.Semaphore，其许可证数量等于或略大于数据库连接池大小。虚拟线程在执行数据库逻辑前，必须先 acquire 许可证。这为数据库访问提供了有效的并发度反压，保护了连接池，也限制了阻塞的虚拟线程总数。
  2. 扩大连接池：在数据库能承受的范围内，适当增加连接池大小（例如，从10增加到100）。但这治标不治本，当并发量再提高一个量级时，瓶颈依然存在。
  3. 异步数据库驱动：使用如 R2DBC 的响应式数据库驱动，与 WebFlux 结合才是实现端到端非阻塞、解决此类背压问题的终极方案。虚拟线程不直接解决这个问题。

4.2 ThreadLocal：成本降低后的新陷阱

ThreadLocal 是实现请求级上下文传递（如用户信息、事务 ID）的核心工具。传统上，由于平台线程数量有限且被池化复用，ThreadLocal 的内存占用相对可控，但必须在请求结束时显式清理，否则可能导致内存泄漏或线程下次复用时读到脏数据。

虚拟线程的出现改变了 ThreadLocal 的成本结构：

• 优势：虚拟线程的生命周期与请求严格绑定。请求结束，虚拟线程会被回收，其持有的 ThreadLocalMap 也会随之被 GC，彻底消除了跨请求的脏数据风险和内存泄漏风险。开发者不再需要那么小心翼翼地在 finally 块中调用 remove（）。
• 新陷阱：低成本导致的高数量，会放大内存占用风险。 每个 ThreadLocal 变量在数百万个虚拟线程中都会存有一份副本。如果变量引用的对象较大（如一个大 Map），这些副本占用的总内存将非常可观。因此，我们仍需谨慎评估存储在 ThreadLocal 中的对象大小，避免存放过多的、过大的数据。

4.3 MDC 与链路追踪的平稳过渡

SLF4J 的 MDC（Mapped Diagnostic Context）底层正是基于 ThreadLocal。由于每个虚拟线程都继承有独立的线程本地存储，MDC 在虚拟线程环境下完全有效且正确。当为每个请求创建一个虚拟线程时，我们在 Filter 中设置的 MDC.put（“traceId”，...） 会自然地限定在当前请求的虚拟线程内。

然而，当涉及父子任务间传递上下文时，比如在虚拟线程中提交一个异步任务，ThreadLocal 的值并不会自动继承。此时，需要使用像阿里开源的 TransmittableThreadLocal（TTL）来解决跨线程上下文传递的问题。TTL 通过在执行任务提交和运行时的特定时机，对 ThreadLocal 的值进行快照和重放，实现上下文无损传递，它在虚拟线程环境下同样有效。

5. 虚拟线程 vs WebFlux：简化并发的边界与取舍

这是架构师面对的最核心的决策冲突。前文“WebFlux 的响应式线程模型与背压机制”详细阐述了其事件循环和响应式流的原理，此处我们与虚拟线程进行系统性的对比。

5.1 编程模型简化 vs. 背压控制缺失

• 虚拟线程（命令式同步）：

  • 优势：代码直观、易于编写、调试和排错。Debugger 能直接停在阻塞点上，堆栈信息清晰完整。迁移现有 Servlet 应用几乎零成本。
  • 劣势：完全缺乏对数据流的背压控制。当一个虚拟线程作为生产者向另一个消费者虚拟线程推送数据时，如果生产速度大于消费速度，数据会在消费者端的某个缓冲区（如内存 List、Queue）无限堆积，最终导致 OutOfMemoryError。它解决的是“为每个请求分配一个线程”的问题，但不解决“在一个请求内，如何处理上游洪水般的数据”的问题。

• WebFlux（响应式流）：

  • 优势：内建端到端的背压。通过 request（n） 信号，消费者可以精确控制生产者的速率，实现资源友好的流式处理。在网关、流媒体处理等场景优势明显。
  • 劣势：学习曲线陡峭，调试复杂，异常栈图难以阅读。需要从数据库驱动到 HTTP 客户端全链路非阻塞的生态支持，改造现有项目成本高。

5.2 百万并发下的资源消耗对比

让我们建立一个理论模型，对比两者在 1M 个长连接 场景下的资源占用。

• WebFlux 模型：假设使用 Netty，核心线程数等于 CPU 核数（例如16个）。1M 个连接对应 1M 个 Channel，每个 Channel 关联一些 ByteBuf 和一些回调对象。

  • 线程数：约 16 个。
  • 内存消耗：主要来自打开的 Channel 和少量缓冲区。一个空闲 Channel 可能占用几 KB，1M 个连接大约需要数 GB 的内存。内存消耗随连接数线性增长。

• 虚拟线程模型：1M 个连接对应 1M 个虚拟线程。

  • 线程数：1，000，000 个 VirtualThread 对象。
  • 内存消耗：每个虚拟线程对象开销加动态栈，在空闲或阻塞时，初始消耗极小（约几百字节）。1M 个虚拟线程的堆内存和栈内存总和可能在 1-2 GB 的水平。内存消耗同样随连接数线性增长。

flowchart LR
    subgraph VirtualModel ["虚拟线程模型： 1M 连接"]
        direction LR
        CPU1["CPU Core"]
        Carrier1["~16 Carrier Threads"]
        VTs1["1M VirtualThread对象"]
        CPU1 --- Carrier1 --- VTs1
    end

    subgraph WebFluxModel ["WebFlux模型： 1M 连接"]
        direction LR
        CPU2["CPU Core"]
        EL["~16 EventLoop Threads"]
        CHs["1M Channel对象"]
        CPU2 --- EL --- CHs
    end

    classDef vt fill:#f9f,stroke:#333;
    classDef ch fill:#90ee90,stroke:#333;
    class VTs1 vt;
    class CHs ch;

图表 3：在 1M 并发连接场景下，虚拟线程模型与 WebFlux 模型的资源占用对比

• 图表主旨概括：直观对比在百万级连接下，虚拟线程模型维护百万个线程对象，而 WebFlux 模型维护百万个连接道Channel对象，两者底层都依赖少量载体/事件循环线程。
• 逐层/逐元素分解：
  • 虚拟线程模型（左）：拥有大量 VTs 对象，但都挂载在少量载体线程上。内存开销是百万个 VirtualThread 实例。
  • WebFlux 模型（右）：拥有大量 CHs 对象，由少量事件循环线程管理。内存开销是百万个 Netty Channel实例。
• 设计原理映射：两者在此场景下的资源消耗是同一量级。真正的硬件瓶颈都会落在网络 I/O、文件描述符等方面。虚拟线程并未在此展现出对响应式模型的数量级优势。
• 工程联系与关键结论：在纯 I/O 密集型长连接场景下，虚拟线程和 WebFlux 的资源效率是接近的。虚拟线程通过更友好的编程模型提供了类似的扩展能力。真正的性能鸿沟在于背压控制。

5.3 决策框架：何时选择何种模型

这是一个清晰的决策框架：

1. 优先选择虚拟线程：

   • 项目是传统的 Servlet 应用，团队不熟悉响应式编程。
   • 业务是典型的请求-响应式 IO 密集型 CRUD，请求处理链中无数据流“生产-消费”失配问题。
   • 主要目标是简化并发，用同步代码编写高并发业务逻辑。

2. 优先选择 WebFlux：

   • 业务核心是流式数据处理，如 API 网关、文件上传/下载代理、实时消息管道，需要对数据流进行精细的背压控制。
   • 需要极低的资源开销和可预测的性能，延迟在纳秒级波动都不能接受。
   • 团队已经熟练掌握 Reactor 或 RxJava。

3. 可以共存：

   • 在一个系统中，可以部分模块用 Spring MVC + 虚拟线程处理 CRUD，另一些模块用 WebFlux 处理流处理。通过 Spring Cloud Gateway（WebFlux）做网关，后面是虚拟线程驱动的微服务，这是一种现代且强大的组合。

6. Pinning、资源耗尽与性能陷阱

虚拟线程的“无限并发”能力，会在特定的编程模式下，遇到无声的杀手：Pinning。

6.1 Pinning：并发度的无声杀手

虚拟线程的设计允诺是，当遇到 IO 阻塞时，它会卸载，释放其载体平台线程。但这个承诺有例外，最大的例外就是 synchronized 关键字。

• 现象：当一个虚拟线程在持有某个对象的管程（Monitor）时，若发生 IO 或等待，该虚拟线程会被固定在其载体平台线程上，无法卸载。
• 根因：在早期 JVM 实现中，要安全地从一个被 synchronized 保护的区域卸载线程，技术上非常复杂。HotSpot VM 选择了更保守但更简单的方案：在 synchronized 块或方法内阻塞时，保持虚拟线程与载体线程的绑定。Object.wait（） 调用则会触发卸载。
• 灾难性后果：假设我们的 Servlet 容器载体线程池有 16 个平台线程。如果一段业务代码包裹在 synchronized 方法中，并在内部执行了一个耗时的远程 RestTemplate 调用。当同时有 17 个请求到达时，前 16 个虚拟线程会被固定，全部阻塞在远程调用上，占满了所有 16 个载体线程。第 17 个虚拟线程及之后的所有请求，即使它们是纯计算任务，也因为没有可用的载体线程而无法执行。CPU 会非常空闲，但服务已完全假死，新的请求无法得到任何处理。

6.2 检测与修复

检测 Pinning 是解决问题的第一步。

• JVM 启动参数：使用 -Djdk.tracePinnedThreads=full。当发生 Pinning 时，JVM 会在标准错误输出中打印完整的栈跟踪，精确指出哪个方法的哪个 synchronized 块导致了问题。
• jcmd 诊断：也可以使用 jcmd <pid> Thread.dump_to_file 来分析线程栈，观察是否有大量固定在同一个载体线程上的虚拟线程。

修复方法：最直接的方式是将引起 Pinning 的 synchronized 块或方法，替换为 java.util.concurrent.locks.ReentrantLock。

// 错误示例：Pinning的根源
public synchronized String remoteCall（） {
    return restTemplate.getForObject（“http：//slow-service/api”， String.class）；
}

// 正确示例：使用ReentrantLock
private final ReentrantLock lock = new ReentrantLock（）；

public String remoteCallFixed（） {
    lock.lock（）；
    try {
        return restTemplate.getForObject（“http：//slow-service/api”， String.class）；
    } finally {
        lock.unlock（）；
    }
}

ReentrantLock 的实现基于 AbstractQueuedSynchronizer，其阻塞行为 JVM 可以安全地处理，允许虚拟线程在等待锁时被卸载。

sequenceDiagram
    autonumber
    participant VT1 as 虚拟线程1
    participant PTA as 载体平台线程A
    participant Lock as "被synchronized保护的对象"
    participant VT2 as 虚拟线程2

    VT1->>PTA: 挂载执行
    PTA->>+Lock: 进入synchronized块，获得锁
    Note over VT1, PTA: 1. 代码执行到RestTemplate调用，IO阻塞
    Note over PTA, Lock: 关键点： VT-1因持有管程被 "Pin" 在PT-A上
    PTA-->>PTA: 阻塞，无法执行其他虚拟线程
    Lock-->>-PTA: (RestTemplate调用结束) 退出synchronized
    Note over PTA: 2. PT-A解除Pinned状态，恢复
    VT1->>PTA: 卸载

    VT2--xPTA: VT-2就绪，但因PT-A被Pinned而无法被调度执行

图表 4：synchronized 导致虚拟线程在载体线程上固定的 Pinning 过程

• 图表主旨概括：该序列图清晰地揭示了当一个虚拟线程在 synchronized 块内部发生阻塞时，如何导致其与载体平台线程绑定，并阻止其他任何虚拟线程复用该载体线程的连锁过程。
• 逐层/逐元素分解：
  • 进入临界区：虚拟线程1挂载到载体平台线程A上，并进入一个synchronized代码块，获得了Java对象锁。
  • Pinning发生：当在这个synchronized块内执行到阻塞操作时，JVM不会将虚拟线程1从载体线程A上卸载。载体线程A与虚拟线程1被“钉”在一起，陷入阻塞。
  • 后果：即使任务队列中有其他就绪的虚拟线程（如VT-2），它们也无法挂载到被占用的载体平台线程A上。如果所有载体线程都发生Pinning，整个系统的虚拟线程调度将完全停滞。
• 设计原理映射：这是一个JVM实现层面的限制。为了避免JVM自身的难以处理的并发问题，HotSpot选择在持有重量级Monitor时，不执行危险的线程栈切换操作。
• 工程联系与关键结论：Pinning是虚拟线程在生产环境中最隐蔽、最具破坏性的问题。它会导致在高并发下，CPU使用率极低但服务完全无响应。排查此类问题时，首要任务是检查堆栈分析中的 synchronized 用法和使用 -Djdk.tracePinnedThreads 进行诊断。

6.3 其他资源瓶颈：文件描述符与堆外内存

虚拟线程的“无限创建”会使隐藏的操作系统瓶颈暴露得更快。

• 文件描述符：每个 Socket 连接都消耗一个文件描述符。在 Linux 系统中，其上限由 ulimit -n 控制（通常是 1024 或 4096）。在平台线程池模式下，有限的线程数（如 200）天然限制了并发连接数，很难触及此上限。但当虚拟线程能支撑成千上万连接时，如果这些连接都是活动的 TCP 长连接，很容易就超出了文件描述符限制，导致 Too many open files 错误。此时即便应用未崩溃，也无法建立新连接。
• 堆外内存（Direct Memory）：虚拟线程的动态栈存储在堆外内存中。大量阻塞的虚拟线程会不断分配堆外内存以扩展其栈。如果堆外内存被耗光，也会引发 OutOfMemoryError，其现象可能与堆内存溢出混淆。

7. 生产事故排查专题

7.1 事故一：synchronized 引发的全服务假死

• 现象：某日上线一个基于 Spring Boot 3.2 的新服务，使用了虚拟线程。晚高峰开始后，服务监控显示 CPU 利用率从 40% 骤降至 2%，但 JVM 进程依旧存活，所有接口的门户端响应超时，服务全面假死。接口 QPS 很高，但无任何正常响应。
• 排查思路：
  1. 查看 CPU：CPU 空闲，说明不是密集型计算导致的问题。
  2. 查看线程：通过 jcmd <pid> Thread.dump_to_file 导出线程转储文件。分析发现，平台线程池的所有线程几乎都处于 RUNNABLE 或 BLOCKED 状态。更关键的是，大量 VirtualThread 栈信息固定在少数几个平台线程上。
  3. 分析堆栈：这些被固定的栈顶部，无一例外都指向了一个工具类方法 com.xxx.ExternalApiClient.getUserInfo（），此方法被 synchronized 修饰。方法内部调用了 RestTemplate 向一个第三方用户服务发起 HTTP 请求。
  4. 验证猜想：使用 -Djdk.tracePinnedThreads=full 重启服务进行压测，日志中立刻刷出大量 Pinning 警告，定位到相同方法。
• 根因：大量并发请求争用 ExternalApiClient 实例的 synchronized 锁。获得锁的虚拟线程在执行耗时的 HTTP 调用时被固定，所有 16 个载体线程很快都被这些固定的虚拟线程占满。JVM 的虚拟线程调度器无法将任何新的、或需要继续执行被阻塞任务的虚拟线程挂载到载体线程上，导致所有请求处理停滞。
• 解决方案：紧急修复，将 ExternalApiClient.getUserInfo 上的 synchronized 关键字替换为 ReentrantLock，并重新部署。系统恢复后，CPU 恢复正常，假死现象消失。
• 最佳实践：在虚拟线程环境下，必须进行全代码扫描，将任何可能在内部包含阻塞操作的 synchronized 方法或块，替换为 ReentrantLock。建立 SOP：部署前使用 -Djdk.tracePinnedThreads=full 进行充分的压力测试，确保无高频 Pinning 事件。

7.2 事故二：数据库连接池耗尽导致的雪崩

• 现象：一个查询服务，开启虚拟线程后，日常运行平稳。在一次营销活动期间，瞬时流量飙升 20 倍。服务开始有部分成功、部分失败，随后所有请求都开始失败，大量返回 HTTP 500 错误，错误信息为：Failed to obtain JDBC Connection； nested exception is org.hikari.pool.PoolBase$RequestTimeoutException： Connection is not available， request timed out after 30000ms。服务监控显示，JVM 存活，CPU 和内存未见明显异常，但数据库侧毫无压力。
• 排查思路：
  1. 检查错误日志：直接指明是获取数据库连接超时。
  2. 检查连接池配置：HikariCP 配置的 maximumPoolSize 为 10，connectionTimeout 为 30 秒。
  3. 分析请求量：当前活跃请求数是平日的数十倍。在虚拟线程模式下，瞬间产生了数万个虚拟线程去处理请求，这些线程都执行到了数据库查询逻辑，从而阻塞在 HikariCP.getConnection 上。
  4. 定位瓶颈：数据库连接池只有 10 个连接，导致 99.9% 的虚拟线程在长时间等待，最终超时失败。大量虚拟线程仅因获取连接这一个操作而堆积，耗费了内存。
• 根因：虚拟线程的无限制并发特性，使得积压在数据库连接获取这一环节的并发度与请求并发度完全相等，而不再是过去的“线程数 ≈ 最大等待数”。数据库连接池成为了整个系统新的、最突出的瓶颈，就像一个无限吞噬请求却只有一根细管输出的漏斗。
• 解决方案：
  1. 紧急措施：在数据库访问层之前，引入一个 Semaphore 限流器，许可证数量设置为 10（略大于连接池）。所有数据库访问逻辑必须先 acquire 到许可证。此举有效地将“等待数据库”的虚拟线程数限制在了一个极低的水平，恢复了系统的处理能力。
  2. 长期方案：对数据库访问进行更细致的资源隔离和熔断降级，使用 Resilience4j 的 Bulkhead 模式，针对不同业务给予不同的并发许可证配额。
• 最佳实践：迁移到虚拟线程后，必须重新审视所有有界资源（数据库连接池、Redis 连接池、第三方 API 客户端等）。必须在应用层引入限流机制（如 Semaphore 或专门的熔断器），作为保护后端资源的阀门，取代过去线程池所扮演的角色。

8. 面试高频专题

1. 【基础】虚拟线程和平台线程的本质区别是什么？

   • 回答：本质区别在于调度权的归属和映射关系。平台线程是操作系统资源的 1:1 包装，由内核调度，创建和切换成本高。虚拟线程是 JVM 内部管理的用户态线程，由 JVM 调度器在少量平台线程上执行 M：N 调度，创建和阻塞成本极低。
   • 追问：这种调度差异如何影响应用的并发能力？为什么虚拟线程不能被池化？虚拟线程的栈是怎么存储的？

2. 【框架】Spring Boot 3.2 是如何支持虚拟线程的？背后改了哪些组件？

   • 回答：通过 VirtualThreadsAutoConfiguration 类，受 spring.threads.virtual.enabled=true 控制。它注册了定制器，将 Tomcat 的 ProtocolHandler 执行器、Jetty 的 ThreadPool 执行器替换为创建虚拟线程的执行器，并将 @Async 的默认执行器等替换为 VirtualThreadTaskExecutor。
   • 追问：如果我自己定义了 TaskExecutor，虚拟线程的自动配置会怎样？server.tomcat.threads.max 在虚拟线程下还起作用吗？@Scheduled 会不会也用上虚拟线程？

3. 【框架】开启虚拟线程后，Tomcat 的线程池配置还有效吗？为什么？

   • 回答：无效。因为 TomcatProtocolHandlerVirtualThreadsCustomizer 调用了 protocolHandler.setExecutor（...），用一个 VirtualThreadPerTaskExecutor 替换了原有的基于 ThreadPoolExecutor 的 StandardThreadExecutor。原有的 maxThreads 参数是配置 ThreadPoolExecutor 的，新执行器无此概念。
   • 追问：那 maxConnections 还有效吗？如果我想限制并发处理的请求数，现在该怎么做？

4. 【陷阱】什么是虚拟线程的 Pinning？什么情况下会发生？

   • 回答：Pinning 指虚拟线程在特定阻塞操作时无法从其载体平台线程上卸载，被“固定”了。主要发生在运行在 synchronized 块或方法、或执行 JNI 调用时发生阻塞。
   • 追问：为什么 JVM 不解决 synchronized 的 Pinning 问题？ReentrantLock 为什么没有 Pinning 问题？如何检测生产环境中的 Pinning 现象？

5. 【架构】虚拟线程能不能取代 WebFlux？为什么？

   • 回答：不能完全取代。虚拟线程用同步模型简化了高并发连接的编程，解决了“请求处理”层面的线程阻塞问题。但它无法提供响应式模型中内建的、端到端的数据流背压控制。在网关、流处理等场景中，WebFlux 的背压能力至关重要。
   • 追问：如果我的新项目是一个超高并发的 CRUD 后端，选什么？如果项目是一个核心业务网关，向不同下游转发并聚合数据，流量峰值高且下游响应速度不一，选哪个？

6. 【数据库】在虚拟线程环境下，数据库连接池应该怎么配置？

   • 回答：不能简单地将连接池大小调得很大。核心是在数据访问层入口增加应用级并发控制，如 Semaphore，限制同时访问数据库的虚拟线程数，使其与连接池大小匹配。这样能避免所有线程都阻塞在抢连接上。
   • 追问：HikariCP 的 maximumPoolSize 应该如何设定？Semaphore 的许可数是否一定要等于连接池大小？如果使用 R2DBC 还会不会有这个问题？

7. 【核心技术】ThreadLocal 在虚拟线程中还能用吗？有什么潜在问题？

   • 回答：能用，且更安全，因为线程生命周期与请求绑定，不会出现脏数据。但潜在问题是内存占用。因为可以创建海量虚拟线程，每个线程里的 ThreadLocal 值都会占用一份内存，需要警惕存储大对象的场景。
   • 追问：在虚拟线程中，MDC 还能正常工作吗？如果在虚拟线程内启动子虚拟线程，或用 @Async，ThreadLocal 怎么传递上下文？

8. 【异步】使用虚拟线程后，@Async 方法的执行有什么变化？

   • 回答：@Async 默认使用的 VirtualThreadTaskExecutor 会为每个 @Async 方法调用创建一个新的虚拟线程去异步执行，不再是有限的平台线程池。
   • 追问：这意味着可以无限用 @Async 而不会 OOM 了是吗？（引导其回答还有其他资源瓶颈）。CompletableFuture 和虚拟线程结合的最佳实践是什么？

9. 【排错】如何检测和诊断虚拟线程的 Pinning 问题？

   • 回答：使用 JVM 参数 -Djdk.tracePinnedThreads=full，在发生 Pinning 时输出栈到标准错误流。可使用 jcmd <pid> Thread.dump_to_file 分析平台线程状态，观察是否有大量 VirtualThread 被固定。
   • 追问：如果忘记加那个参数，线上假死了怎么办？可以从堆转储里看出来吗？有没有 Java Agent 之类的工具可以动态开启？

10. 【客户端】RestTemplate 和 WebClient 在虚拟线程模式下谁更受益？

    • 回答：RestTemplate 更直接受益。它的核心痛点是同步阻塞，而虚拟线程完美解决了阻塞对平台线程的消耗，让同步代码也能获得高并发。WebClient 作为非阻塞库，在虚拟线程中使用并调用 block（） 是一种反模式，它削弱了非阻塞的价值，造成了伪并发。
    • 追问：如果我用 WebClient 但保证全链路非阻塞，和用 RestTemplate+虚拟线程，哪个性能更好？从代码的可维护性看，你推荐哪个？

11. 【底层】虚拟线程的栈内存是如何管理的？为什么它比平台线程更轻量？

    • 回答：平台线程的栈是操作系统在创建线程时预分配的一块连续内存区域，通常 1MB。虚拟线程的栈存储在堆外内存中，由 Continuation 对象管理，可以按需动态增加和缩小，初始只有几百字节。它不需要预分配巨大空间。
    • 追问：这个动态栈在堆外，大量创建会不会导致堆外内存 OOM？虚拟线程的浅堆大小大概是多少？

12. 【系统设计】设计一个基于 Spring Boot 3.2 的高并发 API 网关，它需要向下游微服务转发请求，并且内部需要进行多个外部接口的聚合。要求详细说明在引入了虚拟线程后，哪些地方需要限流保护（如连接池、文件描述符），以及如何避免 Pinning 导致的服务不可用。

    • 回答与解析：
      • 设计概要：网关接收外部请求，对每个请求开启虚拟线程处理。在虚拟线程内，可能需要并发调用多个下游微服务（A， B， C）并聚合结果，再返回给客户端。
      • 限流保护点：
        1. 外部接口聚合：当虚拟线程并发调用 A、B、C 时，相当于在一个请求链路上创建了新的 RestTemplate 调用。这会导致对下游微服务的连接（通常是长连接）和其网关的请求压力。必须为调用每个下游服务的 RestTemplate 配备独立的 Semaphore 熔断/限流机制，防止某个服务慢导致当前网关的所有虚拟线程都被拖垮在该服务调用上。
        2. 数据库连接池：如果网关直接查询数据库（不推荐），必须在数据访问层用 Semaphore 限制并发查询数。
        3. 整体并发度：虽然不需要限制线程，但服务器端口和文件描述符有上限。需要配置 server.tomcat.max-connections，并设置合理的 ulimit -n，防止连接数暴增导致服务“Too many open files”。
      • 避免 Pinning 陷阱：
        1. 强制代码规范：在编码规范中明确禁止在包含网络/IO调用的路径上使用 synchronized。
        2. 静态检查：引入 SonarQube 或 ArchUnit 规则，在 CI/CD 阶段静态扫描对 synchronized 方法/块的使用。
        3. 启动与压测必选参数：将 -Djdk.tracePinnedThreads=full 加入生产 JVM 参数。在每次上线前的压测中，必须分析此日志，确保 Pinning 事件为零。
        4. 使用无锁或无阻塞工具：在聚合结果时，使用 CompletableFuture.failedFuture / newFuture 等非阻塞并发工具进行编排，而不是同步等待。
    • 追问：网关的线程模型是 1 个请求对应 1 个虚拟线程，那内部的聚合任务如何更好并发？如果下游是 WebFlux 服务，网关用 RestTemplate+虚拟线程调用它好吗？服务的超时控制链条怎么设计？

---

虚拟线程核心配置与参数速查表

分类	配置项/参数	作用	适用条件/说明
基础开关	spring.threads.virtual.enabled=true	启用Spring Boot对虚拟线程的全面支持	JDK 21+， Spring Boot 3.2+
容器线程池	server.tomcat.threads.max	失效。配置的线程数不再生效	开启虚拟线程后，处理请求使用虚拟线程
容器连接数	server.tomcat.max-connections	有效。限制最大TCP连接数	操作系统管理的第一道防线，须合理配置
异步任务	@Async + VirtualThreadTaskExecutor	为每个异步任务创建新的虚拟线程	自动装配，也可手动创建Executor Bean覆盖
JVM诊断	-Djdk.tracePinnedThreads=full	当发生Pinning时，打印完整线程栈到标准错误输出	生产部署建议默认开启，特别是性能压测阶段
JVM诊断	-Djdk.virtualThreadScheduler.parallelism=N	设置虚拟线程调度器的平台线程并行度	默认是CPU核数，一般无需调整
操作系统	ulimit -n	进程可打开的最大文件描述符数量	需调高，建议≥65535，每个TCP连接消耗一个。
代码替换	synchronized → ReentrantLock	解决虚拟线程Pinning问题的核心修复模式	所有与I/O阻塞操作共存的同步块/方法

---

延伸阅读

1. OpenJDK JEP 425： Virtual Threads （Preview）
2. OpenJDK JEP 444： Virtual Threads - Final release in JDK 21
3. Spring Official Blog： “Embracing Virtual Threads” （Spring Boot 3.2 milestone）
4. Spring Framework 6.1 Reference Documentation： Section on Virtual Threads support.
5. Book： 《Reactive Spring》 by Josh Long - Section comparing coroutines， virtual threads and reactive programming.
6. Article： “An Order of Magnitude Improvement in Throughput with Virtual Threads” （Oracle Inside Java）