package com.hugh.java17.v21;import java.lang.ScopedValue;public class ScopeValueTest {// 定义一个作用域值（类似“上下文的key”）private static final ScopedValue<String> GIFT = ScopedValue.newInstance();// 赠送礼物的方法：绑定值并执行接收逻辑public static void giveGift() {// 绑定 GIFT 的值为“手机”，并在作用域内执行 receiveGift()ScopedValue.where(GIFT, "手机").run(() -> receiveGift());}// 接收礼物的方法：从作用域中获取值public static void receiveGift() {// 获取当前作用域内 GIFT 的值String gift = GIFT.get();System.out.println("收到礼物：" + gift); // 输出：收到礼物：手机}public static void main(String[] args) {giveGift(); // 调用赠送方法，触发整个流程}
}代码理解
ScopedValue Java 中的作用域值，用于在限定作用域内传递上下文信息
ScopedValue.where(...).run(...) 的设计看起来确实和“投放后随时取用”的直觉不太一样，但这恰恰是它的核心特性——严格限定作用域。我们可以从“为什么不能分开写”和“这种设计的好处”两个角度来理解：
1. 为什么不能把 where 和 run 分开？
假设我们尝试“先投放再取用”，比如：
// 错误示例：尝试分开写
ScopedValue.where(GIFT, "手机"); // 假设这里只是“投放”
receiveGift(); // 再调用“取用”
这种写法会失效，因为 ScopedValue 的核心是 “绑定值只在 run 方法执行的代码块内有效”。where 方法本身并不直接“投放”值，而是创建一个“绑定描述”，必须通过 run（或 call）来指定这个绑定生效的作用域范围（即 run 里的 Lambda 表达式）。
离开这个作用域后，绑定自动失效。这就像“临时借东西”：where 是“准备好要借的东西”，run 是“指定借东西的时间段和用途”，时间段外东西就还回去了。
2. 这种设计的好处：避免“全局污染”
如果允许“投放后随时取用”，就会变成类似全局变量的效果：
- 不同地方的代码可能意外修改或读取到不该访问的值；
- 多线程环境下，线程 A 的绑定可能被线程 B 误读，导致混乱。
而 where(...).run(...) 的设计强制要求：
- 绑定的生效范围精确可控（就是
run里的代码）； - 超出范围后自动失效，不会影响其他代码；
- 多线程安全：每个线程的
run作用域是独立的，互不干扰。
3. 换个角度理解：它像一个“带参数的代码块”
可以把 ScopedValue.where(GIFT, "手机").run(()->{...}) 理解为：
“执行
{...}里的代码时，给它传一个‘隐藏参数’GIFT = "手机"，这个参数只在{...}里能用。”
而 receiveGift() 就是这个代码块里的逻辑，它通过 GIFT.get() 拿到了这个“隐藏参数”。
这种方式比直接传参更灵活（比如多层嵌套调用时，不需要每层方法都显式声明参数），但又比全局变量更安全（严格限定范围）。
总结来说，run 方法的作用是划定绑定生效的“生命周期”，这正是 ScopedValue 区别于全局变量或普通参数传递的关键——既解决了上下文传递的问题，又避免了全局污染。习惯这种“绑定+范围”的组合写法后，就能体会到它在复杂场景（如多线程、多层调用）中的优势了。