ThreadLocal 是线程私有变量的隔离舱，为每个线程自动分配独立实例，避免锁竞争和手动传参；典型场景包括请求上下文传递、非线程安全对象复用、线程池中独立状态管理及框架上下文透传；不及时 remove 会导致 key 为 null 的“幽灵 value”堆积引发内存泄漏；withInitial() 存在初始化异常重试风险，推荐显式控制初始化逻辑。
ThreadLocal 是线程私有变量的“隔离舱”
它不共享、不传递、不竞争——每个线程拿到的 get() 值，都是自己独一份的副本。本质不是“存一个变量”，而是“为每个线程自动配一个独立变量实例”。这直接绕开了 synchronized 和锁竞争，也比手动传参干净得多。
哪些场景非用不可？看这几个典型信号
当你发现以下任意一种情况，ThreadLocal 很可能就是最轻量又可靠的解法：
- 需要在一次请求/事务中贯穿使用某个对象（比如
User、Connection、TransactionId），但又不想把它塞进每个方法参数里 - 正在用非线程安全的类（如
SimpleDateFormat、DecimalFormat），而创建新实例开销大或不方便 - 在线程池环境下复用线程，但每次任务需要各自独立的状态（比如日志
requestId、灰度标识onlineFlag） - 框架层要透传上下文（Spring 的
RequestContextHolder、MyBatis 的SqlSession管理底层都依赖它）
为什么 set 之后不 remove 就容易内存泄漏？
关键不在 value，而在 ThreadLocal 自身作为 key 的引用方式：它被设计成弱引用（WeakReference），一旦外部不再强引用这个 ThreadLocal 实例，GC 就能回收它——但此时 ThreadLocalMap 中对应的 Entry 还在，key 变成 null，value 却还牢牢挂着。
如果线程长期存活（比如 Tomcat 的工作线程、自定义线程池），这些“幽灵 value”就堆积成内存泄漏。所以必须养成习惯：
立即学习“Java免费学习笔记（深入）”；
- 用完立刻调用
remove()，尤其在finally块里 - 别只依赖
set(null)——那只是把 value 设为空，Entry 还在 - Web 场景下，在 Filter 或 Interceptor 的
doFilter()结尾统一remove()
withInitial() 比 new ThreadLocal() 更安全，但也有坑
ThreadLocal.withInitial(() -> new Xxx()) 看似简洁，但它返回的是一个匿名内部类实例，每次 get() 都会触发初始化逻辑——如果初始化过程抛异常（比如数据库连接失败），get() 就会反复重试并持续报错。
更稳妥的做法是显式控制初始化时机：
private static final ThreadLocalconnHolder = new ThreadLocal<>(); public static Connection getConnection() { Connection conn = connHolder.get(); if (conn == null) { conn = createNewConnection(); // 可捕获异常、可重试、可降级 connHolder.set(conn); } return conn; }
复杂逻辑别压进 lambda；线程生命周期越长，越要掌控初始化的确定性。
真正难的不是写对 set 和 get，而是想清楚：这个值该不该由当前线程“拥有”，以及它生命周期是否和线程对齐。很多泄漏和错乱，都始于没问这一句。
