ScopedValue能避免虚拟线程内存膨胀，因其将值存入栈帧而非为每个虚拟线程分配ThreadLocalMap，执行完自动出栈由GC回收；替换ThreadLocal需声明ScopedValue、用where.run包裹调用链、业务层直接get；跨线程需显式传递或配合StructuredTaskScope；日志集成须自定义Converter调用getOrNull()。
ScopedValue 为什么能避免虚拟线程内存膨胀
ThreadLocal 在虚拟线程场景下会为每个虚拟线程分配独立的 ThreadLocalMap，而虚拟线程数量可达百万级，每个 ThreadLocalMap 至少占用几 KB 内存，最终导致堆内存爆炸。ScopedValue 不依赖线程实例存储，而是将值直接压入当前虚拟线程的栈帧（stack chunk），生命周期绑定到作用域代码块，执行完自动出栈释放 —— 栈帧回收由 GC 自动管理，不产生长期驻留对象。
替换 ThreadLocal 的三步实操（Spring Boot 拦截器场景）
以请求 ID 透传为例，原 ThreadLocal 实现需在拦截器 preHandle 中 set、afterCompletion 中 remove，稍有异常就漏掉 remove；换成 ScopedValue 后完全无需手动清理：
- 声明不可变作用域值：
static final ScopedValue<string> REQUEST_ID = ScopedValue.newInstance();</string> - 在拦截器中用
ScopedValue.where(...).run(...)包裹后续调用链：ScopedValue.where(REQUEST_ID, requestId).run(() -> chain.doFilter(request, response)); - 业务层直接通过
REQUEST_ID.get()获取，无需传递参数或上下文对象
注意：必须确保整个调用链（包括异步回调、子任务）都在 run() 的作用域内；若跨线程提交任务，需显式传递值或配合 StructuredTaskScope 使用。
ScopedValue 在虚拟线程池中的行为差异
当使用 Executors.newVirtualThreadPerTaskExecutor() 提交任务时，ScopedValue 值默认不会自动继承到新虚拟线程 —— 这与 InheritableThreadLocal 不同，但更可控。常见错误是误以为“父子线程自动共享”：
- 正确做法：在父线程作用域内，用
ScopedValue.where(...).run(() -> forkNewTask())，并在forkNewTask()内部再次调用REQUEST_ID.get()，值仍有效 - 错误写法：
executor.submit(() -> REQUEST_ID.get())—— 此处已脱离原始作用域，抛出NoSuchElementException - 若需跨虚拟线程边界传递，应封装为参数传入，或改用
StructuredTaskScope+fork()，其天然支持作用域值继承
日志框架集成的关键细节（MDC 替代方案）
Logback/Log4j 的 MDC 本质是 ThreadLocal<map></map>，无法用于虚拟线程。不能简单把 MDC.put("traceId", ...) 换成 ScopedValue 就完事 —— 日志框架本身不识别 ScopedValue：
- 必须重写
PatternLayout或自定义Converter，在格式化时调用REQUEST_ID.getOrNull() - 推荐封装一个工具类：
ScopedMdc.get("traceId")，内部委托给对应ScopedValue实例，避免散落多处硬编码 - 切勿在
Filter或Appender的构造阶段读取ScopedValue—— 此时作用域尚未建立，会 NPE 或空值
作用域值不是“全局上下文”，它只活在你明确划定的那块代码里；越想让它无感渗透，越要小心它的边界在哪里。
