thread才是真正的数据容器，每个thread实例持有独立的threadlocalmap，其中entry的key为弱引用、value为强引用，get/set/remove操作均在thread内部完成。
要真正看懂 ThreadLocal 的内存结构设计精髓，关键不是盯着 ThreadLocal 类本身，而是顺着调用链，看清它和 Thread、ThreadLocalMap、Entry 四者之间的实际持有关系。它的精妙之处不在“怎么用”，而在“数据到底存在哪”以及“为什么这么存”。
Thread 才是真正的数据容器
每个 Thread 实例内部都持有一个 threadLocals 字段：
- 类型是
ThreadLocal.ThreadLocalMap，初始为null - 这个 Map 不属于
ThreadLocal对象，也不属于全局静态区 - 它只属于当前线程，随线程创建而存在，随线程销毁而释放（理想情况下）
- 换句话说：ThreadLocal 只是“钥匙”，Thread 才是“保险柜”
ThreadLocalMap 是定制哈希表，不是 HashMap
它不继承 HashMap，而是 JDK 内部自研的轻量级哈希结构：
- 底层是
Entry[] table数组，采用开放地址法（线性探测）解决哈希冲突 - Entry 是静态内部类，且继承
WeakReference<threadlocal>></threadlocal> - key 是弱引用指向 ThreadLocal 实例，value 是强引用指向用户存入的对象
- 这种设计让 ThreadLocal 对象本身可被 GC，但 value 若不手动清理，会滞留
Entry 的弱引用设计是双刃剑
key 设为弱引用，是为了防止 ThreadLocal 实例泄漏——比如定义成局部变量后被回收，但 map 还拿着强引用导致无法释放。
- 一旦 ThreadLocal 对象被回收，对应 Entry 的 key 变为
null - 但 value 仍被 Entry 强引用着，且该 Entry 在 table 中位置可能长期空悬
- ThreadLocalMap 的
get、set、remove方法中都内置了“探测并清理 key==null 的 stale entry”逻辑 - 但这个清理是被动的、不彻底的；线程长期运行又不调用这些方法时，value 就成了内存泄漏源
set/get/remove 的真实执行路径
以 get() 为例，源码流程直指本质：
- 拿到当前线程
t = Thread.currentThread() - 从
t.threadLocals取出ThreadLocalMap map - 用
this（即当前 ThreadLocal 实例）作为 key，在 map 中查找 Entry - 若没找到，触发
setInitialValue()：先调initialValue()，再创建 map 或 set 值 - 整个过程完全绕过 ThreadLocal 对象的实例字段，所有状态都在 Thread 内部
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
