虚拟线程的最大优势是可以用很低的成本创建海量并发任务。但这也带来一个容易被忽视的问题：如果每个虚拟线程都独立维护一套 ThreadLocal 数据，那么百万级别的线程数量会迅速放大线程局部存储的内存占用和清理开销。Scoped Values 正是为了应对这类场景而设计的，它不再把上下文数据挂在线程对象上，而是让数据跟随代码作用域流动。
从使用方式上看，Scoped Values 比 ThreadLocal 更接近在某个代码块内可见的不可变变量。它强调值只在绑定作用域内有效，作用域一旦退出，值自动失效，这从设计上减少了手动清理的负担。
为什么虚拟线程放大了ThreadLocal的负担
传统线程池中线程数量通常在几十到几百，每个线程持有 ThreadLocalMap 不会造成太大压力。即使有些业务忘记调用 remove，线程复用时可能出现数据串号，但整体可控。虚拟线程出现后，线程数量可以轻松到达数十万甚至百万，ThreadLocal 的两个问题会被急剧放大。
第一个问题是内存占用。每个使用过 ThreadLocal 的线程都会创建自己的 ThreadLocalMap，里面包含 Entry 数组。如果百万个虚拟线程各自短暂执行任务，每个线程即使只读写一次 ThreadLocal，也要分配一份独立 Map，这会带来大量短生命周期对象和垃圾回收压力。第二个问题是清理成本。虚拟线程挂起和恢复时，ThreadLocal 的值并不会自动清除，如果业务代码忘记在 finally 中 remove，数据要么随线程一起被回收，要么在线程复用场景中持续残留，导致上下文混乱。
更深层的差异在于，ThreadLocal 倾向于让数据归属于线程，而虚拟线程的创建与销毁极其频繁，这种归属关系显然不再合适。需要用一种不依赖线程对象本身的作用域传递机制来替代。
Scoped Values的核心用法与作用域绑定
Scoped Values 的使用步骤通常分为三步：先通过 ScopedValue.newInstance() 创建一个键，再调用 ScopedValue.where 绑定键值并传入要执行的代码块，最后在代码块内通过 get() 读取当前值。下面是一个在虚拟线程中传递用户 ID 的示例。
import java.util.concurrent.*;
public class ScopedValueExample {
static final ScopedValue<String> USER_ID = ScopedValue.newInstance();
public static void main(String[] args) throws Exception {
ScopedValue.where(USER_ID, "u-10086", () -> {
System.out.println("外层读取用户：" + USER_ID.get());
Thread.startVirtualThread(() -> {
System.out.println("虚拟线程读取用户：" + USER_ID.get());
}).join();
});
System.out.println("外部是否绑定：" + USER_ID.isBound());
}
}
示例中，USER_ID 在 where 的回调内可读，回调结束后调用 isBound() 返回 false。对于需要在子作用域中叠加多个值的场景，可以使用 ScopedValue.Carrier 对象，先绑定一个键，再继续调用 where 绑定其他键，最后统一执行任务。这样多个值会在同一个作用域中生效，而不需要嵌套多层回调。
有一点需要特别注意：Scoped Values 的值是不可变的。不能像 ThreadLocal 那样在执行过程中调用 set 修改已有绑定。如果业务中确实需要可变状态，应当把并发安全的数据结构作为不可变引用放入 Scoped Value，例如一个 AtomicReference 或不可变对象，而不是试图改 Scoped Value 本身。
与ThreadLocal的性能和设计差异
从设计语义上看，ThreadLocal 允许随时读写，变量生命周期由开发者手动管理；Scoped Values 则把变量限制在只读且作用域明确的范围中。前者灵活，但容易在复杂调用链中留下清理遗漏；后者约束更强，换来的是更清晰的边界和更低的维护成本。
在虚拟线程场景下，Scoped Values 的性能优势主要来自两方面。其一，它不使用线程级 Map 存储数据，而是将值放在作用域调用帧中，线程创建和切换时不需要额外分配或复制线程局部表。其二，因为值不可变且生命周期明确，JVM 可以进行逃逸分析和栈上分配优化，读取路径比 ThreadLocalMap 的哈希查找更短。JDK 官方在 JEP 中给出的基准测试显示，在大量虚拟线程并发访问同一上下文时，Scoped Values 的访问速度和内存占用均优于 ThreadLocal。
不过这不意味着任何场景都应该立即替换 ThreadLocal。对于传统固定线程池、线程数较少且已经稳定使用 ThreadLocal 的系统，替换收益可能并不显著。真正适合迁移的是那些会创建大量虚拟线程，或者需要频繁在线程之间传递上下文的新型并发程序。
迁移建议与兼容性注意点
迁移前需要确认当前 JDK 版本对 Scoped Values 的支持状态。较新的 JDK 版本可能仍将其作为预览特性，编译和运行时需要添加 --enable-preview 参数。如果项目需要长期稳定运行，建议关注该特性转为正式版本后的 API 变化，避免在预览阶段大规模依赖。
迁移时可以从一些清晰的上下文开始，比如用户身份、请求 ID、租户编号、链路追踪 ID 等。这些数据天然具有只读、请求内不变的特点，非常适合用 Scoped Values 承载。改造步骤通常是先保留 ThreadLocal 作为过渡，再逐步把读取点替换为 ScopedValue.get()，最后移除 ThreadLocal.set 和 remove 逻辑。
还需要注意与既有线程池和异步框架的兼容性。Scoped Values 在结构化并发的子任务中可以自动继承，但如果你使用不受控的线程池提交任务，继承行为可能取决于框架对 Scoped Value 的支持程度。迁移初期建议在虚拟线程或结构化并发范围内使用，并补充测试验证边界。
Scoped Values虚拟线程ThreadLocal修改时间：2026-09-20 22:05:01