// Thread.java
ThreadLocal.ThreadLocalMap threadLocals = null;

// ThreadLocalMap内部Entry
static class Entry extends WeakReference<ThreadLocal<?>> {
    Object value;
    
    Entry(ThreadLocal<?> k, Object v) {
        super(k);  // key是弱引用
        value = v; // value是强引用！
    }
}

这里有个非常关键的设计：key（ThreadLocal实例）是弱引用，value是强引用。

2.2 内存泄漏的完整推导

我来画一张引用关系图，这是理解问题的核心：

正常情况：业务代码持有ThreadLocal实例的强引用，Entry的key通过弱引用指向同一个ThreadLocal实例。

发生泄漏的情况：

当业务代码的强引用断开后：

GC触发，ThreadLocal实例只剩弱引用，被回收
Entry的key变成null
但Entry.value仍然是强引用，Value对象无法被回收
ThreadLocalMap里积累大量key=null的"僵尸Entry"
线程不死（线程池），Value对象永远无法回收 → OOM

2.3 ThreadLocalMap的启发式清理机制

ThreadLocalMap内部有两种清理机制，但都不能完全依赖：

探测式清理（expungeStaleEntry）：线性探测，清理一段连续的key=null的Entry。只在get/set/remove时触发，不会主动运行。

启发式清理（cleanSomeSlots）：在set操作时调用，以log2(n)次为上限扫描若干槽位。也是被动触发。

这两种机制的问题在于：如果应用只写不读，或者访问的key恰好避开了这些清理路径，那些"僵尸Entry"就永远不会被清理。

三、标准答案 + 代码验证

3.1 验证弱引用的行为

import java.lang.ref.WeakReference;

public class WeakRefDemo {
    
    public static void main(String[] args) throws InterruptedException {
        // 创建一个对象，并用弱引用持有它
        Object obj = new Object();
        WeakReference<Object> weakRef = new WeakReference<>(obj);
        
        System.out.println("GC前：" + weakRef.get()); // 不为null
        
        // 断开强引用
        obj = null;
        
        // 触发GC
        System.gc();
        Thread.sleep(100);
        
        System.out.println("GC后：" + weakRef.get()); // null，对象被回收了
    }
}

3.2 模拟ThreadLocal内存泄漏

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class ThreadLocalLeakDemo {
    
    // 模拟一个持有大对象的ThreadLocal
    private static ThreadLocal<byte[]> threadLocal = new ThreadLocal<>();
    
    public static void main(String[] args) throws InterruptedException {
        ExecutorService pool = Executors.newFixedThreadPool(5);
        
        for (int i = 0; i < 1000; i++) {
            final int taskId = i;
            pool.submit(() -> {
                // 每个任务往ThreadLocal放入1MB数据
                threadLocal.set(new byte[1024 * 1024]);
                
                // 模拟业务处理
                doWork(taskId);
                
                // 危险！没有调用remove()
                // threadLocal.remove(); 
            });
        }
        
        Thread.sleep(5000);
        System.out.println("任务完成，但内存已泄漏");
        pool.shutdown();
    }
    
    static void doWork(int taskId) {
        byte[] data = threadLocal.get();
        // 处理数据...
        System.out.println("Task " + taskId + " 处理了 " + data.length + " 字节");
    }
}

3.3 正确使用ThreadLocal的规范写法

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class ThreadLocalCorrectUsage {
    
    private static final ThreadLocal<UserContext> USER_CONTEXT = new ThreadLocal<>();
    
    public static void main(String[] args) {
        ExecutorService pool = Executors.newFixedThreadPool(10);
        
        for (int i = 0; i < 100; i++) {
            final int userId = i;
            pool.submit(() -> processRequest(userId));
        }
        
        pool.shutdown();
    }
    
    static void processRequest(int userId) {
        try {
            // 设置上下文
            USER_CONTEXT.set(new UserContext(userId, "user_" + userId));
            
            // 业务处理（多层调用无需传参）
            serviceA();
            serviceB();
            
        } finally {
            // !!!! 必须在finally中remove，保证异常时也能清理
            USER_CONTEXT.remove();
        }
    }
    
    static void serviceA() {
        UserContext ctx = USER_CONTEXT.get();
        System.out.println("ServiceA 处理用户: " + ctx.getUserId());
    }
    
    static void serviceB() {
        UserContext ctx = USER_CONTEXT.get();
        System.out.println("ServiceB 处理用户: " + ctx.getUserId());
    }
    
    static class UserContext {
        private final int userId;
        private final String userName;
        
        UserContext(int userId, String userName) {
            this.userId = userId;
            this.userName = userName;
        }
        
        public int getUserId() { return userId; }
        public String getUserName() { return userName; }
    }
}

3.4 使用InheritableThreadLocal传递父子线程上下文

public class InheritableThreadLocalDemo {
    
    // InheritableThreadLocal：子线程可以继承父线程的值
    private static final InheritableThreadLocal<String> TRACE_ID = 
        new InheritableThreadLocal<>();
    
    public static void main(String[] args) throws InterruptedException {
        TRACE_ID.set("trace-12345");
        System.out.println("父线程 traceId: " + TRACE_ID.get());
        
        Thread child = new Thread(() -> {
            // 子线程能获取到父线程设置的值
            System.out.println("子线程 traceId: " + TRACE_ID.get());
            // 但！线程池中的复用线程不会重新继承，需要用TTL（TransmittableThreadLocal）
        });
        child.start();
        child.join();
        
        // 注意：线程池场景请使用阿里开源的TTL
        // TransmittableThreadLocal<String> ttl = new TransmittableThreadLocal<>();
        
        TRACE_ID.remove();
    }
}

四、面试官追问

追问1：为什么ThreadLocalMap的Entry要把key设计成弱引用，而不是把value也设计成弱引用？

我的回答：这是个很有意思的问题。key用弱引用，是为了在ThreadLocal实例不再被外部代码引用时，允许GC回收ThreadLocal对象本身，避免ThreadLocal实例的内存泄漏。value不能用弱引用，因为value是用户的业务数据，用户把数据存进去就是希望能取出来用的，如果value是弱引用，可能一次GC之后数据就没了，ThreadLocal就失去了意义。所以这是一个权衡：宁可牺牲一部分value泄漏的风险，也要保证ThreadLocal实例本身可以被回收。真正防止value泄漏的手段，是要求用户自己调用remove()。

追问2：如果我确实忘记调用remove()，JVM内部有没有什么机制可以帮我清理？

我的回答：有，但不可靠。ThreadLocalMap在每次get()、set()时，遇到key为null的Entry会触发探测式清理，把value引用也断掉，让GC可以回收value对象。但这个清理是被动触发的，如果线程一直不访问ThreadLocal，清理就不会发生。另外，线程死亡时，threadLocals字段会被置为null，整个ThreadLocalMap都会被GC回收，自然也包括所有value。所以线程池才是最危险的场景——线程永不死亡，而且可能很长时间不访问某个ThreadLocal。

追问3：Spring框架里有哪些地方用到了ThreadLocal？

我的回答：Spring大量使用ThreadLocal来绑定请求级别的上下文。最典型的是事务管理，TransactionSynchronizationManager用ThreadLocal存储当前线程的数据库连接，保证同一个线程内的多次数据库操作使用同一个连接，从而实现事务传播。RequestContextHolder用ThreadLocal存储当前HTTP请求和响应对象，让你在Service层也能通过RequestContextHolder.getRequestAttributes()获取到请求信息。SecurityContextHolder用ThreadLocal存储当前用户的认证信息。这些框架级的ThreadLocal都是由框架负责remove的，用户感知不到，但如果你自己用ThreadLocal，就必须自己管理。

追问4：TransmittableThreadLocal解决了什么问题？

我的回答：InheritableThreadLocal可以让新创建的子线程继承父线程的ThreadLocal值，但在线程池中这个机制失效了，因为线程池的线程是复用的，不会重新从提交任务的线程继承值。阿里的TransmittableThreadLocal（TTL）解决了这个问题，它通过对Runnable和Callable进行包装，在任务提交时捕获当前线程的TTL值，在任务执行时将这些值注入到执行线程中，执行完后再清理掉注入的值，恢复执行线程原有的TTL状态。

五、同类题目举一反三

1. Java中有哪几种引用类型，区别是什么？

Java有四种引用：强引用（普通new出来的）、软引用（SoftReference，内存不足时回收，适合做缓存）、弱引用（WeakReference，GC时直接回收，ThreadLocalMap.Entry的key用的就是弱引用）、虚引用（PhantomReference，随时可能被回收，主要用于跟踪对象被GC的时机，DirectByteBuffer的Cleaner就用了虚引用）。

2. WeakHashMap和ThreadLocalMap有什么相似之处？

两者都用弱引用作为key，GC后key变成null。WeakHashMap会在每次操作时清理key为null的Entry（通过expungeStaleEntries方法），而ThreadLocalMap的清理是探测式的，相对不彻底。两者都适合用作与对象生命周期绑定的缓存。

六、踩坑实录

坑一：Web容器线程复用导致上下文污染

在Tomcat这类Web容器中，每个请求都由线程池中的线程处理。有一次我们的系统出现了一个诡异的bug：用户A提交了一个请求，但日志里显示操作人是用户B。排查后发现：处理用户B的线程在请求结束后没有清理ThreadLocal里的用户信息，这个线程被复用来处理用户A的请求时，ThreadLocal里还残留着用户B的数据。

修复方案是在Filter或拦截器的finally块中统一清理所有ThreadLocal，而不是依赖业务代码自己清理。

坑二：子线程访问不到父线程的ThreadLocal数据

有个同事写了一个异步日志的功能，主线程把traceId放进ThreadLocal，然后提交一个Runnable到线程池做异步处理，想在异步任务里打印同一个traceId。但日志里traceId是null。

原因就是普通ThreadLocal不在线程间传递。解决方案有三个：手动把traceId作为参数传给Runnable（最简单）、用InheritableThreadLocal（线程池无效）、用阿里的TTL框架（最完整的方案）。

坑三：static ThreadLocal导致的隐蔽泄漏

有人写了这样的代码：

public class SomeService {
    // 非static，每个SomeService实例持有一个ThreadLocal实例
    private ThreadLocal<Connection> connHolder = new ThreadLocal<>();
}

如果SomeService本身是单例（Spring Bean），这个非static的ThreadLocal其实也只有一个实例，问题不大。但如果SomeService被频繁创建和销毁，每次创建都生成一个新的ThreadLocal实例，这些ThreadLocal实例可能在Thread的ThreadLocalMap里留下key，即使ThreadLocal对象本身因为弱引用被GC了，value还是可能残留一段时间。

规范写法是：ThreadLocal应该声明为static final，保证一个类只有一个ThreadLocal实例。

坑四：MDC导致的内存泄漏

我们项目里用了SLF4J的MDC（Mapped Diagnostic Context）来做链路追踪。MDC底层就是ThreadLocal。有个服务每处理一个请求就往MDC放N个key，但只在正常流程中清理，异常分支没有清理。线程池里的线程处理大量请求后，每个线程的MDC里积累了成百上千个过期的key-value对，虽然不会直接OOM，但增加了GC压力，也让日志输出包含大量无用的上下文信息。

七、总结

ThreadLocal内存泄漏的本质是：Entry的value是强引用，而Thread（尤其是线程池中的线程）的生命周期远比ThreadLocal的使用生命周期长，导致value对象无法被GC回收。

记住这三条铁律：

使用ThreadLocal必须在finally块中调用remove()
ThreadLocal必须声明为static final
线程池场景需要格外注意，考虑使用TTL框架

面试时如果能把弱引用机制、线程池复用、探测式清理这三个层次都讲清楚，配合一两个实际案例，基本上这道题就拿满分了。