ThreadLocal内存泄漏源于Entry的key弱引用与value强引用不对称设计，哈希冲突则通过线性探测解决；二者交织导致stale entry滞留，线程池中因线程复用加剧泄漏风险。
ThreadLocal 的内存泄漏和哈希冲突，不是两个孤立问题，而是源码中紧密交织的设计后果。关键得从 ThreadLocalMap 的结构、Entry 的引用类型、以及 set/get 的探测逻辑三者联动来看。
哈希冲突在 ThreadLocalMap 中怎么解决
ThreadLocalMap 用的是开放地址法中的线性探测（而非 HashMap 的链地址法）。数组索引由 key.threadLocalHashCode & (len - 1) 计算得出，但数组长度有限，多个 ThreadLocal 实例可能算出相同索引。
- 遇到冲突时，代码会从该索引开始，依次向后查找下一个空槽（
nextIndex(i, len)） - 如果途中遇到 key 相同的 Entry，就直接覆盖 value；遇到 key == null 的 stale Entry，则触发
replaceStaleEntry - 最终新 Entry 插入第一个空位，形成“连续探测段”，这本身不导致泄漏，但为后续清理埋下伏笔
内存泄漏的根本原因在 Entry 的引用设计
Entry 继承自 WeakReference<ThreadLocal<?>>，key 是弱引用，value 是强引用 —— 这个不对称设计是泄漏的源头。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 当外部 ThreadLocal 变量被置为 null 或超出作用域，GC 会回收它，Entry.key 变成 null，但 Entry 对象本身仍留在数组里
- 此时 value 仍被 Entry 强引用着，而因 key == null，常规 get/set 无法定位到它，也就不会主动清理
- 只要线程持续运行（如线程池中的工作线程），这些“stale entry”就一直占着堆内存
Java 怎么尝试缓解泄漏：被动清理机制
ThreadLocal 并没有完全杜绝泄漏，而是靠 set/get 过程中顺带做清理，属于“懒清理”策略。
-
set()中若发现 stale Entry，会调用replaceStaleEntry()：把新值塞进去，同时向前/向后扫描，批量清除沿途 key == null 的 Entry -
get()和remove()也会触发expungeStaleEntries()，清理当前探测路径上的过期项 - 但这些清理都依赖“有操作才触发”，线程空闲或只 get 不 set 时，stale entry 就可能长期滞留
为什么线程池环境下泄漏更危险
普通线程执行完就销毁，threadLocals 随之回收；线程池里的线程却被反复复用，生命周期远超业务请求。
- 一次请求中 set 了用户信息，但忘了 remove，下次复用该线程时，旧 value 仍在 map 里
- 大量请求积累后，stale entry 越来越多，value 对象（比如大对象、连接、上下文）无法释放
- 最终表现为老年代缓慢增长、Full GC 频繁，甚至 OOM
不复杂但容易忽略：泄漏不是因为用了 ThreadLocal，而是没配对使用 remove()，尤其在线程复用场景下。
