ThreadLocal 源码解析get(),set(), remove()用不好容易内存泄漏

1.Java中内存泄漏

在 Java 中，内存泄漏是指程序在申请内存后，无法释放不再使用的内存空间。这意味着随着时间的推移，应用程序占用的内存会持续增长，最终可能导致OutOfMemoryError，使得应用程序崩溃。

内存泄漏通常发生在以下情况：

1. 对象引用：当一个对象不再需要，但仍然被引用，导致垃圾收集器无法回收它。
2. 静态变量：如果一个对象被静态变量引用，那么即使该对象不再被其他变量引用，垃圾收集器也无法回收它。
3. 线程：如果一个线程持有对象的引用，而该线程无法结束，那么该对象将无法被回收。
4. 集合：使用如 HashMap、HashSet 等集合时，如果不小心，可能会出现内存泄漏。例如，当从集合中删除元素时，如果只是简单地从集合中移除引用，而不是真正地删除元素，那么这些元素将无法被垃圾收集器回收。
5. 监听器和回调：如果注册了监听器或回调，但没有正确地取消注册，可能会导致内存泄漏。
6. 单例和缓存：如果缓存中的对象没有正确地过期或被清理，可能会导致大量的内存占用。
7. 代码问题：如无限递归、大数据量的循环等，也可能导致内存泄漏。

要避免内存泄漏，需要注意以下几点：

1. 及时释放资源：关闭流、数据库连接等资源。
2. 避免长时间持有对象引用：尤其是静态变量和全局变量。
3. 使用弱引用和软引用：如 WeakReference 和 SoftReference，它们可以用来引用对象，但不会阻止对象被垃圾收集器回收。
4. 监控和分析工具：使用如 VisualVM、JProfiler 等工具来监控和分析内存使用情况，以便及时发现和解决内存泄漏问题。

2.先上案例

public class UserEntity implements Serializable {
    private String id;
    private String name;
 
    public String getId() {
        return id;
    }
 
    public void setId(String id) {
        this.id = id;
    }
 
    public String getName() {
        return name;
    }
 
    public void setName(String name) {
        this.name = name;
    }
}

public class ThreadLocalTest {
    private static final ThreadLocal<UserEntity> THREAD_LOCAL = new ThreadLocal<UserEntity>();
 
    public static void set(UserEntity tokenInfo) {
        THREAD_LOCAL.set(tokenInfo);
    }
 
    public static UserEntity get(){
        return THREAD_LOCAL.get();
    }
 
    public static void remove(){
        THREAD_LOCAL.remove();
    }
}

3.Key 的泄漏

每一个 Thread 都有一个 ThreadLocal.ThreadLocalMap 这样的类型变量，该变量的名字叫作 threadLocals。线程在访问了 ThreadLocal 之后，都会在它的 ThreadLocalMap 里面的 Entry 中去维护该 ThreadLocal 变量与具体实例的映射

我们可能会在业务代码中执行了 ThreadLocal instance = null 操作，想清理掉这个 ThreadLocal 实例，但是假设我们在 ThreadLocalMap 的 Entry 中强引用了 ThreadLocal 实例，那么，虽然在业务代码中把 ThreadLocal 实例置为了 null，但是在 Thread 类中依然有这个引用链的存在

GC 在垃圾回收的时候会进行可达性分析，它会发现这个 ThreadLocal 对象依然是可达的，所以对于这个 ThreadLocal 对象不会进行垃圾回收，这样的话就造成了内存泄漏的情况

JDK 开发者考虑到了这一点，「所以 ThreadLocalMap 中的 Entry 继承了 WeakReference 弱引用」，代码如下所示

static class Entry extends WeakReference<ThreadLocal<?>> {
    /** The value associated with this ThreadLocal. */
    Object value;
 
    Entry(ThreadLocal<?> k, Object v) {
        super(k);
        value = v;
    }
}

这个 Entry 是 extends WeakReference。弱引用的特点是，「如果这个对象只被弱引用关联，而没有任何强引用关联，那么这个对象就可以被回收，所以弱引用不会阻止 GC。」因此，这个弱引用的机制就避免了 ThreadLocal 的内存泄露问题

4.Value 的泄漏

虽然 ThreadLocalMap 的每个 Entry 都是一个对 key 的弱引用，但是这个 Entry 包含了一个对 value 的强引用，还是刚才那段代码

static class Entry extends WeakReference<ThreadLocal<?>> {
    /** The value associated with this ThreadLocal. */
    Object value;
 
 
    Entry(ThreadLocal<?> k, Object v) {
        super(k);
        value = v;
    }
}

可以看到，value = v 这行代码就代表了强引用的发生

正常情况下，当线程终止，key 所对应的 value 是可以被正常垃圾回收的，因为没有任何强引用存在了。「但是有时线程的生命周期是很长的，如果线程迟迟不会终止」，那么可能 ThreadLocal 以及它所对应的 value 早就不再有用了。在这种情况下，我们应该保证它们都能够被正常的回收

为了更好地分析这个问题，我们用下面这张图来看一下具体的引用链路（实线代表强引用，虚线代表弱引用）

可以看到，左侧是引用栈，栈里面有一个 ThreadLocal 的引用和一个线程的引用，右侧是我们的堆，在堆中是对象的实例

重点看一下下面这条链路：Thread Ref → Current Thread → ThreadLocalMap → Entry → Value → 可能泄漏的value实例

这条链路是随着线程的存在而一直存在的，「如果线程执行耗时任务而不停止，那么当垃圾回收进行可达性分析的时候，这个 Value 就是可达的，所以不会被回收。」但是与此同时可能我们已经完成了业务逻辑处理，不再需要这个 Value 了，此时也就发生了内存泄漏问题

JDK 同样也考虑到了这个问题，在执行 ThreadLocal 的 set、remove、rehash 等方法时，它都会扫描 key 为 null 的 Entry，如果发现某个 Entry 的 key 为 null，则代表它所对应的 value 也没有作用了，所以它就会把对应的 value 置为 null，这样，value 对象就可以被正常回收了

但是假设 ThreadLocal 已经不被使用了，那么实际上 set、remove、rehash 方法也不会被调用，与此同时，如果这个线程又一直存活、不终止的话，那么刚才的那个调用链就一直存在，也就导致了 value 的内存泄漏

5.如何避免内存泄露

调用 ThreadLocal 的 remove 方法。调用这个方法就可以「删除对应的 value 对象，可以避免内存泄漏」

public void remove() {
    ThreadLocalMap m = getMap(Thread.currentThread());
    if (m != null)
        m.remove(this);
}

它是先获取到 ThreadLocalMap 这个引用的，并且调用了它的 remove 方法。这里的 remove 方法可以把 key 所对应的 value 给清理掉，这样一来，value 就可以被 GC 回收了，在使用完了 ThreadLocal 之后，我们应该「手动去调用它的 remove 方法，目的是防止内存泄漏的发生」