发布于 由码界行者

作用域值：Java开发者期待已久的ThreadLocal现代替代方案

内容目录

如果你曾编写过多线程Java应用程序，很可能接触过ThreadLocal变量。自Java 1.2引入以来，它已存在超过25年，帮助开发者在线程内共享数据而无需通过每个方法参数传递。但时代在变，Java也在演进。随着虚拟线程和Project Loom的出现，传统的ThreadLocal方式已显陈旧。作用域值（Scoped Values）应运而生：一种更简洁、高效且安全的替代方案，正在重塑我们对线程局部数据的认知。

ThreadLocal的问题：为何需要变革

想象一下：你正在构建一个处理数千个并发请求的Web应用程序。每个请求需要在处理生命周期（从Web控制器到服务层，再到数据访问组件）中携带用户认证信息。传统做法是使用ThreadLocal。

public class ThreadLocalExample {
    private static final ThreadLocal<String> userContext = new ThreadLocal<>();

    public static void main(String[] args) {
        userContext.set("Admin");
        System.out.println("User: " + userContext.get());
        userContext.remove(); // 千万别忘记这一步！
    }
}

但问题在于：ThreadLocal在现代应用中存在以下日益突出的缺陷：

  1. 内存泄漏隐患
    必须手动调用remove()，否则可能导致内存泄漏。忘记清理？随着线程不断累积废弃值，你的应用会逐渐耗尽内存。这就像离开每个房间后都不关灯——最终会导致电路过载。

  2. 可变性混乱
    ThreadLocal值可在任意位置、任意时间被修改。这种“远距离幽灵作用”（借用爱因斯坦描述量子力学的比喻）使得调试极其困难。哪个方法修改了值？何时修改？为何修改？在复杂的调用链中追踪这些问题如同大海捞针。

  3. 昂贵的继承开销
    当父线程使用InheritableThreadLocal创建子线程时，整个线程局部映射会被复制。对于虚拟线程（可能同时存在10万个线程），这种内存压力将无法承受。

  4. 生命周期模糊
    ThreadLocal值会持续存在于线程的整个生命周期，除非显式移除。数据应在何处可访问、何处不可访问的边界并不清晰。

作用域值：我们需要的解决方案

作为Java 20的孵化器功能引入，并在Java 21和22中持续优化，作用域值解决了ThreadLocal的所有痛点，同时为虚拟线程时代量身定制。

作用域值的不同之处
可将作用域值视为ThreadLocal更智能、更规范的“兄弟”。其核心变革如下：

import java.lang.ScopedValue;

public class ScopedValuesExample {
    private static final ScopedValue<String> USER_CONTEXT = ScopedValue.newInstance();

    public static void main(String[] args) {
        ScopedValue.where(USER_CONTEXT, "Admin").run(() -> {
            System.out.println("User: " + USER_CONTEXT.get());
            processRequest(); // 嵌套调用中值仍可访问
        });
        // USER_CONTEXT 在此自动清理！无需手动清除
    }

    private static void processRequest() {
        System.out.println("仍可访问: " + USER_CONTEXT.get());
    }
}

这里发生了什么？值“Admin”仅在run() lambda作用域内绑定到USER_CONTEXT。一旦作用域结束，值会自动消失。无需手动清理，没有内存泄漏，只有清晰可靠的行为。

核心原则：为何作用域值更优

  1. 设计上的不可变性
    一旦将值绑定到ScopedValue，在该作用域内就无法更改。这不是限制，而是特性——它消除了因意外变更导致的整类错误。
ScopedValue.where(USER_CONTEXT, "Admin").run(() -> {
    // 不存在set()方法！
    // 值在整个作用域内保持为"Admin"
    callServiceLayer();
    callDataAccessLayer();
    // 所有方法看到相同且不变的值
});
  1. 显式的有限生命周期
    代码的语法结构清晰展示了数据的可访问范围。看到那些花括号了吗？那就是作用域，也是值的存活范围。超出之后，值即消失。

这不仅是内存管理问题，更关乎认知负荷。你可以一眼理解数据流，无需在代码中费力追踪ThreadLocal值可能被修改或清理的位置。

  1. 极速性能
    由于不可变性，JVM可以积极优化作用域值的访问。无论方法调用嵌套多深，通过get()读取作用域值的速度通常堪比读取局部变量。该实现采用轻量级缓存机制，使得重复访问几乎零开销。

对虚拟线程而言，这一点至关重要。在可能存在数百万个并发线程的情况下，每个字节和每个CPU周期都至关重要。

  1. 零成本继承
    当将作用域值与结构化并发（Java 21的另一预览功能）结合使用时，子线程会自动继承父线程的值。但神奇之处在于：由于值不可变，没有复制开销，本质上只是传递指针。
private static final ScopedValue<String> REQUEST_ID = ScopedValue.newInstance();

ScopedValue.where(REQUEST_ID, "REQ-12345").run(() -> {
    try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
        // 子线程自动看到REQUEST_ID
        scope.fork(() -> processPartA());
        scope.fork(() -> processPartB());
        scope.join();
    }
});

processPartA()和processPartB()都能看到“REQ-12345”且无需任何复制。用ThreadLocal可无法高效实现这一点！

实际案例：构建Web框架上下文

让我们通过一个实际场景（处理包含用户认证和事务管理的Web请求）来展示作用域值的优势：

public class WebFramework {
    private static final ScopedValue<Principal> LOGGED_IN_USER = ScopedValue.newInstance();
    private static final ScopedValue<Connection> DB_CONNECTION = ScopedValue.newInstance();

    public void handleRequest(Request request) {
        Principal user = authenticate(request);
        Connection conn = getConnection();

        ScopedValue.where(LOGGED_IN_USER, user)
                   .where(DB_CONNECTION, conn)
                   .run(() -> {
                       processRequest(request);
                   });

        // conn和user自动清理
    }

    private void processRequest(Request request) {
        // 调用链中的任何方法均可访问这些值
        Principal currentUser = LOGGED_IN_USER.get();
        Connection db = DB_CONNECTION.get();

        // 业务逻辑在此处理
        serviceLayer.process();
        dataAccessLayer.save();
    }
}

注意我们无需进行以下操作：

  • 无需通过每个方法参数传递user和conn
  • 无需手动清理代码
  • 无需担心其他方法修改这些值
  • 即使抛出异常也不会内存泄漏

框架处理请求、绑定必要上下文、通过各层处理请求，并在完成后自动清理。非常优雅。

多线程示例：随机数生成

以下完整示例展示不同线程如何获取各自的作用域值：

import java.lang.ScopedValue;
import java.util.concurrent.Executors;

public class MultiThreadExample {
    private static final ScopedValue<Integer> RANDOM_NUMBER = ScopedValue.newInstance();

    public static void main(String[] args) {
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            for (int i = 0; i < 10; i++) {
                executor.submit(() -> {
                    int randomValue = (int) (Math.random() * 100);
                    ScopedValue.where(RANDOM_NUMBER, randomValue).run(() -> {
                        System.out.println(Thread.currentThread().getName() + 
                                         ": 随机数: " + RANDOM_NUMBER.get());
                        doSomeWork();
                    });
                });
            }
        }
    }

    private static void doSomeWork() {
        // 此处仍可访问RANDOM_NUMBER
        System.out.println("正在处理: " + RANDOM_NUMBER.get());
    }
}

每个虚拟线程获取自己的随机数，并在其作用域内可访问。简单、清晰、高效。

作用域值 vs. ThreadLocal：何时使用

以下情况，使用作用域值

  • 使用虚拟线程（Project Loom）
  • 需要共享不可变上下文数据（用户信息、请求ID、事务上下文）
  • 需要自动清理和有限生命周期
  • 使用结构化并发并需要高效的子线程继承
  • 希望代码更易理解和维护

以下情况，继续使用ThreadLocal

  • 需要真正的每线程可变存储
  • 缓存创建成本高的对象（如DateFormat实例）
  • 处理无法重构的遗留系统
  • 数据确实需要在线程整个生命周期内持久存在

技术深度解析：实际工作原理

在底层，作用域值采用复杂但轻量的实现，涉及两个关键组件：

  • 载体（Carrier）：保存ScopedValue与其实际值之间的绑定
  • 快照（Snapshot）：在特定时间点捕获所有绑定的状态

当你调用ScopedValue.where(KEY, value).run(...)时，JVM会创建一个新的载体来关联该键值对。ScopedValue对象本身如同映射键——一个用于在载体栈中查找值的唯一指针。

其精妙之处在于缓存：首次调用get()时，会搜索外围作用域以找到绑定，然后将结果缓存到小型线程局部缓存中。后续访问速度极快——可能堪比读取局部变量。

专业提示：如需绑定多个值，可创建记录类来保存它们，并将单个ScopedValue绑定到该记录实例。这能最大化缓存效率：

record RequestContext(Principal user, Connection db, String requestId) {}

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

ScopedValue.where(CONTEXT, new RequestContext(user, conn, "REQ-123"))
           .run(() -> processRequest());

现状与未来

截至2025年11月，作用域值已从孵化器（Java 20）经过预览状态（Java 21、22），并有望成为永久功能。该API在多个预览周期中保持稳定，表明其已接近正式发布。

在Java 21-23中使用作用域值，当前需要启用预览功能：

javac --release 23 --enable-preview YourProgram.java
java --enable-preview YourProgram

一旦功能定稿（可能在Java 24或25），将不再需要预览标志。

结论

作用域值代表了对多线程Java应用中数据共享方式的根本性重新思考。通过拥抱不可变性、显式作用域和性能优化，它们解决了ThreadLocal的所有主要弱点，同时完美适应虚拟线程革命。

你无需急于替换代码库中的每个ThreadLocal。但对于新代码——尤其是为虚拟线程和结构化并发设计的代码——作用域值应是默认选择。它们更安全、更快速、更清晰、更易维护。

明确的信息是：对于面向虚拟线程和结构化并发的新Java应用，作用域值应成为共享上下文数据的首选。它们使代码更安全、更快速，且显著更易理解。

Java并发的未来已至，而且拥有精美的作用域。

本文要点总结

在服务超过25年后，ThreadLocal在现代Java应用中显现出明显局限性。手动清理要求带来内存泄漏风险，可变性导致意外状态变化，继承机制开销昂贵，生命周期模糊不清——这些问题在使用虚拟线程时尤为突出。

作用域值通过其核心设计解决了这些问题。它们提供自动生命周期管理以消除内存泄漏顾虑，不可变性防止意外变更，有限作用域使数据生命周期显式化。性能表现强劲，通过优化缓存实现快速访问，高效的继承机制允许与子线程零成本共享值。

编程模型以显式作用域为核心。值通过ScopedValue.where(KEY, value).run(...)绑定，在嵌套方法调用中自动可访问，并在作用域结束时自动清理。这种方法与虚拟线程（JEP 444）和结构化并发（JEP 453）良好集成，为现代并发编程创建了连贯的基础。

性能特性适合实际使用。通过智能缓存，读取作用域值的速度接近局部变量，轻量级实现可处理数百万虚拟线程而无ThreadLocal的内存压力。常见用例包括Web请求上下文、用户认证数据、事务管理、请求追踪，以及任何需要通过调用链传播不可变上下文的场景。

作用域值和ThreadLocal之间的选择取决于需求。作用域值适用于现代代码中的不可变上下文共享，而ThreadLocal仍适用于每线程可变缓存和遗留系统。该功能从Java 20的孵化器状态演进至Java 21-23的预览阶段，API稳定性表明它即将成为永久功能。

当需要绑定多个值时，将它们分组到记录类并绑定单个ScopedValue可最大化缓存效率并简化代码。更广泛地说，作用域值代表了向更安全、更易理解的并发编程的转变，与Java向轻量级、高并发应用发展的方向一致。

【注】本文译自：Scoped Values: The Modern Alternative to ThreadLocal That Java Developers Have Been Waiting For

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注