警惕！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 块里最安全。