题干与适用场景
面试官可能会问：“Java 25 的 ScopedValue 解决了什么问题？请比较它与 ThreadLocal，并说明在线程池或虚拟线程中的正确用法。”
JEP 506 将 Scoped Values 在 JDK 25 定稿。它用于让调用者在词法作用域内向深层方法和子线程共享不可变数据，减少为了传递上下文而层层增加参数的需要。题目考察的是生命周期、可见性和并发边界，不能只回答“ThreadLocal 的新名字”。
面试官考察点
- 是否理解 ScopedValue 是不可变、受作用域控制的隐式参数。
- 是否能说明
where(...).run(...)或call(...)的绑定范围和恢复行为。 - 是否识别它与可变 ThreadLocal、线程池复用和虚拟线程继承的差异。
- 是否考虑 key 的访问控制、绑定数量、异常传播和取消。
- 是否知道何时仍应保留 ThreadLocal 或显式参数。
回答前需要澄清的问题
- 共享的是请求 ID、认证主体、租户，还是可变事务状态？
- 数据必须只读吗，子任务是否需要继承？
- 执行模型是平台线程、虚拟线程、结构化并发，还是现有线程池？
- 代码是否可能在作用域外读取 key，或把 Carrier 泄露给不受信调用方？
- 现有框架是否依赖 ThreadLocal 的清理、可变更新或 MDC 集成？
30 秒回答框架
可以这样回答：
ScopedValue 是 Java 25 的不可变、词法作用域上下文机制。调用方用ScopedValue.where(key, value).run(...)或call(...)建立绑定，作用域结束后自动恢复；只有持有 key 的代码能读取它。相比 ThreadLocal，它减少线程池清理和可变状态泄漏，适合请求上下文、虚拟线程和结构化并发。它不替代需要逐步更新的 ThreadLocal，也不能跨出作用域保存引用。实现前我会验证子任务继承、异常和取消行为，并控制 key 的访问权限。
分步骤深入解答
先理解绑定模型
ScopedValue 的值在动态执行范围内可读，但绑定由代码结构明确界定：
static final ScopedValue<String> REQUEST_ID = ScopedValue.newInstance();
ScopedValue.where(REQUEST_ID, "req-42").run(() -> {
audit("start");
handleRequest();
});
static void audit(String message) {
logger.info("{} {}", REQUEST_ID.orElse("missing"), message);
}audit 不必接收请求 ID 参数，但只有在绑定作用域中才能读取有意义的值；作用域结束后，绑定不会继续污染调用线程。
对比 ThreadLocal 的可变性
ThreadLocal 允许每个线程持有可变值，在线程池复用时必须清理，否则下一个请求可能读到旧上下文。ScopedValue 的设计目标是共享不可变值，并通过嵌套绑定覆盖外层值，再在作用域退出后恢复。它减少清理责任，但不能承载需要在深层代码中反复 set 的状态机。
处理子线程与虚拟线程
JEP 506 关注与虚拟线程和结构化并发配合的成本与可推理性。是否自动继承、继承何时发生以及任务执行器的行为必须以目标 JDK 和 API 契约验证，不能把普通线程池的经验直接套用。共享对象本身仍应不可变，避免通过引用绕过上下文边界。
设计 key、异常和兼容路径
key 应是私有静态 final 对象或受控 API 的一部分，不要把可被任意模块持有的全局 key 当作安全边界。读取缺失值时选择 orElse 或显式异常；orElse 的参数在 Java 25 不能是 null。异常离开 run 或 call 时，作用域会结束并恢复外层绑定。需要兼容旧 JDK 时保留显式参数或 ThreadLocal 实现，并用测试矩阵验证行为。
高质量示范回答
我会把 ScopedValue 视为不可变的隐式参数，而不是新的可变 ThreadLocal。请求入口用where(key, value).run或call建立结构化作用域，深层方法通过持有的 key 读取请求 ID、租户或认证主体；退出作用域后绑定自动恢复。它适合虚拟线程和结构化并发中的只读上下文，避免线程池复用造成的清理遗漏。ThreadLocal 仍适合必须逐步更新、且框架已经围绕它构建的状态，但要在 finally 中清理。实现时我会限制 key 可见性，验证子任务继承、异常、取消和嵌套覆盖，并在旧 JDK 上保留显式参数或兼容实现。
常见错误
- 把 ScopedValue 说成自动清理的可变 ThreadLocal。
- 在作用域外保存 Carrier、值或读取 key，导致生命周期错误。
- 忽略线程池复用、子任务继承和虚拟线程差异。
- 用可变对象作为值，却宣称整个上下文不可变。
- 让任意模块共享 key，把访问控制误当成数据加密。
- 忘记 Java 25
orElse不接受 null，或没有旧 JDK 兼容策略。
追问及应对
1. ScopedValue 能替代所有 ThreadLocal 吗？
不能。它适合只读、作用域明确的上下文；需要在调用链中逐步更新的状态仍可使用 ThreadLocal 或显式参数，并承担清理责任。
2. 嵌套绑定会发生什么？
内层作用域可以临时绑定同一 key 的新值，内层退出后恢复外层值。回答时应说明异常路径也必须退出作用域，不能把内层值泄露到外层。
3. 如何测试并发继承？
分别覆盖平台线程、虚拟线程、结构化任务和线程池复用；检查子任务看到的值、取消后的清理、嵌套覆盖和作用域外读取。测试应固定 JDK 版本与执行器配置。