从 JDK1.2 到 JDK21：ThreadLocal的进化解决了什么问题

1. JDK 1.2：ThreadLocal 初版（最小可用）

核心特点：

ThreadLocal 首次出现。
每个线程维护自己的 ThreadLocalMap。
ThreadLocalMap 的 key 就是 ThreadLocal 本身。
底层使用开放地址法的哈希表（Entry[] table）。
key 不是弱引用，导致 ThreadLocal 对象不释放时可能造成内存泄漏。

主要问题：

ThreadLocal 实例如果被 GC 回收前未手动 remove()，线程（尤其是线程池）不会结束，Entry 永远存在，导致 value 泄漏。

这也是行业里常说的 ThreadLocal 泄漏最初来源。

2. JDK 1.3 ~ 1.4：Bug 修复 + 行为稳定

关键改动：

增强清理机制，但依然是 key 强引用。
修复部分扩容和冲突处理问题。

但根本性的泄漏问题仍然存在。

3. JDK 5：引入弱引用（关键里程碑）

这是 ThreadLocal 设计史上最重要的变更。

重大更新：

ThreadLocalMap.Entry 改为 弱引用：

scala 复制代码

static class Entry extends WeakReference<ThreadLocal<?>> {
    Object value;
}

一旦 ThreadLocal 对象不再被外部引用，可以被 GC 回收，Entry 的 key 会变成 null。

为什么改成弱引用？

防止 ThreadLocal 对象不释放导致整组 Entry 无法被清理。

带来的副作用：

value 仍然是强引用，只要线程活着，value 永远不会被回收。
如果你不手动 remove()，依旧可能内存泄漏（尤其线程池）。

至此，ThreadLocal 的内存泄漏问题变成了：

不是 key 泄漏，而是 value 泄漏。

4. JDK 6：清理机制增强 + TAB 数组 rehash 改善

JDK6 的重要演进：

加强对 key 为 null 的 Entry 的清理逻辑（例如访问冲突位点时主动清理）。
优化 rehash 和探测机制。

整体结构仍为开放地址法，不改变本质机制。

5. JDK 7：性能优化 + 部分线程局部缓存行为改进

JDK7 的变化偏向实现层。

增强点：

完善冲突探测，降低哈希冲突导致的退化。
改善 nextIndex/prevIndex 的性能。
修复扩容后 rehash 的一些 bug。

ThreadLocalMap 变得更健壮，但不改变语义。

6. JDK 8：清理策略进一步加强，核心逻辑成熟稳定

关键变化：

ThreadLocalMap 清理 stale entry（key = null）的策略更加激进：
- get/set/remove 时都会尝试清理死 key。
内部 rehash 策略更高效。
线程池场景下的内存泄漏仍然需要手动处理 (remove())，但 default 逻辑更健壮。

JDK8 的 ThreadLocal 基本成为行业主流参考实现。

7. JDK 9：新增 `ThreadLocal.withInitial()`（语法糖）

此版本以后属于稳定期，新增功能而非机制变化。

新增：

scss 复制代码

ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"))

机制不变，易用性提升。

8. JDK 11 / JDK 17：几乎无变化，属于稳定维护期

持续做小修复，增强可读性与边界处理。
内存清理策略与 JDK8 几乎无差别。
语义和行为已经非常稳定。

9. JDK 21：虚拟线程（Loom）下的 ThreadLocal 语义扩展（重要）

在 Loom（虚拟线程）中：

ThreadLocal 默认机制仍然可用，但成本更低：

虚拟线程是轻量结构，保留自己的 ThreadLocalMap。
虚拟线程不复用，生命周期短，因此不容易产生 ThreadLocal value 泄漏。

关键点：

虚拟线程不是池化线程，不会出现线程池泄漏问题。
某些场景 ThreadLocal 成本反而比传统线程更轻。

10. 前后机制的核心变化总结

JDK 版本	变化点	影响
1.2	基本实现	存在严重泄漏风险
1.3-1.4	Bug 修复	稳定性增强
5	key 改为弱引用	避免 key 泄漏，但 value 泄漏依旧
6	加强化清理逻辑	降低内存泄漏风险
7	进一步优化冲突处理	性能提升
8	成熟实现，清理更激进	标准实现，被行业普遍使用
9+	易用性提升（withInitial）	开发体验增强
21	虚拟线程支持稳定	泄漏风险显著降低

11. 哪些问题贯穿所有版本？

无论哪个版本，ThreadLocal 永远有两个核心风险：

value 会泄漏，只要线程还活着
线程池复用导致 value 长期驻留

这两个问题在 JDK21 的虚拟线程中弱化但未彻底消失。

12. 业内最佳实践

创建后必须手动 remove()
避免在容器/框架级别缓存业务值
避免使用无界线程池结合 ThreadLocal
不要把 ThreadLocal 当成上下文传递机制（应使用 ThreadLocal 设计的框架）
推荐使用 withInitial() 避免 null 值

13. 讲清楚本质

ThreadLocal 在整个 JDK 生命周期中的核心变化只有一次：JDK5 引入弱引用。

其余版本改动都是：

更激进的清理策略
更健壮的哈希探测与 rehash
更易用的 API
虚拟线程场景下的运行时表现改善

但行为本质没有改变：

每个线程维护一个 Map
key 弱引用
value 强引用
需要手动 remove，线程池中更应当如此