警惕！ThreadLocal 内存泄露的真相与最佳实践
在 Java 后端开发中，ThreadLocal 是我们处理用户上下文（UserContext）、数据库连接管理的神器。但面试官总爱问：“你知道 ThreadLocal 会导致内存泄露吗？为什么？”。
今天就来拆解一下这个经典的“八股文”背后的工程陷阱。
1. 为什么会内存泄露？
核心原因在于 ThreadLocalMap 的 Entry 设计。
ThreadLocal 在 Thread 内部维护了一个 Map，这个 Map 的 Key 是弱引用（WeakReference），而 Value 是强引用。
- Key (ThreadLocal): 弱引用。当外部没有强引用指向 ThreadLocal 对象时，GC 发生时 Key 会被回收，变成 null。
- Value: 强引用。只要当前线程（Thread）没有结束，这个引用链就会一直存在：Thread -> ThreadLocalMap -> Entry -> Value。
后果：如果线程是线程池里的（生命周期很长），Key 被回收了，但 Value 还在内存中，且无法被访问（因为 Key 没了），这就造成了内存泄露。
2. 正确的使用姿势
为了避免这种情况，JDK 官方建议在使用完后，必须手动调用 remove() 方法。
最佳实践是用 try-finally 块包裹业务逻辑：
public class UserContextHolder {
private static final ThreadLocal<User> userHolder = new ThreadLocal<>();
public static void set(User user) {
userHolder.set(user);
}
public static User get() {
return userHolder.get();
}
// 核心方法：清理资源
public static void remove() {
userHolder.remove();
}
}
// 在拦截器或过滤器中使用
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
try {
// 1. 设置上下文
User user = parseToken(request);
UserContextHolder.set(user);
// 2. 执行业务
chain.doFilter(request, response);
} finally {
// 3. 【必须】请求结束时清理，防止内存泄露和线程复用导致的数据串扰
UserContextHolder.remove();
}
}
3. 总结
- ThreadLocal 并不拥有数据，它只是线程取数据的“索引”。
- 内存泄露的根源是线程池线程复用 + Value强引用。
- 黄金法则：用完即删（remove），放在 finally 块里最安全。
