【无标题】 - 技术栈

在实际开发中，我们经常会遇到 ThreadLocal 取值为 null 的情况，排查起来往往无从下手。本文将详细拆解 ThreadLocal 取不到值的三种核心原因，结合原理、场景和代码示例，帮助大家快速定位并解决问题。

一、三种核心原因

最常见原因：多个线程操作 ThreadLocal

这是开发中最易出现的情况，本质是对 ThreadLocal 的核心设计理念理解不到位------ThreadLocal 的变量副本是绑定到具体线程的，每个线程都有自己独立的副本，线程之间的副本相互隔离、互不影响。

原理解析： ThreadLocal 内部维护了一个 ThreadLocalMap，这个 Map 是线程（Thread）的私有属性（threadLocals），而非 ThreadLocal 自身的属性。当我们调用 threadLocal.set(value) 时，是向当前线程（Thread.currentThread()）的 ThreadLocalMap 中存入键值对（键为当前 ThreadLocal 对象，值为变量副本）；调用 threadLocal.get() 时，也是从当前线程的 ThreadLocalMap 中根据当前 ThreadLocal 对象取对应的值。

问题场景： 如果线程 A 调用 set 存入值，线程 B 调用 get 取值，由于线程 B 的 ThreadLocalMap 中没有线程 A 存入的键值对，自然会返回 null。这种问题常出现在多线程任务、线程池复用场景中。

代码示例：

java 复制代码

public class ThreadLocalMultiThreadTest {
    private static final ThreadLocal<String> threadLocal = new ThreadLocal<>();

    public static void main(String[] args) {
        // 线程1：存入值
        new Thread(() -> {
            threadLocal.set("线程1的变量副本");
            System.out.println("线程1取值：" + threadLocal.get()); // 正常输出：线程1的变量副本
        }).start();

        // 线程2：尝试取值（未存入）
        new Thread(() -> {
            System.out.println("线程2取值：" + threadLocal.get()); // 输出：null
        }).start();
    }
}

易忽略原因：类加载器不同导致取不到值

这种原因相对隐蔽，很多开发者会忽略类加载器的影响，其本质是：不同类加载器加载同一个类（全限定名相同），会生成两个不同的 Class 对象；而 ThreadLocal 作为变量的载体，若其所在的类被不同类加载器加载，会产生多个 ThreadLocal 实例，导致 set 和 get 操作的不是同一个 ThreadLocal 对象，最终取不到值。

原理解析： Java 中，一个类的唯一性由「类加载器 + 类全限定名」共同决定。假设我们有一个类 A，里面定义了 static ThreadLocal 变量，当类加载器1（如系统类加载器）加载类 A 时，会创建 ClassA1 和 ThreadLocal1；当类加载器2（如自定义类加载器）加载类 A 时，会创建 ClassA2 和 ThreadLocal2。此时，ThreadLocal1 和 ThreadLocal2 是两个完全独立的对象，调用 ThreadLocal1.set() 存入的值，在 ThreadLocal2.get() 中无法获取（因为存入的是当前线程 ThreadLocalMap 中 ThreadLocal1 对应的键值对，ThreadLocal2 作为不同的键，自然找不到对应值）。

问题场景： 常见于Spring Boot DevTools 热部署等场景。

代码示例：

java 复制代码

import org.apache.commons.io.IOUtils;
import java.io.ByteArrayOutputStream;
import java.io.InputStream;
import java.util.function.Supplier;

public class StaticClassLoaderTest implements Supplier<Integer> {

    // 静态ThreadLocal变量（类加载器不同时，会产生多个该变量实例）
    protected static final ThreadLocal<Integer> local = new ThreadLocal<Integer>();

    public StaticClassLoaderTest() {
    }

    // 存入值：向当前线程的ThreadLocalMap中存入local（当前类加载器对应的实例）和值
    public void setInfo(Integer val) {
        local.set(val);
        System.out.println("set成功，当前类加载器：" + this.getClass().getClassLoader());
    }

    public static void main(String[] args) {
        try {
            // 1. 使用系统类加载器（AppClassLoader）加载当前类，创建实例并存入值
            StaticClassLoaderTest supplier1 = new StaticClassLoaderTest();
            supplier1.setInfo(2); // 此时存入的是「AppClassLoader加载的local实例」对应的值

            // 2. 使用自定义类加载器（cusLoader）加载当前类，创建实例并尝试取值
            // 自定义类加载器加载的StaticClassLoaderTest，与系统类加载器加载的是不同的Class对象
            Supplier<Integer> staticClassLoaderTest2 = (Supplier<Integer>) 
                    Class.forName("gittest.StaticClassLoaderTest", true, new CusLoader())
                          .newInstance();
            
            // 取值失败：staticClassLoaderTest2的local是「CusLoader加载的local实例」，与supplier1的local不是同一个对象
            System.out.println("自定义类加载器取值：" + staticClassLoaderTest2.get()); // 输出：null

        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    // 自定义类加载器：重写loadClass方法，优先加载指定类
    public static class CusLoader extends ClassLoader {
        @Override
        protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
            // 只拦截当前类的加载
            if (name.contains("StaticClassLoaderTest")) {
                // 从类路径中获取class文件的输入流
                InputStream is = Thread.currentThread().getContextClassLoader()
                        .getResourceAsStream(name.replace(".", "/") + ".class");
                ByteArrayOutputStream output = new ByteArrayOutputStream();
                try {
                    // 读取class文件内容
                    IOUtils.copy(is, output);
                    // 定义Class对象（自定义类加载器加载）
                    return defineClass(name, output.toByteArray(), 0, output.toByteArray().length);
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
            // 其他类仍使用父类加载器加载（遵循双亲委派模型）
            return super.loadClass(name, resolve);
        }
    }

    // 取值方法：从当前线程的ThreadLocalMap中获取local对应的值
    @Override
    public Integer get() {
        System.out.println("get操作，当前类加载器：" + this.getClass().getClassLoader());
        return StaticClassLoaderTest.local.get();
    }
}

代码说明： 运行后会发现，supplier1（系统类加载器）和 staticClassLoaderTest2（自定义类加载器）的类加载器不同，对应的 local 实例也不同，因此 staticClassLoaderTest2.get() 无法获取到 supplier1.setInfo(2) 存入的值，最终返回 null。

特殊原因：父子线程间取值

这种原因主要出现在父子线程场景中：父线程调用 ThreadLocal.set() 存入值后，子线程调用 ThreadLocal.get() 取值，结果为 null。核心原因是：父线程和子线程是两个独立的线程，各自拥有自己的 ThreadLocalMap，子线程不会继承父线程的 ThreadLocalMap 中的数据。

原理解析： ThreadLocal 的变量副本是绑定到具体线程的，父线程的 ThreadLocalMap 是父线程的私有属性，子线程启动时，会初始化自己的 ThreadLocalMap（为空），不会自动复制父线程 ThreadLocalMap 中的键值对。因此，即使父线程已经存入值，子线程调用 get() 时，自己的 ThreadLocalMap 中没有对应的数据，就会返回 null。

**问题场景：**常见于线程池中子线程依赖父线程数据、异步任务（如 CompletableFuture、Thread 子类）、Spring @Async 异步方法等场景。

代码示例：

java 复制代码

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.scheduling.annotation.Async;
import org.springframework.scheduling.annotation.EnableAsync;
import org.springframework.stereotype.Service;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

// 启动类：必须添加@EnableAsync，开启Spring异步功能
@SpringBootApplication
@EnableAsync
public class AsyncThreadLocalTest {
    public static void main(String[] args) {
        SpringApplication.run(AsyncThreadLocalTest.class, args);
    }

    // ThreadLocal工具类：模拟存储父线程（请求线程）的上下文数据
    public static class ThreadLocalUtil {
        private static final ThreadLocal<String> CONTEXT = new ThreadLocal<>();

        public static void setContext(String value) {
            CONTEXT.set(value);
        }

        public static String getContext() {
            return CONTEXT.get();
        }

        public static void remove() {
            CONTEXT.remove();
        }
    }

    // 异步服务类：@Async标注的方法会在独立线程（子线程）中执行
    @Service
    public static class AsyncService {
        // @Async：该方法脱离父线程，在Spring默认线程池的子线程中执行
        @Async
        public void asyncGetContext() {
            // 子线程（异步方法）尝试获取父线程存入的ThreadLocal值
            String context = ThreadLocalUtil.getContext();
            System.out.println("异步方法（子线程）取值：" + context); // 输出：null
            System.out.println("异步方法（子线程）ID：" + Thread.currentThread().getId());
        }
    }

    // 测试控制器：父线程（请求线程）存入值，调用异步方法
    @RestController
    public static class TestController {
        private final AsyncService asyncService;

        // 构造器注入异步服务
        public TestController(AsyncService asyncService) {
            this.asyncService = asyncService;
        }

        @GetMapping("/test/async")
        public String testAsync() {
            // 父线程（请求线程）：存入值到ThreadLocal
            ThreadLocalUtil.setContext("父线程（请求线程）的上下文数据");
            System.out.println("父线程（请求线程）取值：" + ThreadLocalUtil.getContext()); // 正常输出
            System.out.println("父线程（请求线程）ID：" + Thread.currentThread().getId());

            // 调用异步方法：触发子线程执行
            asyncService.asyncGetContext();

            // 清理资源，避免内存泄漏
            ThreadLocalUtil.remove();
            return "异步请求测试完成，查看控制台输出";
        }
    }
}

解决方案：若需要实现 @Async 异步方法（子线程）获取父线程（请求线程）的 ThreadLocal 数据，可结合以下两种方式：

简单场景：使用 Java 自带的 InheritableThreadLocal 替换 ThreadLocal，它会在子线程启动时，自动复制父线程 InheritableThreadLocal 中的数据到子线程；但注意，线程池复用场景下（Spring @Async 默认使用线程池），子线程不会重新初始化，复制逻辑仅执行一次，会导致数据错乱。
实际开发场景（推荐）：使用 TransmittableThreadLocal（TTL）框架，专门解决线程池复用场景下的 ThreadLocal 数据传递问题，完美适配 Spring @Async。只需引入 TTL 依赖，替换 ThreadLocal 为 TransmittableThreadLocal，即可实现异步方法正常获取父线程数据，无需额外复杂配置。

二、总结

ThreadLocal 取不到值，本质都是「set 和 get 操作的线程不匹配 」或「set 和 get 操作的 ThreadLocal 对象不匹配」，具体可归纳为：

多个线程操作：set 和 get 属于不同线程，线程的 ThreadLocalMap 相互独立；
类加载器不同：set 和 get 操作的 ThreadLocal 对象，属于不同类加载器加载的 Class 实例，是两个不同对象；
父子线程：父线程和子线程是独立线程，子线程不会继承父线程的 ThreadLocal 数据。