一、ThreadLocal 核心原理

1. 一句话总结

ThreadLocal 是 线程本地变量，作用是为每个线程独立创建一个变量副本，线程之间互不干扰，实现线程封闭，解决多线程下变量共享的并发安全问题。

2. 底层核心结构（关键！）

很多人误解：ThreadLocal 自己存数据。真实结构：

• 每个 Thread 线程对象内部，都有一个 ThreadLocalMap 成员变量（threadLocals）
• ThreadLocalMap 是一个定制化的 Map。key 是当前 ThreadLocal 对象，是弱引用，GC 后变为 null；value 存的数据，是强引用，只要线程存活就无法回收。
• 一个线程可以关联多个 ThreadLocal，对应 Map 里的多个键值对

3. 核心流程

• 存值（set）：获取当前线程 → 拿到线程的 ThreadLocalMap → 以当前 ThreadLocal 为 key 存数据
• 取值（get）：获取当前线程 → 拿到线程的 ThreadLocalMap → 以当前 ThreadLocal 为 key 取数据
• 线程隔离：不同线程的 Map 是独立的，互不访问

4. 核心源码简化版

// Thread 类源码（核心）
public class Thread implements Runnable {
    // 每个线程自带的 ThreadLocalMap，key=ThreadLocal，value=存储值
    ThreadLocal.ThreadLocalMap threadLocals = null;
}

// ThreadLocal set 方法
public void set(T value) {
    Thread t = Thread.currentThread(); // 获取当前线程
    ThreadLocalMap map = t.threadLocals; // 拿线程自己的 Map
    if (map != null)
        map.set(this, value); // key = 当前 ThreadLocal 对象
    else
        createMap(t, value);
}

二、ThreadLocalMap 与 弱引用（内存泄漏的根源）

1. 关键设计：Entry 继承弱引用

ThreadLocalMap 的内部节点 Entry 定义：

static class Entry extends WeakReference<ThreadLocal<?>> {
    Object value;
    // key：弱引用指向 ThreadLocal 对象
    // value：强引用指向我们存储的数据
    Entry(ThreadLocal<?> k, Object v) {
        super(k);
        value = v;
    }
}

• key(ThreadLocal)：弱引用（WeakReference）
• value (存储数据)：强引用（StrongReference）

2. 弱引用规则

弱引用对象：只要 GC 触发，就会被回收，不管内存是否充足。

三、ThreadLocal 内存泄漏原理

1. 什么是内存泄漏

无用对象（不再使用的对象）持续占用内存，GC 无法回收，导致内存浪费甚至 OOM。

2. 内存泄漏的完整链路

• 使用完 ThreadLocal，把外部强引用置为 null

  ThreadLocal<Object> tl = new ThreadLocal<>();
  tl = null; // 外部强引用断开
  

• Entry 中的 key 是弱引用 → GC 时，ThreadLocal 对象被回收，key 变成 null
• 重点：value 是强引用！
  • 只要线程还存活（比如线程池中的核心线程）
  • Thread → ThreadLocalMap → Entry → value 这条强引用链就一直存在
  • key 为 null 的 Entry 无法访问，value 永远无法被 GC 回收 → 内存泄漏

3. 总结

key 被回收了，但 value 还活着，且永远用不到、也收不回 → 内存泄漏

4. 解决方案

• 使用完必须调用 remove () 清理
• 定义为 static final 全局变量
• 线程池中谨慎使用，做好资源回收

四、为什么要把 key 设计成弱引用？

不是为了制造内存泄漏，而是为了减少内存泄漏的概率：

• 如果 key 用强引用：即使外部 tl=null，Map 还持有 key 强引用 → ThreadLocal 和 value 都无法回收 → 更严重的内存泄漏
• 如果 key 用弱引用：至少 ThreadLocal 能被回收，只剩 value 泄漏 → 降低危害

弱引用不是内存泄漏的原因，线程池 + 没手动清理才是主因。

1. 必须手动调用 remove () 【最重要】

使用完 ThreadLocal 后，一定要调用 remove()，清空当前线程的 Entry：

try {
    tl.set(data);
    // 业务逻辑
} finally {
    tl.remove(); // 强制回收，防止内存泄漏
}

remove() 会直接删除 Entry，同时回收 key 和 value。

2. 定义为 static final 全局变量

让 ThreadLocal 生命周期和应用一致，避免 key 被意外回收：

private static final ThreadLocal<Object> TL = new ThreadLocal<>();

3. 避免在线程池中滥用

线程池线程长期存活，最容易引发内存泄漏，必须严格清理。

五、ThreadLocal与Synchronized的区别

ThreadLocal和synchronized都可以用来解决并发问题，但二者的思路完全相反。

核心区别：

• Synchronized：排队等锁，让多个线程依次使用同一个变量，保证数据一致。
• ThreadLocal：每人一份，让每个线程自己用自己的变量副本，互不干扰。

底层本质区别：

• Synchronized
  • 锁机制，控制同一时间只有一个线程访问共享变量。
  • 牺牲并发效率，保证数据安全一致。
• ThreadLocal
  • 无锁机制，彻底隔离变量，从根源上杜绝并发冲突。
  • 牺牲一点内存，换取极高的并发性能。

适用场景：

• Synchronized 必须共享数据，要保证数据准确。适用于商品库存扣减、订单号生成、全局计数器、共享资源修改。
• ThreadLocal 每个线程需要独立数据，不需要共享，只需要线程安全、传参数。适用于存储用户信息、数据库链接等

六、总结

• ThreadLocal 本质是线程自带的 Map，实现线程间变量隔离
• 内存泄漏根源：key 弱引用被回收 + value 强引用存活 + 线程不销毁
• 根治方案：手动调用 remove ()，最安全、最标准的写法