第 04 篇 · 线程池与虚拟线程

这道题考察对 ThreadPoolExecutor 七个构造参数语义的精确理解、参数调优的方法论（而非拍脑袋）、以及四种拒绝策略的边界与选型。更深一层，它考察"线程池是一种资源约束机制"的认知——线程池的本质不是"加速"，而是在有限 CPU/内存下对并发任务进行排队与背压，避免瞬时流量压垮系统。

手工 new Thread（JDK 1.0）：每次任务新建线程，创建/销毁开销大，无上限易耗尽资源，无法复用。Doug Lea 在 JSR-166 之前就指出这是并发编程的首要反模式。

Executor 框架（JDK 5，2004）：引入 ThreadPoolExecutor，将"任务提交"与"执行策略"解耦，线程池成为一等公民。同期 Executors 工具类提供 newFixedThreadPool/newCachedThreadPool 等快捷工厂（注：阿里 Java 开发规约禁止使用这些快捷工厂方法，因 newFixedThreadPool/newSingleThreadExecutor 内部用无界队列、newCachedThreadPool 最大线程数为 Integer.MAX_VALUE，存在 OOM 风险，推荐手动构造 ThreadPoolExecutor 显式声明有界队列与最大线程数）。

参数动态化（美团 2016+）：静态参数难以应对流量波动，美团在《Java 线程池实现原理及其在美团业务中的实践》中提出基于配置中心的动态调参方案——将核心/最大线程数、队列容量暴露为可热更新字段，setCorePoolSize 等方法本身是 public 支持运行时修改。

Virtual Threads（JDK 21，2023）：对 IO 密集场景，Executors.newVirtualThreadPerTaskExecutor() 几乎消除"线程数调优"问题——每个任务一个虚拟线程，由 JVM 调度到少量载体线程。这使传统线程池调优的适用范围收窄到 CPU 密集场景，是并发治理的范式转移。

七个构造参数：

调优公式（Brian Goetz 经验法则）：

• CPU 密集型：N + 1（N = CPU 核数）。线程数过多只会增加上下文切换开销，+1 是为了在偶发抖动（如缺页中断）时仍能保持 CPU 满载。
• IO 密集型：N × (1 + WT/ST)（WT = 等待时间，ST = 计算时间）。本质是"让 CPU 在 IO 等待期间切换到其他任务"，比值越大线程越多。注意 WT/ST 难以精确测量，实践中常用 2N~10N 估算，或直接用虚拟线程消除该问题。

// 自定义线程池：拒绝 Executors 工厂方法，显式声明有界队列与拒绝策略
ThreadPoolExecutor pool = new ThreadPoolExecutor(
    8,                                          // corePoolSize：CPU 密集 8 核 +1
    32,                                         // maximumPoolSize：IO 峰值上限
    60L, TimeUnit.SECONDS,                       // 非核心线程空闲 60s 回收
    new LinkedBlockingQueue<Runnable>(2000),        // 必须有界！防止 OOM
    new ThreadFactoryBuilder()                      // Guava：命名线程便于排查
        .setNameFormat("biz-pool-%d").build(),
    new ThreadPoolExecutor.CallerRunsPolicy()       // 拒绝策略：回退到调用线程
);

四种拒绝策略对比：

动态调参方案：将线程池参数托管到配置中心（Apollo/Nacos），监听变更后调用 setCorePoolSize / setMaximumPoolSize 实时生效。线程数是运行期可调参数；队列容量属于队列结构约束，不要通过反射改写 LinkedBlockingQueue.capacity。若确实需要变更容量，应封装可替换执行器：先创建新线程池和有界队列，再原子切换引用、停止接受旧池新任务，并把旧队列中的任务排干后关闭旧池。配合监控大盘观察活跃线程数、队列长度和拒绝次数，形成"监控→调参→验证"闭环。

// 线程数：ThreadPoolExecutor 提供 public setter，可接入配置中心
pool.setCorePoolSize(16);        // 立即生效，多余核心线程会空闲回收，不足会立即创建
pool.setMaximumPoolSize(64);    // 立即生效

// 队列与饱和度：只做观测；容量变更走“新建池 + 原子切换 + 排干旧池”
int queueDepth = pool.getQueue().size();
int saturation = pool.getActiveCount() + queueDepth;
// rejectedCount 由自定义 RejectedExecutionHandler 中的 AtomicLong 累加

追问 1：为什么阿里规约禁止用 Executors 的快捷工厂方法？

newFixedThreadPool 和 newSingleThreadExecutor 内部用 LinkedBlockingQueue（无参构造 = Integer.MAX_VALUE，无界）；newCachedThreadPool 的 maximumPoolSize = Integer.MAX_VALUE。两者在请求堆积时要么 OOM（队列），要么耗尽线程资源（maxThreads）。必须用 ThreadPoolExecutor 显式声明有界队列与最大线程数。

追问 2：核心线程数能否设为 0？最大线程数能否小于核心线程数？

corePoolSize 可设为 0，此时任务先入队，队列满后才创建线程（极端低延迟场景不推荐）。但 maximumPoolSize 必须 >= corePoolSize，否则 ThreadPoolExecutor 构造方法会抛 IllegalArgumentException；运行时若 setMaximumPoolSize 把 max 调到小于 core，会触发 core 自动下调。

追问 3：keepAliveTime 对核心线程生效吗？

默认不生效，核心线程即使空闲也会保留。调用 allowCoreThreadTimeOut(true) 后，核心线程也会在 keepAliveTime 后被回收——适用于流量有明显波谷、希望快速释放资源的场景。但会增加流量回升时的线程创建抖动。

这道题考察两个核心机制：任务提交后的资源分配决策链（核心线程→队列→最大线程→拒绝）与线程池生命周期状态机（RUNNING→SHUTDOWN→STOP→TIDYING→TERMINATED）。前者决定线程池在压力下的行为，后者决定优雅停机与资源回收的正确性。理解这两者，才能回答"为什么用无界队列时最大线程数不生效"和"shutdown 和 shutdownNow 的区别"。

单线程（JDK 1.0）：无状态管理概念，线程创建即运行，销毁即消失，无生命周期抽象。

Executor 框架（JDK 5）：引入 ThreadPoolExecutor 的五状态机，用单个 AtomicInteger ctl 同时编码"状态"和"工作线程数"，是无锁状态管理的经典设计。

ForkJoinPool（JDK 7）：引入工作窃取（work-stealing），任务模型从"外部提交队列"变为"每工作线程一个双端队列"，状态机更复杂但对外 API 仍兼容 ExecutorService。

Virtual Threads（JDK 21）：Executors.newVirtualThreadPerTaskExecutor() 返回的池本质是无界虚拟线程生成器，传统状态机的"核心/最大线程数"概念被弱化，但 shutdown 语义仍保留——这是结构化并发能基于它构建父子生命周期的前提。

任务提交流程（execute 方法决策链）：这是核心，必须按顺序说清。

关键源码逻辑（execute 方法三步）：

// ThreadPoolExecutor.execute 简化逻辑
public void execute(Runnable command) {
    int c = ctl.get();
    // 步骤1：线程数 < corePoolSize，addWorker(core=true) 创建核心线程
    if (workerCountOf(c) < corePoolSize) {
        if (addWorker(command, true)) return;
        c = ctl.get();
    }
    // 步骤2：核心满，入队。isRunning 二次检查状态，若已 shutdown 则移除并拒绝
    if (isRunning(c) && workQueue.offer(command)) {
        int recheck = ctl.get();
        if (!isRunning(recheck) && remove(command))
            reject(command);
        else if (workerCountOf(recheck) == 0)
            addWorker(null, false);  // 防御：核心为0时也建一个线程消费
    }
    // 步骤3：入队失败（队列满），尝试 addWorker(core=false) 扩到 max，失败则拒绝
    else if (!addWorker(command, false))
        reject(command);
}

五状态机与 ctl 设计：ctl 是一个 AtomicInteger，高 3 位存状态、低 29 位存工作线程数，用一次 CAS 同时原子更新两者。这是"用一个 int 编码两个维度"的极致压缩。

优雅停机：应用下线时调用 shutdown()（等待队列任务完成）+ awaitTermination（带超时），超时后 shutdownNow() 强制中断。Spring 的 @PreDestroy / DisposableBean 可接入此流程。

// 优雅停机：先拒绝新任务，等待存量完成，超时强制中断
pool.shutdown();                              // 进入 SHUTDOWN，不再接收新任务
if (!pool.awaitTermination(30, TimeUnit.SECONDS)) {
    pool.shutdownNow();                       // 进入 STOP，中断执行中任务
    if (!pool.awaitTermination(10, TimeUnit.SECONDS))
        System.err.println("线程池未完全终止");
}

线程池预热：prestartAllCoreThreads() 提前创建所有核心线程，避免冷启动时首批任务因线程创建产生抖动——适用于对延迟敏感的网关/交易场景。

追问 1：为什么 ctl 要用一个 AtomicInteger 同时存状态和线程数？

两者高度耦合：状态流转（如 SHUTDOWN 时判断"队列空且线程数 0"）需要原子地读取状态+线程数，若分开用两个变量，CAS 无法保证两者的一致性快照——可能读到 RUNNING 状态但旧的线程数。用一个 int 编码，单次 CAS 即可原子更新，是无锁设计的经典取舍。代价是线程数被限制为 2^29-1（约 5 亿），对线程池场景绰绰有余。

追问 2：SHUTDOWN 状态下还能执行队列里的任务吗？execute 提交的新任务会怎样？

SHUTDOWN 仍会消费队列中已存在的任务（getTask 仍工作），但 execute 提交的新任务会被直接拒绝（调用 reject）。这就是"优雅停机"的语义：让存量跑完，拒绝增量。shutdownNow 则连存量都丢弃并 interrupt 执行中任务。

追问 3：addWorker 失败的常见原因有哪些？

① 状态不满足（如已 STOP，或 SHUTDOWN 且队列为空但传入新任务）；② 线程数已达上限（core 或 max）；③ ThreadFactory 返回 null（工厂实现异常）。addWorker 内部用 CAS 自旋增加 workerCount，再真正 new Thread 启动，启动失败会回滚 workerCount。

从 JDK 原生 ThreadPoolExecutor 到生产级 Web 容器，Tomcat 线程池做了大量定制化设计；而虚拟线程的引入进一步改变了线程池参数的语义，这一层补全两者的整合实践。

• Tomcat 线程池三大核心参数：maxThreads（最大工作线程数，默认 200）控制并发处理能力上限；acceptCount（全连接队列长度，默认 100）是 TCP 完成三次握手后等待 Tomcat 线程接受的积压队列；minSpareThreads（核心线程数，默认 10）保持预热线程。三者关系：连接数 > maxThreads + acceptCount 时新连接被操作系统拒绝。
• Tomcat 自定义 TaskQueue 的反直觉行为：Tomcat 的 org.apache.tomcat.util.threads.TaskQueue 继承 LinkedBlockingQueue，其 offer 方法在线程数未达 maxThreads 时返回 false，迫使 ThreadPoolExecutor 创建新线程而非排队等待——这与原生 ThreadPoolExecutor 的"核心→队列→最大"流程不同，Tomcat 实际行为是"核心→最大→队列"，优先用线程而非积压。
• 拒绝策略：默认 ThreadPoolExecutor.AbortPolicy（抛 RejectedExecutionException），可配置为 CallerRunsPolicy 让提交线程（即 Tomcat Acceptor 线程）自己执行任务，起到背压效果。
• 虚拟线程整合（JDK 21+）：设置 spring.threads.virtual.enabled=true 后，Tomcat 请求处理线程自动切换为虚拟线程，每个请求分配一个 VT，不受 maxThreads 限制（VT 数量可达百万级）。此时 maxThreads 退化为"平台线程数"限制，仅控制载体线程规模。
• VT 的 pinning 陷阱：VT 在 synchronized 块中执行阻塞 IO（如数据库查询、HTTP 调用）时会 pin 到 carrier thread 无法卸载，等效于平台线程，降低吞吐。JDK 21（JEP 444）下 Object.wait 仍钉住，调度器通过临时扩并行度补偿；真正接近可卸载是 JDK 24（JEP 491）对 synchronized pinning 的改造。synchronized + IO 在 JDK 21–23 仍会 pin。
• 混合模式建议：IO 密集型任务用 VT，CPU 密集型任务仍用平台线程池（如 ForkJoinPool），避免 VT 被 CPU 计算长期占用载体线程。
• 生产实践：典型 IO 密集场景下，Spring Boot 3.2 + JDK 21 的收益取决于 IO 等待占比、连接池和下游容量，必须用同一业务压测验证。JDK 21-23 可用 -Djdk.tracePinnedThreads=full 排查 pinning 热点，JDK 24+ 改用 jdk.VirtualThreadPinned JFR 事件。

上线门禁：池大小与队列拒绝策略、VT pinning 检测版本矩阵。表达提纲：饱和现象→队列/载体证据→参数与代码改造。

这道题考察对 ThreadLocal 内部 ThreadLocalMap 的引用链结构的理解——弱引用 Key + 强引用 Value 的不对称设计，以及线程池复用线程场景下 Value 无法回收的根因。更深一层，它引出"线程上下文传递"的演进脉络：ThreadLocal → InheritableThreadLocal → TransmittableThreadLocal → Scoped Values，这是从"线程私有"到"任务透传"再到"结构化作用域"的范式演进。

ThreadLocal（JDK 1.2，1998）：提供线程局部变量，每个线程独立副本。设计初衷是避免参数层层传递，典型用于 SimpleDateFormat 线程安全、数据库连接、用户上下文。但父子线程无法继承。

InheritableThreadLocal（JDK 1.2）：子线程创建时（new Thread 构造方法内）复制父线程的 InheritableThreadLocal 值。但线程池场景失效——线程被复用，只在首次创建时复制一次，后续任务拿不到提交线程的最新上下文。

TransmittableThreadLocal / TTL（阿里开源，2017+）：通过 TtlRunnable.get(runnable) 包装，在任务提交时快照、执行时回放、执行后还原，解决线程池场景的上下文透传。是全链路 TraceId 透传的事实标准。

Scoped Values（JDK 20 incubator；JDK 21 Preview；JDK 25 JEP 506 正式交付）：与结构化并发配套的不可变、有界作用域的值传递机制，用于治理 one-way immutable context 这类 ThreadLocal 滥用。它绑定到结构化作用域的生命周期，作用域结束自动清理；双向更新和线程私有可变缓存仍可能继续使用 ThreadLocal。

引用链结构：每个 Thread 持有一个 ThreadLocalMap，Map 的 Entry 继承 WeakReference，Key 是 ThreadLocal 的弱引用，Value 是强引用。

泄漏根因（双重条件）：

1. ThreadLocal 实例被回收后：栈上的局部变量 TL 出栈，此时 Entry 的 Key（弱引用）指向 null，但 Value 仍被 Entry 强引用，Entry 又被 Thread 的 ThreadLocalMap 强引用。若 Thread 不退出（线程池复用），这条 Thread → ThreadLocalMap → Entry → Value 强引用链永远存在，Value 无法 GC。
2. 线程池场景：核心线程长期存活，泄漏的 Value 持续累积，每个 Value 可能是大对象（如缓存 Map、连接），最终 OOM 或 metaspace 涨。

OpenJDK 的部分缓解：ThreadLocalMap 在 get/set/remove 时会主动清理 Key 为 null 的 Entry（expungeStaleEntry / replaceStaleEntry），但仍无法保证及时清理——若不再调用任何 ThreadLocal 操作，那些 stale Entry 永远不会被触发清理。这是设计权衡（弱引用 Key 避免了 ThreadLocal 本身泄漏，但把泄漏转移到 Value）。

// 反例：忘记 remove，线程池复用导致泄漏与脏数据
class UserController {
    private static final ThreadLocal<UserContext> CTX = new ThreadLocal<>();

    public void handle(Request req) {
        CTX.set(buildCtx(req));     // 设置上下文
        try {
            doBusiness();            // 业务逻辑读取 CTX.get()
        } finally {
            CTX.remove();         // 必须 remove！否则下一个复用此线程的任务读到脏数据 + Value 泄漏
        }
    }
}

四条铁律：

• 用完必 remove：try-finally 模式，finally 块调用 remove。
• 线程池场景用 TTL：用 TransmittableThreadLocal + TtlRunnable/TtlCallable 包装任务，确保上下文跨线程池透传。
• 避免存大对象：ThreadLocal 存 UserContext/TraceId 等小对象，不要存缓存 Map、Connection 等大对象。
• 用 static final 修饰 ThreadLocal：避免 ThreadLocal 实例本身被频繁创建，减少弱引用 Key 提前回收导致的 stale Entry。

// TTL 全链路透传：提交线程的上下文快照到执行线程
class TraceContext {
    private static final TransmittableThreadLocal<String> TRACE_ID
        = new TransmittableThreadLocal<>();

    public void submit(Runnable task) {
        TRACE_ID.set(UUID.randomUUID().toString());
        try {
            // TtlRunnable 在 submit 时快照、run 时回放、finally 还原
            pool.submit(TtlRunnable.get(task));
        } finally {
            TRACE_ID.remove();
        }
    }
}

追问 1：为什么 Key 用弱引用而不是强引用？

若 Key 是强引用，ThreadLocal 实例即使不再被业务代码引用，仍被 ThreadLocalMap 强引用而无法回收——这会让ThreadLocal 对象本身泄漏。用弱引用后，ThreadLocal 实例可被 GC，留下 Key=null 的 stale Entry（Value 仍泄漏）。这是两害相权取其轻：弱引用把"绝对泄漏"降级为"条件泄漏"（需线程退出或主动 remove 才彻底解除）。本质是 OpenJDK 设计者认为"开发者有责任 remove"，框架只做尽力而为的清理。

追问 2：InheritableThreadLocal 为什么在线程池场景失效？

它在 Thread.init（构造方法）时复制父线程的值。线程池中线程是预先创建并复用的，复制只发生在首次创建那一刻，之后提交任务的"提交线程"不是该工作线程的父线程，自然无法继承。TTL 的解法是在任务提交时（而非线程创建时）做快照，绕开了"父线程"概念。

追问 3：虚拟线程对 ThreadLocal 有何影响？

虚拟线程数量可达百万级，若每条线程都保留大量 ThreadLocal 副本，内存开销会被放大。JDK 21 默认仍支持，但 JEP 446（Scoped Values）建议在 one-way immutable context 场景使用 Scoped Values——它的不可变绑定可被同一作用域内的结构化子任务高效共享，内存模型更友好。这是这类上下文从 ThreadLocal 迁出的信号，不是无条件废弃 ThreadLocal。

这道题考察对 Project Loom / JEP 444 的架构级理解：虚拟线程如何把"线程"从"OS 调度单元"解耦为"JVM 调度单元"，从而让同步阻塞式代码获得接近异步回调的吞吐。核心要讲清三件事：平台线程与虚拟线程的本质差异、载体线程与栈在堆上的 unmount/mount 机制、以及 pinning（钉扎）这个最大陷阱。它同时考察架构判断——虚拟线程不是银弹，它解决 IO 密集场景，不解决 CPU 密集场景。

Java 并发模型经历了六代演进，每一代都在解决上一代的"表达力 vs 性能"权衡：

• Thread（JDK 1.0）：1:1 映射 OS 线程，创建/上下文切换由内核完成，开销大（栈 MB 级、切换微秒级），千级已是上限。
• Executor（JDK 5）：线程池复用，解决创建开销，但线程数仍受 OS 限制，IO 等待时线程被阻塞占用。
• ForkJoinPool（JDK 7）：工作窃取提升 CPU 利用率，适合 CPU 密集分治，但仍是平台线程。
• CompletableFuture（JDK 8）：异步回调组合，解决"IO 等待时线程浪费"，但回调地狱破坏可读性、异常处理复杂、调试困难。
• Virtual Threads（JDK 21）：N:M 调度，JDK 调度器把虚拟线程挂载到少量载体线程，遇到可卸载阻塞点时 unmount 而非长期占用载体线程。用同步代码的写法获得异步的扩展性，是并发编程的"回归命令式"。
• Structured Concurrency（JDK 21+ Preview，截至 JDK 26 仍 Preview，与 C04.08 一致）：将并发任务组织成父子树，父任务等待所有子任务，错误与取消自动传播；需 --enable-preview，勿绑核心生产路径。

平台线程 vs 虚拟线程：

unmount/mount 机制（核心原理）：虚拟线程的栈是堆上的 StackChunk 对象。当虚拟线程执行到可卸载阻塞操作（如 socket IO、LockSupport.park）时，JVM 把当前栈帧拷贝出载体线程（unmount），载体线程立即去运行下一个虚拟线程；当 IO 就绪，JVM 把栈帧拷贝回某个载体线程（mount）继续执行。JEP 444 明确当前不为虚拟线程实现 CPU 时间片抢占（time sharing）；CPU 密集任务不会因用完时间片被 JVM 强制换出，只有显式 Thread.yield() 或可卸载阻塞才会交还载体线程。载体线程本身仍由 OS 正常调度。

pinning（钉扎）问题——最大陷阱：并非所有阻塞都能触发 unmount。以下情况虚拟线程会钉扎在载体线程上，无法释放，退化为平台线程行为：

• synchronized 块/方法内的阻塞：synchronized 持有的是 monitor，JVM 当前实现无法在持锁期间 unmount（栈中存了 monitor 状态）。JDK 21 仍存在，JEP 491（JDK 24）已修复。
• 本地方法（JNI）或 Foreign Function 中的阻塞：JVM 无法接管 native 栈。
• 文件 IO（部分）：旧 FileInputStream 阻塞读可能 pinning。

JDK 21-23 可用 -Djdk.tracePinnedThreads=full|short 打印钉扎栈；JDK 24 已移除该系统属性，应改用 jdk.VirtualThreadPinned JFR 事件和新式线程转储。替代方案：JDK 21-23 把 synchronized 换成 ReentrantLock（可 unmount）。

// 创建虚拟线程的三种方式
// 1. 直接启动
Thread vt = Thread.startVirtualThread(() -> doIO());

// 2. 每任务一虚拟线程的 Executor（推荐）
try (ExecutorService e = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 100_000; i++)
        e.submit(() -> handle(req));   // 10万并发也不耗尽
}

// pinning 反例：synchronized 内阻塞会钉扎载体线程
public synchronized String fetch() {   // 不要 synchronized！
    return httpClient.send(...);  // 阻塞 IO，此时载体线程被钉住
}
// 正确：用 ReentrantLock，可正常 unmount
private final ReentrantLock lock = new ReentrantLock();
public String fetch() {
    lock.lock();
    try { return httpClient.send(...); }
    finally { lock.unlock(); }
}

落地步骤：① 升级到 JDK 21+；② 用 newVirtualThreadPerTaskExecutor 替换 IO 密集线程池；③ 全链路排查 synchronized 阻塞点，JDK 21-23 用 tracePinnedThreads，JDK 24+ 用 jdk.VirtualThreadPinned；④ ThreadLocal 评估，one-way immutable context 考虑迁移 Scoped Values；⑤ 数据库连接池、HTTP 客户端确认支持虚拟线程（HikariCP 5.1+、HttpClient 原生支持）。

追问 1：虚拟线程和 Go goroutine、Kotlin 协程有何异同？

三者都是 N:M 调度的轻量级线程，但实现与生态不同。goroutine 是 Go 运行时内建，调度器成熟、栈可增长、channels 是一等公民；Kotlin 协程是基于线程池的"协作式挂起"，需 suspend 函数显式标记，挂起点编译期确定。Java 虚拟线程不要求把业务改写成 suspend 风格，但也不是 CPU 时间片抢占模型：JDK 调度器在可卸载阻塞点释放载体线程，CPU 密集任务不会自动让出。其优势是多数同步存量代码无需重写，直接换 Executor 往往即可运行；代价是需排查 pinning 和不支持卸载的阻塞点。

追问 2：为什么虚拟线程不能取代 CPU 密集型线程池？

虚拟线程解决的是"IO 等待时线程被浪费"。CPU 密集任务没有可卸载阻塞点，JDK 当前也不会基于时间片强制抢占，实际并行度仍由载体线程数决定。多开虚拟线程只会增加调度开销和排队。所以 CPU 密集场景，平台线程池（线程数=核数）仍是首选，虚拟线程是为高并发阻塞等待而生。

追问 3：虚拟线程会让 CompletableFuture 失去价值吗？

部分场景会。CompletableFuture 的核心价值是"IO 等待时不占线程"，虚拟线程直接用同步代码就实现了这一点，可读性更好。但 CompletableFuture 在任务编排（组合多个异步结果、超时、异常分支）上仍有表达力优势，且不依赖 JDK 21。未来趋势是：简单串行 IO 用虚拟线程+同步代码，复杂编排仍用 CompletableFuture，但它的执行器会换成虚拟线程执行器。

上线门禁：池大小与队列拒绝策略、VT pinning 检测版本矩阵。表达提纲：饱和现象→队列/载体证据→参数与代码改造。

这道题考察 Spring Boot 3.2+ 虚拟线程集成的落地工程能力：一行配置 spring.threads.virtual.enabled=true 背后发生了什么（Tomcat 线程模型切换）、与传统线程池的性能差异、以及落地前的兼容性评估（synchronized/pinning、连接池、ThreadLocal）。它考察"知道怎么开"和"知道开了之后会踩什么坑"的差距。

Spring MVC（Thread-per-Request）：Tomcat 用 200 个平台线程，每个请求占一个线程，IO 等待时线程阻塞。简单直观，但并发上限受线程数限制。

Spring WebFlux（响应式，Spring 5/Boot 2）：少量 EventLoop 线程 + Reactor 声明式编排，IO 不阻塞线程。吞吐高但学习曲线陡、调试困难、生态（阻塞库）兼容差。

Spring MVC + Virtual Threads（Spring 6.1/Boot 3.2，2023）：Tomcat 把请求处理线程换成虚拟线程，每个请求一个虚拟线程，IO 阻塞时 unmount。用 MVC 的命令式写法获得接近 WebFlux 的吞吐，是编程模型的"回归"——开发者无需学响应式即可享受高并发。

未来：Spring 持续把虚拟线程推广到 @Async、@Scheduled、TaskExecutor、Kafka listener 等所有异步抽象，最终形成"声明式开关 + 命令式代码"的统一并发模型。

一行配置背后的机制：开启后 Spring Boot 做 3 件事——① Tomcat 的 ProtocolHandler 切换为虚拟线程执行器（每个请求 new VirtualThread）；② SimpleAsyncTaskExecutor 配置为虚拟线程模式，供 @Async / @Scheduled 使用；③ 自动配置类 TaskExecutionAutoConfiguration 调整 Bean。

# application.yml — Spring Boot 3.2+ 开启虚拟线程
spring:
  threads:
    virtual:
      enabled: true   # 一行配置，Tomcat/Async/Scheduled 全部切换到虚拟线程

# 前置条件：JDK 21+，Spring Boot 3.2+
# Maven: java.version=21, parent 为 spring-boot-starter-parent:3.2.x

性能对比（典型 IO 密集场景，外部 HTTP 调用 50ms）：

关键结论：MVC + Virtual Threads 在吞吐上接近 WebFlux，但保留了命令式代码的可读性与生态兼容性，是大多数项目的最优解。

落地清单：

• JDK 升级：升到 21 LTS，确认 GC（G1/ZGC）、依赖兼容。
• 开启开关：spring.threads.virtual.enabled=true。
• pinning 排查：JDK 21-23 启动加 -Djdk.tracePinnedThreads=short 压测观察日志；JDK 24+ 用 jdk.VirtualThreadPinned。重点检查 synchronized + IO、第三方库（如旧版 JDBC 驱动、Jackson 某些路径）。
• 连接池校验：HikariCP 5.1+ 支持虚拟线程；连接池 size 不必调大（虚拟线程不持有连接等待）。
• ThreadLocal 审计：百万虚拟线程下 ThreadLocal 内存放大，评估迁移 Scoped Values。
• @Async 执行器：确认 @Async 用的是虚拟线程执行器而非旧线程池 Bean。

// 自定义 @Async 虚拟线程执行器（替代默认）
@Configuration
@EnableAsync
public class AsyncConfig implements AsyncConfigurer {
    @Override
    public Executor getAsyncExecutor() {
        return Executors.newVirtualThreadPerTaskExecutor();
    }
}

// 压测脚本：jmh 或 wrk 验证 pinning
// JDK 21-23: java -Djdk.tracePinnedThreads=short -jar app.jar
// wrk -t8 -c10000 -d60s http://localhost:8080/io-endpoint

追问 1：开启虚拟线程后，Tomcat 的 maxThreads 配置还有意义吗？

意义降低。虚拟线程模式下，Tomcat 不再使用传统的 maxThreads=200 平台线程池，而是为每个请求创建一个虚拟线程，并发上限几乎只受内存和后端（连接池、下游服务）限制。server.tomcat.threads.max 对虚拟线程模式不再生效，应转而关注连接池 size、下游限流等真实瓶颈。

追问 2：数据库连接池在虚拟线程下怎么配？

虚拟线程让"等待连接"不再占线程，但连接本身仍是稀缺资源。HikariCP 的 maximumPoolSize 仍是数据库能承受的连接数（通常 10~30），不能因为虚拟线程百万级就把连接池调大——瓶颈会转移到数据库。虚拟线程的价值是"线程等连接时不浪费载体线程"，而非"打开更多连接"。

追问 3：synchronized 是 Spring Boot 落地虚拟线程的主要障碍吗？

是高频障碍之一。Spring 框架本身已大量替换 synchronized 为 ReentrantLock 以适配虚拟线程，但第三方库（如某些 JDBC 驱动、Redis 客户端、序列化库）内部的 synchronized 在 IO 路径上会导致 pinning。落地前按 JDK 版本选择诊断方式并全链路压测，识别并升级或替换问题库。JEP 491（JDK 24）消除几乎全部 synchronized pinning，但 native/foreign 调用等剩余场景仍需验证。

这道题考察对 CompletableFuture（JDK 8）链式编排模型的掌握： supplyAsync/thenApply/thenCompose/allOf/anyOf 的语义差异、同步与异步方法的区别、异常处理三件套（exceptionally/handle/whenComplete）、以及默认线程池 commonPool 的陷阱。它是 Java 异步编程的核心工具，也是理解响应式编程的台阶。

Future（JDK 5）：只能 get() 阻塞获取结果，无法链式组合、无法回调，实战价值有限。

CompletableFuture（JDK 8，2014）：引入 50+ 方法，支持链式回调、组合、异常处理，成为 Java 异步编排事实标准。借鉴 Scala 的 Future 和 Twitter 的 Finagle。

Reactive Streams / Reactor（Spring 5）：CompletableFuture 是"单值异步"，Reactor 的 Mono/Flux 是"流式异步"，增加了背压、操作符融合。表达力更强但更复杂。

JDK 9 增强：补齐 orTimeout、completeOnTimeout、delayedExecutor，解决超时控制缺失痛点。

Virtual Threads（JDK 21）：简单串行 IO 可直接用同步代码+虚拟线程替代 CompletableFuture；但复杂编排（多任务聚合、超时、错误分支）CompletableFuture 仍有价值，执行器可换成虚拟线程执行器。

核心方法分类：

thenApply vs thenCompose（最容易混淆）：thenApply 的 fn 返回普通值 T -> R，结果 CF<R>；thenCompose 的 fn 返回 CF T -> CompletableFuture<R>，结果扁平化为 CF<R>。类比 Stream 的 map vs flatMap。

// 典型编排：并行调用三个服务，聚合结果，带超时与异常降级
CompletableFuture<UserProfile> profile = CompletableFuture
    .supplyAsync(() -> userService.getProfile(uid), bizExecutor)
    .orTimeout(500, TimeUnit.MILLISECONDS);    // JDK9 超时

CompletableFuture<List<Order>> orders = CompletableFuture
    .supplyAsync(() -> orderService.list(uid), bizExecutor)
    .orTimeout(500, TimeUnit.MILLISECONDS);

CompletableFuture<Integer> credit = CompletableFuture
    .supplyAsync(() -> creditService.score(uid), bizExecutor)
    .exceptionally(ex -> 0);                   // 异常降级为默认分

// 三个并行，全部完成后组合（thenCompose 扁平化）
CompletableFuture<UserView> result = CompletableFuture.allOf(profile, orders, credit)
    .thenApply(v -> new UserView(
        profile.join(),         // 此时都已完成，join 不阻塞
        orders.join(),
        credit.join()));

UserView view = result.join();   // 顶层才阻塞一次

commonPool 陷阱：supplyAsync 不传 executor 时默认用 ForkJoinPool.commonPool()，其并行度 = CPU 核数 - 1。在 IO 密集任务下会饥饿——所有线程都在 IO 阻塞，新任务排队。务必传入业务线程池或虚拟线程执行器。

• 始终显式传 Executor：避免 commonPool 污染，IO 任务用独立线程池或虚拟线程执行器。
• 只在顶层 join/get：链式中间用 thenApply 等回调，避免阻塞。
• 必须配超时：orTimeout 防止单个异步任务拖垮整链。
• 异常链完整：exceptionally/handle 做降级，whenComplete 做日志/监控。
• 跨异步边界保留上下文：在提交前显式捕获 MDC/TraceContext 快照，回调或子任务入口恢复，finally 还原；不要假设回调总在提交线程上执行。接入 TTL 时也应明确包装提交任务或装饰 Executor。
• allOf 结果收集：allOf 返回 CF<Void>，需在 thenApply 中对各 CF 调 join 收集（此时已完成，不阻塞）。

追问 1：thenApply 的 fn 到底在哪个线程执行？

分三种情况：① 若上一步已完成，thenApply 的 fn 通常在调用 thenApply 的线程执行；② 若上一步未完成，fn 通常由触发依赖完成的线程执行；③ 用 thenApplyAsync 则提交到指定 executor（不传时默认 commonPool）。执行线程存在边界竞争与框架差异，不应依赖以上"通常"结果。跨异步边界必须显式传递 TraceId/MDC/租户上下文：任务提交时捕获快照，执行入口 restore，finally 恢复旧值；TtlRunnable 只适合包装可提交的 Runnable/Callable，回调链可结合 thenApplyAsync、显式 executor 和统一装饰器处理。

追问 2：CompletableFuture 的异常如何传播？

异常会沿链向下传播，直到遇到 exceptionally/handle/whenComplete。未处理的异常在 join 时以 CompletionException 包装抛出，get 时以 ExecutionException 包装。若链中无任何异常处理且不 join，异常会被静默吞掉（仅记录到内部结果）——这是常见坑，务必在链尾加 whenComplete 记录日志。

追问 3：CompletableFuture 与 Reactor Mono 的本质区别？

CompletableFuture 是"热"的——创建即开始执行，计算只执行一次。Mono 是"冷"的——定义了数据流，subscribe 才执行，可多次订阅。Mono 支持背压（虽然单值场景不明显）、操作符融合、与流式 Flux 统一。CompletableFuture 表达力弱但简单，Mono 表达力强但复杂。在虚拟线程时代，简单场景两者都可被同步代码替代。

CompletableFuture 的执行器可以切换为虚拟线程，但 Spring Boot 3.2 的虚拟线程自动配置有明确的作用范围与局限性，这一层补全自动配置的覆盖边界与实践陷阱。

• spring.threads.virtual.enabled=true 的作用范围：① Tomcat/Jetty/Undertow 的请求处理线程 → VT；② @Async 异步任务执行器 → VT；③ Spring TaskExecutor bean → VT。
• 不受影响的组件：ScheduledExecutor、Stream parallel()、CompletableFuture 默认仍用 ForkJoinPool.commonPool()——需手动传 Executors.newVirtualThreadPerTaskExecutor() 或注入 Spring 管理的 TaskExecutor。
• 局限性一：synchronized 阻塞导致 pinning：synchronized 块内有阻塞 IO（如 DB 查询、HTTP 调用），VT 会固定在 carrier thread 上无法卸载，等效于平台线程。JDK 21（JEP 444）下 Object.wait 仍钉住（调度器扩并行度补偿）；JDK 24（JEP 491）起 synchronized pinning 基本消除。synchronized + IO 在 JDK 21–23 仍会 pin。
• 局限性二：ThreadLocal 继承问题：新建虚拟线程不会自动继承父线程的普通 ThreadLocal；JDK 21 推荐在 one-way immutable context 场景使用 ScopedValue（当时为预览特性，JDK 25 转正）。
• 局限性三：第三方库未适配：MySQL JDBC 驱动在 synchronized 块内执行 IO 会 pin；Netty EventLoop 不支持 VT（VT 不适合事件驱动框架）。
• 局限性四：监控与排查困难：jstack 中 VT 数量极多，传统线程分析工具（如 async-profiler）需适配。
• 替代方案：Reactor/WebFlux 响应式模型在 IO 多路复用场景仍优于 VT（更低的内存开销），复杂流式编排与背压场景不应盲目迁移到 VT。

这道题考察架构师对三种并发模型本质差异的判断：Servlet（同步阻塞，线程=请求）、WebFlux（响应式声明，少量线程 EventLoop）、Virtual Threads（同步代码+轻量线程）。核心不是背 API，而是理解每种模型的线程模型、编程范式、资源假设、生态约束，以及"Virtual Threads 是否会取代响应式"这个仍持续的架构争论。

Servlet 模型（同步阻塞）：Servlet 3.0 之前，每个请求一个线程，IO 阻塞线程。简单但扩展性差。

Async Servlet（Servlet 3.0，2009）：允许异步分发，释放容器线程，但编程模型仍是命令式，回调用 Runnable，组合困难。

Spring WebFlux（Spring 5，2017）：基于 Reactor + Netty/Undertow，全链路非阻塞，少量 EventLoop 线程处理海量请求。声明式 Mono/Flux 编排，背压支持流式。吞吐高但学习曲线陡、阻塞库不兼容。

Virtual Threads（Spring 6.1/Boot 3.2，2023）：让 Servlet 模型用虚拟线程，同步代码获得异步吞吐，许多人视为 WebFlux 的"终结者"。

三维度对比：

WebFlux 的本质：声明式数据流 + 背压。Mono/Flux 是"数据流的描述"，subscribe 才执行。Reactor 通过操作符组合实现 map/filter/flatMap/merge，背压让消费者控制生产者速率（request(n)）。它的价值不只是"高并发"，而是对流的抽象——SSE、WebSocket、流式 LLM 输出等场景，Flux 比"阻塞队列+轮询"优雅得多。

WebFlux 的致命约束：全链路非阻塞。任何一个阻塞调用（JDBC、synchronized、Thread.sleep）都会卡住 EventLoop，整个服务吞吐崩塌。这要求整个生态（驱动、ORM、HTTP 客户端）都有响应式版本，迁移成本极高。R2DBC（响应式 DB）成熟度远不及 JDBC，是 WebFlux 落地的主要障碍。

选型决策矩阵：

• 新建 IO 密集服务 + JDK 21+：MVC + Virtual Threads（首选）。
• 强流式场景（LLM 流式、SSE、实时数据流）：WebFlux（Flux 表达力无可替代）。
• 已有成熟 WebFlux 且无痛点：保持，不必为迁移而迁移。
• 重度依赖 JDBC/阻塞库：MVC + Virtual Threads（WebFlux 会被阻塞库拖垮）。
• 需要背压的流处理：WebFlux 或直接用 Reactive Streams API。

追问 1：为什么 WebFlux 调试困难？

响应式代码是声明式的，操作符链在 subscribe 时才组装执行，异常栈反映的是 Reactor 内部调度，而非业务调用链。一个 NPE 的栈可能只有 reactor.core.publisher 的内部帧，看不到业务方法。Reactor 提供 Hooks.onOperatorDebug() 和 checkpoint() 补充装配点信息，但仍不如命令式栈直观。这是 WebFlux 维护成本高的核心原因。

追问 2：背压在请求-响应场景有意义吗？

意义有限。请求-响应是"单值"语义，背压主要针对"流"。WebFlux 在 HTTP 请求-响应场景的背压价值在于"客户端慢消费时，服务端不堆积"，但实践中 HTTP/1.1 单连接单请求模型下，背压机制难以发挥。真正的背压价值在 SSE、WebSocket、Kafka 消费等流式场景。

追问 3：MVC + Virtual Threads 能完全达到 WebFlux 的吞吐吗？

在纯 IO 密集、无 pinning 的场景，吞吐接近（差异通常在 10% 以内）。但 WebFlux 在极端高并发 + 内存效率上仍有优势：虚拟线程每个有栈对象（KB 级），百万并发时内存比 EventLoop 模型高；且虚拟线程的 unmount/mount 有调度开销。对于"十万级以下并发"，差异不显著；对于"百万级长连接"，WebFlux 仍更省资源。

这道题考察对 JDK 19/20 incubator（JEP 428/437）到 JDK 21+ preview（JEP 453/462/480/499/505/525）结构化并发的专家级理解：它如何通过 StructuredTaskScope 把并发任务组织成父子生命周期绑定的树，解决传统并发"任务逃逸、错误丢失、取消不可达"的根本问题。它考察"从非结构化到结构化"的范式跃迁，以及与 Scoped Values、Virtual Threads 的协同设计。截至 JDK 26 仍是 Preview API，但代表了并发编程的演进方向。

非结构化并发（new Thread / Executor）：任务提交后生命周期与提交者解耦，子任务可逃逸——提交者已返回，子任务仍在跑；子任务异常无人接；取消无法传播到子任务。这是"fire-and-forget"模型的根本缺陷。

CompletableFuture（部分结构化）：allOf/anyOf 提供了组合，但仍是"扁平"的——异常需手动 exceptionally，取消需手动传播，且子任务的子任务仍可逃逸。没有"作用域"概念。

结构化并发（JDK 19/20 incubator；JDK 21+ Preview）：借鉴 Erlang/Go 的设计哲学，把并发任务组织成树——父任务等待所有子任务，子任务的生命周期不超出父作用域。作用域退出时所有未完成子任务自动取消，异常自动传播。这是"作用域化"思维在并发的应用，与 try-with-resources 对资源的作用一致。（注：截至 JDK 26 仍为 Preview API，需 --enable-preview 启用，API 可能调整，不建议核心生产链路依赖。）

未来：Scoped Values + Structured Concurrency + Virtual Threads 构成 JDK 并发的"新三件套"，目标是让百万级并发也具备命令式代码的可读性与正确性保证。当前 Preview，API 可能调整，但方向已定。

核心抽象：StructuredTaskScope。它是一个作用域，JDK 25 的 fork() 默认在作用域内启动子虚拟线程，join() 按 Joiner 策略等待，作用域退出时自动取消未完成子任务。JDK 21-24 的两个内置策略：

• ShutdownOnFailure：任一子任务异常则中断所有其他子任务（fail-fast），适用于"全部成功才有意义"的场景。
• ShutdownOnSuccess：任一子任务成功则中断其他（first-win），适用于"任一结果即可"的场景（如多源查询取最快）。

// 结构化并发：并行调用三个服务，任一失败则全部取消（fail-fast）
record Response(User user, Order order, Credit credit) {}

public Response load(long uid) throws ExecutionException, InterruptedException {
    try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
        // fork 启动子虚拟线程，立即返回 Subtask
        var userTask   = scope.fork(() -> userService.get(uid));
        var orderTask  = scope.fork(() -> orderService.get(uid));
        var creditTask = scope.fork(() -> creditService.get(uid));

        scope.join();            // 等待全部完成或某异常触发关闭
        scope.throwIfFailed();   // 若有异常，抛出（自动取消已中断的其他任务）

        return new Response(
            userTask.get(),        // 此时已完成，get 不阻塞
            orderTask.get(),
            creditTask.get());
    }   // try-with-resources：作用域关闭，自动取消所有未完成子任务
}

// ShutdownOnSuccess：多源查询取最快返回（first-win）
public String fastestQuote(String symbol) throws InterruptedException {
    try (var scope = new StructuredTaskScope.ShutdownOnSuccess<String>()) {
        scope.fork(() -> sourceA.quote(symbol));
        scope.fork(() -> sourceB.quote(symbol));
        scope.fork(() -> sourceC.quote(symbol));
        scope.join();
        return scope.result();   // 第一个成功的结果，其他已自动取消
    }
}

以上示例必须按版本理解：JDK 21-24 使用 ShutdownOnFailure/ShutdownOnSuccess 和 public 构造器；JDK 25（JEP 505）改为 StructuredTaskScope.open() 或 open(Joiner)。常用 Joiner 是 allSuccessfulOrThrow()、anySuccessfulResultOrThrow()、awaitAllSuccessfulOrThrow()、awaitAll() 和 allUntil(...)。不要把两代 API 混写在同一编译目标里。

三大保证：① 生命周期绑定——子任务不超出作用域，作用域关闭即取消全部未完成子任务；② 错误传播——子任务异常自动传播给父，触发 fail-fast 关闭；③ 可观测性——作用域内的任务树可被整体 dump（线程转储能看到父子关系）， unlike CompletableFuture 的扁平链。

当前状态（2026）：JDK 25（JEP 505，第五次 Preview）引入 open()/Joiner；JDK 26（JEP 525，第六次 Preview）继续预览，尚未 GA，核心生产链路慎用。示例与运行版本必须一致，例如 JDK 25 预览 API 使用 --enable-preview --release 25。其设计思想已可用 CompletableFuture + 虚拟线程近似实现：用 allOf 编排、exceptionally 降级、虚拟线程执行器承载。

何时采用：① 学习与原型验证；② 内部工具/非核心链路在受控配置下试用；③ 待正式 GA 后再逐步替换 CompletableFuture 的复杂编排场景。

追问 1：结构化并发与 Erlang supervisor / Go errgroup 的异同？

Erlang 的 supervisor 树是"进程级"的，子进程失败由 supervisor 决定重启策略，强调"让它崩溃"哲学。Go 的 errgroup.WithContext 提供取消传播与错误收集，但 goroutine 仍可逃逸（无强制作用域）。Java StructuredTaskScope 更接近 errgroup 但更强——try-with-resources 强制作用域语义，子任务无法逃逸，且与虚拟线程深度集成。三者的共同思想是"父任务不应在子任务还在跑时就返回"。

追问 2：为什么 StructuredTaskScope 必须配合虚拟线程？

JDK 25 的 fork 默认启动虚拟线程；若通过配置换成平台线程，作用域语义仍然成立，但每个子任务都对应 OS 线程，fork 十万次会耗尽资源。虚拟线程让"每子任务一线程"廉价，才使结构化并发在大规模并发下可行。这是 Project Loom 三件套（VT + Scope + ScopedValue）协同设计的体现。

追问 3：StructuredTaskScope 能嵌套吗？取消如何传播？

可嵌套，形成任务树。外层作用域取消时，自动取消其所有内层作用域的子任务（取消沿树向下传播）。内层作用域关闭不影响外层。这种树状取消语义让"大任务取消 → 所有子任务级联取消"成为语言级保证，解决了 CompletableFuture 时代"手动管理取消令牌"的繁琐。

考察虚拟线程"钉住（pinning）"问题的生产排查与治理能力。核心要讲清三件事：① 虚拟线程在哪些场景下无法从载体线程卸载（JDK 21-23 的 synchronized monitor、native/foreign 栈帧中的阻塞）；② JDK 21-23 可用 -Djdk.tracePinnedThreads 与新式线程转储定位，JDK 24 起改用 JFR 事件和线程转储；③ 治理策略——旧版本把热点 synchronized 换成 ReentrantLock、native 调用隔离、JDK 24+（JEP 491）消除几乎全部 synchronized pinning。能否讲清 pinning 触发条件、诊断链路与版本差异，是区分"会用虚拟线程"与"能扛虚拟线程"的分水岭。

虚拟线程 JDK 21 GA（JEP 444，2023）：虚拟线程在载体线程（ForkJoinPool carrier）上运行，遇到 IO 阻塞（socket read/write、LockSupport.park）时自动 yield 卸载，载体线程立即服务其他虚拟线程，实现"线程数与吞吐解耦"。

pinning 问题暴露：生产落地后高频出现"虚拟线程没起到作用、吞吐反而下降"。根因是虚拟线程并非在所有阻塞点都能卸载——synchronized 持有 monitor 时载体线程无法让出（monitor 绑定在 OS 线程上），native 栈帧/JNI 阻塞时 JVM 无法保存恢复 native 栈。这两种场景下虚拟线程被"钉"在载体线程上，高并发下迅速耗尽载体线程池（默认 CPU 核数），吞吐崩塌。

诊断工具演进：JDK 21 提供 -Djdk.tracePinnedThreads=full|short 在钉住时打印栈与持有 monitor 的虚拟线程；jcmd <pid> Thread.dump_to_file -format=json <file> 输出结构化线程转储，可观察 pinned 状态和线程关系。JDK 24 起该系统属性被移除；jdk.VirtualThreadPinned JFR 事件保留，并增强为携带 pinning 原因和载体线程信息。

JDK 24（JEP 491，2025）：重构 synchronized 实现，允许虚拟线程在 synchronized 块内卸载（monitor 改为可虚拟化），消除最主要的 pinning 源。趋势：JDK 24+ 后 pinning 治理重心从 synchronized 转向 native/JNI 阻塞与第三方库的 native 调用。

卸载机制：虚拟线程的本质是"栈存堆、调度由 JVM 接管"。当虚拟线程在可卸载阻塞点（park、socket IO、文件 IO 的 NIO 适配）阻塞时，JVM 将其完整栈复制到堆，unmount 载体线程，载体线程立即调度下一个就绪虚拟线程。关键约束：卸载要求虚拟线程的栈帧全部是可序列化的 Java 帧——一旦出现 native 栈帧或绑定了 OS 线程的 monitor，JVM 无法保存恢复，只能钉住。

pinning 触发条件与影响：

诊断工具对比：JDK 21-23 的 -Djdk.tracePinnedThreads=full 适合开发期打印阻塞时钉住的完整虚拟线程栈；新式线程转储适合按线程树观察关系，两者用于定位具体代码。JFR 的 jdk.VirtualThreadPinned 适合生产持续监控和阈值告警。不要把某个 JSON 字段名或原因枚举当作跨版本稳定 API，应以目标 JDK 的诊断输出为准。

生产诊断流程：① JDK 21-23 才使用 -Djdk.tracePinnedThreads=full（生产可改 short 降噪）定位阻塞时钉住的栈；② JDK 24+ 以 JFR 开启 jdk.VirtualThreadPinned 监控频率、持续时间和载体线程压力，需要现场快照时再执行 jcmd <pid> Thread.dump_to_file -format=json /tmp/vt.json；③ 按栈、线程关系和事件上下文定位 synchronized 块或 native/foreign 调用，不把诊断字段当作长期契约解析。

// 典型 pinning 反模式：synchronized 包裹 IO 阻塞
public String fetchBad(String key) throws IOException {
    synchronized (this) {              // JDK21-23 持有 monitor 期间阻塞即 pinning
        return httpClient.send(req, BodyHandlers.ofString()).body();
    }
}

// 治理：改用 ReentrantLock，park 可卸载，虚拟线程正常 yield
private final ReentrantLock lock = new ReentrantLock();
public String fetchGood(String key) throws IOException {
    lock.lock();
    try {
        return httpClient.send(req, BodyHandlers.ofString()).body();
    } finally {
        lock.unlock();
    }
}

追问 1：为什么 synchronized 会 pinning 而 ReentrantLock 不会？

synchronized 基于 JVM 内置 monitor，monitor 与 OS 线程强绑定（ObjectMonitor 持有 owner 线程指针），虚拟线程持有 monitor 时无法把所有权迁移到另一个载体线程，只能钉住。ReentrantLock 基于 AQS + LockSupport.park，park 是可卸载阻塞点，虚拟线程 park 时正常 yield 释放载体线程，锁状态保存在 AQS 的 Java 对象中，唤醒后在任意载体线程恢复。这是 JDK 21-23 期推荐 ReentrantLock 替代 synchronized 的根本原因。

追问 2：JDK 24 JEP 491 如何修复 synchronized pinning？

JEP 491 改造 monitor 记录方式，使虚拟线程可以在 synchronized 块内、等待 monitor 和 Object.wait() 时释放载体线程；JEP 原文明确消除几乎全部 synchronized pinning。native/foreign 回调等剩余场景仍可能钉住。升级到 JDK 24 后，绝大多数 synchronized 阻塞自动受益，但虚拟线程迁移仍需用 JFR 压测确认。

追问 3：少量 pinning 是否必须治理？

不必一概治理。pinning 的危害是载体线程被占用，只要载体线程池（默认并行度 = CPU 核数）未耗尽，少量钉住通常无伤大雅。判断标准是监控 jdk.VirtualThreadPinned 事件速率、持续时长与载体线程池利用率——若钉住率低且载体线程空闲充足，可暂不治理；若高并发下载体线程饱和、吞吐不达标，必须按诊断流程定位并修复。

跨 C04 / E03 / C15 的统一对照（本表为准；速查见 E03.06，响应式边界见 C15）。核心结论：JDK 24+（JEP 491）消除几乎全部 synchronized pinning，native/FFI 钉住仍在；不要把「升级到 24」写成「彻底零 pinning」。

互链：原理速查 E03.06（排查）/ E03.07（锁与 JEP 491）；响应式边界见 C15.05，讨论 VT 与阻塞模型时以本表为准，避免三处表述漂移。

上线门禁：池大小与队列拒绝策略、VT pinning 检测版本矩阵。表达提纲：饱和现象→队列/载体证据→参数与代码改造。

这道题考察在 虚拟线程（大量并发） 场景下，传统 ThreadLocal 的固有缺陷（无界生命周期、线程池复用污染、昂贵继承），以及 ScopedValue 如何用"一次写入、不可变绑定、作用域生命周期"的模型安全传递上下文（traceId / 用户身份 / 租户）。它是结构化并发（Structured Concurrency）的配套基石，但不是 ThreadLocal 的无条件替代。

ThreadLocal（JDK 1.2）：每线程一份变量副本，解决线程安全与参数透传。缺陷：需手动 remove() 否则泄漏；线程池复用导致跨任务值污染。

InheritableThreadLocal：父子线程继承，但线程池场景失效——线程由池创建，任务提交时并非"父子"关系，值不会随任务更新。

TransmittableThreadLocal（阿里 TTL）：通过包装 Runnable/Callable 在任务提交/执行边界拷贝值，解决线程池传递，是框架级补丁。

ScopedValue 演进：JDK 20（JEP 429）incubator，JDK 21-24 preview（JEP 446/464/481/487），JDK 25（JEP 506）正式交付。它适合 one-way immutable context：调用方传给直接/间接调用方和结构化子线程，支持嵌套 rebind，绑定随作用域退出销毁。

虚拟线程 + ScopedValue：虚拟线程轻量到可大量创建；若每条线程都保留自己的 ThreadLocal 副本，内存和继承开销会放大。ScopedValue 让不可变上下文可被同一作用域内的子任务共享，并与 StructuredTaskScope 的生命周期配合。

ThreadLocal 三重坑：① 泄漏：key 是弱引用、value 强引用，未 remove() 则线程存活期间 value 不回收；② 污染：线程池线程复用，上一任务残留值被下一任务读到；③ 虚拟线程不友好：不可继承给子任务，且每虚拟线程维护 map 开销大。

ScopedValue 模型：用 ScopedValue.where(KEY, value).run(() -> {...}) 在作用域内绑定一个不可变值；作用域结束自动解除；内层可嵌套 rebind，但外层绑定不变。只有 StructuredTaskScope 这类能保证子线程在作用域结束前终止的 API 才能继承 ScopedValue；任意线程池不继承。

final static ScopedValue<String> TRACE_ID = ScopedValue.newInstance();

// 在作用域内绑定，run() 期间及其中派生的子任务都能读到，结束自动解除
ScopedValue.where(TRACE_ID, "req-123").run(() -> {
    handleRequest();              // TRACE_ID.get() == "req-123"
    // StructuredTaskScope 派生并在 run 前结束的子任务继承该值
});
// 作用域外 TRACE_ID.orElse("none")，无残留、无泄漏

迁移场景：请求级只读上下文（traceId、userId、租户标识）从 ThreadLocal 迁到 ScopedValue，在入口（如 filter/拦截器）用 where(...).run() 或 call(...) 包裹业务处理；JDK 25 前必须开启对应 preview。

与结构化并发配合：在 StructuredTaskScope 内 fork() 的子任务继承父作用域的 ScopedValue，作用域通过 join/close 保证子任务结束后才销毁绑定；不要期望 ForkJoinPool 或任意 ExecutorService 自动继承。

兼容性注意：Spring Security、日志框架（MDC）等生态可能仍基于 ThreadLocal，迁移要看框架版本和适配能力；过渡期继续用显式快照/restore 或 TTL 桥接。双向写回和线程私有可变缓存不是 ScopedValue 的目标场景。

追问 1：ScopedValue 为什么设计为不可变？ 不可变才能安全被并发子任务共享且无需加锁；若可写，多个虚拟线程继承同一作用域会产生竞争，违背"作用域即契约"的简洁模型。

追问 2：ScopedValue 能完全替代 ThreadLocal 吗？ 不能无条件替代。JEP 506 建议在 one-way immutable context 场景迁移；若调用深处要通过 ThreadLocal.set 向远处调用方写回结果，或需要线程生命周期内的可变缓存，ThreadLocal 仍是合适工具。JEP 也明确不以废弃 ThreadLocal 为目标。

追问 3：虚拟线程下 ThreadLocal 的开销具体在哪？ JEP 506 指出虚拟线程本身仍支持 ThreadLocal，短命、非池化虚拟线程也能降低长期泄漏风险；但当大量虚拟线程各自保留副本时，内存和继承开销会显著放大。ScopedValue 让不可变数据由作用域结构高效共享，不是宣称"零存储"。

虚拟线程对 IO 密集负载可能有明显吞吐收益，但内存、下游容量与 pinning 是落地约束；精确收益必须用自身压测和容量模型验证。