面经策

什么是 Scoped Values？相比 ThreadLocal 有什么优势？ ​

  • 标签：Java、新特性

🏛 业务架构师 ​

Scoped Values（JDK 21 预览，25 转正路线）是 ThreadLocal 的替代者：通过 ScopedValue.where(KEY, value).run(runnable) 把值绑定到一个作用域（代码块），作用域内可读，结束自动失效，且不可变。

相比 ThreadLocal 的三大优势（配合虚拟线程是刚需）：

  1. 成本模型适配海量线程：ThreadLocal 是"每线程一份副本"——百万虚拟线程×每份对象=内存灾难；ScopedValue 是"绑定一次、作用域内共享不可变值"——近乎零拷贝；
  2. 生命周期确定：ThreadLocal 忘记 remove 就是泄漏（线程池线程长生不死，脏数据串到下一个请求的经典事故源）；ScopedValue 随作用域自动清理，机制上消灭这类 bug——这对"一次请求"这种天然有边界的业务场景完美契合（请求上下文：traceId、租户 ID、用户身份）；
  3. 可继承性与可读性：子线程（结构化并发的子任务）自动可见父作用域的值，语义清晰；不可变特性让"谁改了上下文"这类疑难杂症不可能发生。

迁移策略：请求级上下文传递（链路追踪、租户隔离、认证信息）优先迁 ScopedValue；真正需要"每任务可变状态"的少数场景（如缓存累加器）保留 ThreadLocal，但虚拟线程下慎用重对象。

业务视角：这是虚拟线程生态的配套投资——2026 年团队升级 Java 21/25 时，把"ThreadLocal 治理 + ScopedValue 迁移"列入同一个改造包，一次升级解决并发模型的完整换代，避免"开了虚拟线程、踩了 ThreadLocal 坑、回头再救火"的返工路径。

🏗 系统架构师 ​

Scoped Values（JDK 21 预览 → 25 转正）= 不可变、有界生命周期的上下文传递机制，定位是 ThreadLocal 的现代替代：

java
private static final ScopedValue<User> CURRENT_USER = ScopedValue.newInstance();

ScopedValue.where(CURRENT_USER, user).run(() -> service.process());
// 作用域内任意深处:  CURRENT_USER.get()

相比 ThreadLocal 的优势（架构账本）：

  • 不可变性：ScopedValue 绑定后只读——一次绑定贯穿整个调用链，杜绝"中途 set 被其他线程读到脏值"的竞态；ThreadLocal 是可变全局状态，是并发 bug 的温床；
  • 有界生命周期：绑定随 run/call 作用域自动生效与清除——不存在"忘 remove 导致泄漏/串数据"；ThreadLocal 必须 finally remove（线程池复用线程时的经典事故：上个请求的 user 数据漏给下个请求）；
  • 与虚拟线程/结构化并发协同：scoped value 随结构化并发的 fork 自动继承到子任务（继承的是不可变快照）；ThreadLocal 在百万虚拟线程下内存模型崩溃（每线程一份副本），且 InheritableThreadLocal 只在线程创建时拷贝、线程池场景完全失效；
  • 性能：作用域内查值不需要哈希表（ThreadLocalMap 慢查询），实现上是栈式快照，读写更快。

该用谁：

  • 请求级上下文（用户身份、traceId、租户）→ ScopedValue（新代码必选）；
  • 真正需要每线程可变状态的（罕见，如缓冲区复用）→ ThreadLocal 保留，但虚拟线程场景要重新审视；
  • 框架作者（事务上下文、安全上下文）→ 迁移路线 Spring 6/新版本框架已在跟进。

一句话：ScopedValue 把"上下文传递"从可变全局状态升级为作用域化的值传递——用不可变性换确定性，是并发模型演进的一环。

💻 全栈开发专家 ​

Scoped Values（JDK 25 转正，JEP 506）：不可变的、有界作用域的上下文传递机制，定位是 ThreadLocal 的替代品（尤其面向虚拟线程时代）。

相比 ThreadLocal 的三大优势：

  1. 不可变 + 生命周期确定：
java
static final ScopedValue<User> CURRENT_USER = ScopedValue.newInstance();

ScopedValue.where(CURRENT_USER, user)
           .run(() -> service.handle());      // 作用域内可读
// CURRENT_USER.get() —— 出了作用域自动失效

写入只在 where(...).run() 边界内有效，结束自动清理——ThreadLocal 的 set() 后忘 remove()（线程池下串数据）这类事故从机制上根除。

  1. 继承语义可控：Callable 传给子线程/结构化并发 fork 的任务时自动继承（bounded inheritance），且子任务不能反向污染父作用域——ThreadLocal 的 InheritableThreadLocal 在线程池复用场景就是坑（继承错乱）。

  2. 虚拟线程友好：ThreadLocal 是「每线程一份」的可变存储——百万虚拟线程 × 大对象 = 内存爆炸，且虚拟线程用完即弃根本不适合做缓存。ScopedValue 是绑定值（写入即快照），内存 O(作用域数) 而非 O(线程数)。

迁移实践：MDC 日志上下文、租户/用户上下文、链路 traceId 这些「请求级只读数据」是最佳迁移对象；真正需要可变每线程状态的（老代码的 buffer 缓存）改池化共享。Spring 6.2+ 内部已支持 scoped value 传播，框架层会越来越顺。

一句话：ThreadLocal 是「线程拥有的可变变量」，ScopedValue 是「执行作用域携带的常量」——后者才是虚拟线程百万并发下的正确抽象。