scoped values 是 java 22 正式引入的不可变、作用域受限的上下文传递机制，能安全替代 threadlocal 解决内存泄漏、继承缺失和手动清理问题，但不支持可变状态管理。
Scoped Values 是什么，它能替代 ThreadLocal 吗
Scoped Values 是 Java 22 引入的正式特性（JEP 429），用于在虚拟线程（virtual thread）和平台线程中安全传递**不可变的、作用域受限的上下文数据**。它不是 ThreadLocal 的增强版，而是设计目标完全不同的机制：Scoped Values 只允许绑定不可变值，且绑定仅对当前执行链（包括子虚拟线程）可见，不支持“线程内任意时刻读写”，也不支持跨线程手动传播。
如果你正用 ThreadLocal 存 SimpleDateFormat 或用户身份信息，并依赖 remove() 防泄漏——Scoped Values 能更干净地做到；但若你依赖 ThreadLocal 在线程池中反复 set/get 可变状态，它就无法直接替代。
怎么声明和绑定一个 ScopedValue
必须用 static final 声明，值类型需是不可变的（如 String、Integer、自定义 final 类）。绑定只能通过 ScopedValue.where() + run() 或 call() 完成，不能像 ThreadLocal.set() 那样随意赋值。
ScopedValue<string> USER_ID = ScopedValue.newInstance();</string>- 绑定并执行：
ScopedValue.where(USER_ID, "u123", () -> doWork()); - 在
doWork()内部用USER_ID.get()读取，无需传参或查上下文容器 - 子虚拟线程自动继承该绑定（这是关键优势，
ThreadLocal默认不继承）
注意：如果在未绑定时调用 get()，会抛 NoSuchElementException，不是 null —— 这迫使你在逻辑上明确“该值必须存在”。
为什么 ScopedValue 在虚拟线程场景下更高效
虚拟线程数量可能达百万级，每个都维护一份 ThreadLocal 映射表会造成显著内存开销和 GC 压力。Scoped Values 的实现不为每个线程分配独立存储，而是在调用栈帧中携带绑定信息，只在需要时才解析，且无须清理（作用域退出即失效）。
- 没有
ThreadLocal的哈希表查找开销，get()接近直接字段访问 - 不依赖线程生命周期管理，彻底规避在线程池中忘记
remove()导致的内存泄漏 - 与结构化并发天然契合：绑定随
ForkJoinPool或VirtualThread的调度链自动传播
但要注意：它不适用于需要“动态重绑定”的场景（比如一个请求中途切换租户 ID），因为 where() 是嵌套式覆盖，不是可变更新。
常见误用和兼容性陷阱
Scoped Values 不是万能上下文总线。它被刻意限制，所以容易踩坑：
- 不能绑定
ArrayList、HashMap等可变容器 —— 即使声明为final，内容仍可变，编译器会拒绝 - 不能在
Runnable或Callable外部提前get()，必须确保已进入where()包裹的作用域 - 在传统线程池（如
FixedThreadPool）中，子任务不会自动继承绑定 —— 需显式用ScopedValue.copyTo()手动传播（Java 22 尚未提供，需自行封装） - Android 和多数 JDK 21 及更早版本不支持，必须确认运行时是 JDK 22+ 且启用预览特性（
--enable-preview）
真正关键的一点是：Scoped Values 的价值不在“共享”，而在“消除共享副作用”——它让你把上下文当作函数参数的语法糖来用，而不是一个需要小心维护的全局状态容器。
