1.核心拷问：ThreadLocal 到底把数据存哪了？
很多人误以为 ThreadLocal 内部维护了一个 Map，并将当前线程作为 Key。这其实是一个巨大的误解。
1.1 真正的底层归属
当我们执行 threadLocal.set(user) 时，这个 user 对象既不在 ThreadLocal 实例里，也不在堆空间的某个全局 Map 里，而是存放在当前线程（Thread 实例）的成员变量中。
-
Thread 类：每个线程对象内部都持有一个名为 threadLocals 的成员变量，其类型是 ThreadLocal.ThreadLocalMap。
-
ThreadLocalMap：这是一个 ThreadLocal 内部实现的定制化 Hash 表。
-
ThreadLocal 实例：它仅仅作为这个 Map 的 Key，用来索引和查找存入的数据。
1.2 源码级存取流程
让我们看一眼 ThreadLocal.set() 的核心源码：
public void set(T value) {
Thread t = Thread.currentThread(); // 1. 获取当前线程
ThreadLocalMap map = getMap(t); // 2. 拿到当前线程里的那个 Map
if (map != null) {
map.set(this, value); // 3. 以当前的 ThreadLocal 对象作为 Key
} else {
createMap(t, value); // 4. 首次调用则初始化
}
}
结论： ThreadLocal 只是一个入口代理。它像一把“钥匙”，帮你打开当前线程那把私人锁，把数据存进线程自己的柜子里。
2. 内存泄漏（Memory Leak）的致命诱因
在 Tomcat 或 Spring Boot 等企业级框架中，线程是池化（Thread Pool）管理的。如果使用 ThreadLocal 不当，极易发生内存泄漏。
2.1 弱引用（WeakReference）的“锅”？
ThreadLocalMap 的 Entry 定义如下：
static class Entry extends WeakReference<ThreadLocal<?>> {
Object value; // 强引用指向真正的数据
Entry(ThreadLocal<?> k, Object v) {
super(k); // Key 是弱引用
value = v;
}
}
-
Key 的生命周期：Key 是弱引用。如果 ThreadLocal 外部强引用被置为 null，下次 GC 时 Key 就会被回收。此时 Entry 里的 Key 变成了 null。
-
Value 的生命周期：Value 是强引用。只要线程（Thread）不销毁，这条 Entry 记录就会一直存在。由于 Key 已经是 null，你再也无法通过任何 ThreadLocal 访问到这个 Value，但它却占着内存不释放。
2.2 线程池的放大效应
在 Spring Boot 中，线程是复用的。
线程 A 处理完请求 1，ThreadLocal 里的 User 对象没有清理。
线程 A 回到池子。
线程 A 被复用来处理请求 2。 如果不手动清理，之前请求 1 的数据会一直堆积在线程 A 的 ThreadLocalMap 中。随着线程池中所有线程都被污染，内存就会缓慢耗尽。
3. 线上避坑：必须执行的“神圣操作”
为了彻底杜绝内存泄漏，在项目中必须遵循**“谁污染，谁治理”**的原则。
3.1 核心操作：remove()
每次使用完 ThreadLocal，必须显式调用 remove() 方法。该方法会清除 ThreadLocalMap 中对应的 Entry，从而断开 Value 的强引用，让 GC 能够回收内存。
3.2 最佳实践：结合 Spring 拦截器
在 Web 开发中，我们通常在 Interceptor 中统一管理 ThreadLocal。
public class UserInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
// 1. 模拟从 Token 解析用户信息并存入
User user = parseUser(request);
UserContextHolder.set(user);
return true;
}
@Override
public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
// 2. 【最关键的一步】请求结束后，务必清理，防止线程池污染和内存泄漏
UserContextHolder.remove();
}
}
为什么是 afterCompletion 而不是 postHandle？
因为 afterCompletion 保证了无论请求成功还是抛出异常，都会被执行。这类似于 try-finally 的保障机制。
4. 总结
存储位置：数据存在 Thread 对象的 ThreadLocalMap 成员变量里，Key 是 ThreadLocal 本身。
泄露根源：Entry 的 Key 是弱引用（易回收），但 Value 是强引用（难回收）。在线程池环境下，不手动清理会导致无效对象随线程生命周期永生。
避坑指南：必须在代码的 finally 块或拦截器的 afterCompletion 中调用 threadLocal.remove()。
