ThreadLocal本质是线程本地变量的访问代理，通过每个Thread内部的threadLocals（ThreadLocalMap）实现隔离：key为弱引用的ThreadLocal实例，value为强引用的线程私有数据；需显式remove避免线程池场景内存泄漏。
ThreadLocal 的本质不是“存数据的容器”，而是线程本地变量的访问代理。它的演进主线始终围绕一个目标：更安全、更轻量、更可控地实现线程封闭。从 JDK 1.2 初版的简单封装，到 Java 24 的底层哈希优化与 GC 协同，核心逻辑没变——每个线程持有一份独立副本；但实现细节持续收敛风险、提升效率。
ThreadLocal 是怎么做到线程隔离的？
关键不在 ThreadLocal 类本身，而在每个 Thread 对象内部的 threadLocals 字段，它是一个 ThreadLocalMap 类型的哈希表：
- 键（key）是 ThreadLocal 实例，且为弱引用——避免因 ThreadLocal 被回收后 Entry 仍滞留导致内存泄漏
- 值（value）是线程私有数据，为强引用——只要线程存活且未 remove，数据就一直存在
- ThreadLocal.get() / set() 实际是委托给当前线程的 ThreadLocalMap 进行查找或插入
哪些场景真正适合用 ThreadLocal？
适用前提是：数据天然属于单一线程生命周期，且多个线程之间不需要共享、也不应共享。典型用例包括：
- 非线程安全对象的复用：如 SimpleDateFormat、DecimalFormat、Jackson ObjectMapper —— 避免每次 new，又不担心并发问题
- 请求上下文透传：Web 场景中存储用户身份、租户 ID、链路追踪 traceId，在 Filter → Service → DAO 全链路隐式获取
- 事务/连接绑定：确保同一请求内所有 DAO 操作复用同一个数据库连接或事务状态（Spring TransactionSynchronizationManager 底层即基于此）
- 线程级缓存：如解析后的配置、权限规则等，仅本线程反复使用，无需全局同步
为什么用了 ThreadLocal 还会内存泄漏？
根本原因不是 ThreadLocal 本身，而是线程长期存活 + value 未清理。尤其在使用线程池时：
立即学习“Java免费学习笔记（深入）”；
- 线程池中的线程被复用，threadLocals Map 不会自动清空
- 若只 set 不 remove，value 强引用持续持有大对象（如 User、Map、InputStream），就会堆积
- 虽然 key 是弱引用，GC 后 Entry 可能变成 key=null 的“脏项”，但 value 仍驻留，直到 ThreadLocalMap 的 nextEntry 或 resize 时才被动清理
所以必须显式调用 remove()，推荐模式是：
try {
contextHolder.set(value);
// 执行业务
} finally {
contextHolder.remove(); // 关键！不能省略
}
Java 24 带来了哪些实质性改进？
不是新增 API，而是对底层 ThreadLocalMap 的深度优化：
- 哈希冲突处理更高效：改用动态负载因子 + 改进的开放寻址策略，减少探测步数，写操作延迟下降约 25%
- GC 友好性增强：线程结束前主动扫描并清理失效 Entry，降低 Full GC 触发频率
- 内存占用压缩：千线程规模下 threadLocals 内存开销从 48MB 降至 36MB，对微服务高密度部署更友好
这些优化对开发者透明，但要求你继续坚持最佳实践——否则再快的底层也救不了误用。
