编程面试题：Java 25 的 ScopedValue 如何安全传播请求上下文？

题干与适用场景

一个 Java 服务需要把 trace ID、租户或安全主体传给深层回调和虚拟线程，但不希望每层方法都增加参数，也不希望线程池复用造成上下文泄漏。请说明 Java 25 ScopedValue 的词法作用域、绑定与重绑定、Carrier、虚拟线程和结构化并发行为，并给出从 ThreadLocal 迁移的边界。

面试官考察点

能否解释隐式上下文的可见范围和生命周期。
是否理解 ScopedValue 绑定只在 run、call 或 where 作用域内可读。
能否区分不可变快照传播与可变线程本地状态。
能否处理嵌套绑定、子任务、异常和取消。
能否识别安全主体、可变对象和线程池迁移的风险。

回答前需要澄清的问题

上下文是请求级只读值，还是需要在线程之间写回的可变状态？
任务使用虚拟线程、结构化并发还是传统线程池？
子任务是否必须继承上下文，是否允许覆盖某个键？
需要支持哪些 JDK 版本，迁移能否分阶段进行？

30 秒回答框架

我会把请求上下文建模为不可变值，用 ScopedValue.where(key, value).run 或 call 建立词法作用域。作用域内的深层代码通过键读取，退出后自动解除绑定；嵌套作用域可以临时重绑定，Carrier 本身不可变且线程安全。对于虚拟线程和结构化并发，它比可变 ThreadLocal 更容易约束生命周期，但不适合需要跨作用域写回的状态；迁移时保留显式参数和旧实现的边界测试。

分步骤深入解答

1. 定义上下文键

使用私有的 ScopedValue 键，把 trace ID、tenant ID 和主体封装在不可变 Context 中。不要把可变 map 或可写会话对象直接暴露给深层代码。

2. 建立词法作用域

java

static final ScopedValue<RequestContext> REQUEST = ScopedValue.newInstance();

ScopedValue.where(REQUEST, context).run(() -> handle(request));

handle 的深层调用可以读取当前绑定，但作用域结束后值不再可见。这样生命周期与代码块绑定，不依赖线程何时回收。

3. 读取与缺省处理

读取前可用 isBound() 判断，或用 orElse 提供明确的内部默认值。安全主体等必需上下文应使用 orElseThrow，避免静默以匿名身份执行。

4. 解释 Carrier

ScopedValue.Carrier 是不可变且线程安全的键值映射；连续调用 where 会返回新的 carrier。把多个上下文绑定组装后再调用 run 或 call，不要共享可变 carrier。

5. 处理嵌套重绑定

内层 where 可以为同一个键临时绑定新值，内层结束后外层值恢复。审查时要画出作用域树，确认回调、异常处理和日志不会读取错误租户或主体。

6. 配合虚拟线程与结构化并发

把任务放在词法作用域内创建，使子任务能获得约定的上下文快照。取消或异常结束时作用域仍会退出，不需要手动清理线程本地变量；仍要明确哪些子任务可以覆盖键。

7. 与 ThreadLocal 比较

ThreadLocal 适合需要线程关联和可变写入的旧 API，但在线程池复用时容易忘记清理。ScopedValue 倾向只读、短生命周期和受限可见性，不能直接替代所有 ThreadLocal，尤其是需要跨回调修改状态的场景。

8. 设计迁移与观测

先定义上下文 schema、允许读取的模块和 JDK 兼容矩阵，再用适配层让旧代码逐步读取 ScopedValue。记录未绑定异常、跨线程边界、嵌套覆盖和请求结束后的对象引用，防止把隐式上下文变成难以追踪的全局变量。

设计取舍与边界

ScopedValue 传递的是绑定引用；值本身若可变，仍可能产生数据竞争和越权修改。它不能让任意新线程自动获得业务语义，也不能替代显式参数、认证策略或取消协议。Java 25 的 API 适合在明确 JDK 基线和结构化并发模型下采用，旧版本需要保留兼容方案。

落地计划与证据

列出现有 ThreadLocal 的键、写入点、清理点和跨线程边界。
为只读请求上下文创建 ScopedValue key 与不可变类型。
用 where(...).run/call 包住请求入口和结构化任务创建点。
测试嵌套重绑定、异常、取消、虚拟线程、线程池复用和未绑定访问。
以 Oracle Java 25 API 对 ScopedValue、Carrier、访问控制和结构化并发的说明作为发布依据。

常见误区与追问

误区一：把 ScopedValue 当作可变全局变量

键控制可见性，但绑定对象仍可能可变。应使用不可变 context，并限制写操作。

误区二：忘记作用域边界

作用域结束后读取会失败或回到外层绑定。必须明确入口、回调和异步任务的创建位置。

误区三：所有 ThreadLocal 都直接替换

需要跨作用域写回或旧 JDK 支持的代码仍有不同约束。先分类，再迁移只读请求上下文。

误区四：假设任意线程都自动继承

上下文传播要和任务创建、执行器和结构化并发策略一起设计，不能只看线程名称。

误区五：忽略安全主体覆盖

嵌套重绑定可能改变审计身份。安全主体应不可变、必需时强制存在，并对覆盖行为留痕。