ThreadLocal的内存泄漏

内存泄漏：是指本应该被GC回收的无用对象没有被回收，导致内存空间的浪费，当内存泄露严重时会导致内存溢出。Java内存泄露的根本原因是：长生命周期的对象持有短生命周期对象的引用，尽管短生命周期对象已经不再需要，但是因为长生命周期对象持有它的引用而导致不能被GC回收。

内存溢出：就是我们常说的OOM（OutOfMemoryError）异常，简单理解就是内存不够了，通常发生在程序申请的内存超出了JVM中可用内存的大小，就会抛出OOM异常。在JVM内存区域中，除了程序计数器外其他的内存区域都有可能抛出OOM异常。

ThreadLocal很好地解决了线程之间需要数据隔离的问题，同时也引入了另一个问题，在应用程序中通常会使用线程池来管理线程，那么线程的生命周期与应用程序的生命周期基本保持一致，如果线程的数量很多，随着程序的运行，时间的推移，ThreadLocal类型的变量会越来越多，将会占用非常大的内存空间，从而产生内存泄漏，如果这些对象一直不被释放的话，可能会导致内存溢出。

ThreadLocal的OOM演示

下面的代码中开启了十个线程，每个线程申请10M的内存，而给堆只分配了100M，这样到后面的线程申请内存时就会抛出OOM异常。

package com.morris.jvm.threadlocal;

import java.util.concurrent.*;

/**
 * 演示ThreadLocal的内存泄漏问题
 * VM args: -Xmx100m -Xms100m -XX:+PrintGC
 */
public class ThreadLocalOom {

    public static void main(String[] args) throws BrokenBarrierException, InterruptedException {
        ThreadLocal<byte[]> threadLocal = new ThreadLocal<>();

        CyclicBarrier cyclicBarrier = new CyclicBarrier(12);

        for (int i = 0; i < 10; i++) {
            new Thread(()->{
                threadLocal.set(new byte[1024 * 1024 * 10]); // java.lang.OutOfMemoryError: Java heap space
                // threadLocal.remove();
                try {
                    cyclicBarrier.await();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } catch (BrokenBarrierException e) {
                    e.printStackTrace();
                }
            }).start();
        }

        cyclicBarrier.await(); // 保证main线程不退出
    }

}

源码分析

下面从源码中分析ThreadLocal应该怎么防止内存泄漏？

    static class ThreadLocalMap {

        static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;

            Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
            }
        }

从上面的源码中可以看出ThreadLocalMap内部的这个Entity的key是弱引用。

下面用一张图来说明堆和栈中各个对象之间的引用关系：

在这里插入图片描述
随着程序的运行，栈中ThreadLocal的强引用也会消亡，由于ThreadLocalMap.Entity中的key是弱引用，所以堆中的ThreadLocal对象会被回收（只要发生GC，弱引用对象就会被回收）。

而对于线程来说，线程的生命周期与应用程序的生命周期基本保持一致，所以一直会存在：Current Thread Refefence -> Thread -> ThreaLocalMap -> Entry -> value -> Object的强引用，这样value所强引用的Object对象迟迟得不到回收，就会导致内存泄漏。

此时堆和栈中各个对象之间的引用关系变成如下图：

在这里插入图片描述

怎么解决内存泄漏

ThreadLocalMap的设计中已经考虑到这种情况，所以ThreadLocal的get()、set()、remove()的时候都会清除线程ThreadLocalMap里所有key为null的value。

以get方法为例：

java.lang.ThreadLocal.ThreadLocalMap#getEntry

        private Entry getEntry(ThreadLocal<?> key) {
            int i = key.threadLocalHashCode & (table.length - 1);
            Entry e = table[i];
            if (e != null && e.get() == key)
                return e;
            else
                return getEntryAfterMiss(key, i, e);
        }

        private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
            Entry[] tab = table;
            int len = tab.length;

            while (e != null) {
                ThreadLocal<?> k = e.get();
                if (k == key)
                    return e;
                if (k == null)
                    expungeStaleEntry(i); // 删除过期的Entry
                else
                    i = nextIndex(i, len);
                e = tab[i];
            }
            return null;
        }

        private int expungeStaleEntry(int staleSlot) {
            Entry[] tab = table;
            int len = tab.length;

            // expunge entry at staleSlot
            tab[staleSlot].value = null;
            tab[staleSlot] = null;
            size--;

            // Rehash until we encounter null
            Entry e;
            int i;
            for (i = nextIndex(staleSlot, len);
                 (e = tab[i]) != null;
                 i = nextIndex(i, len)) {
                ThreadLocal<?> k = e.get();
                if (k == null) {
                    e.value = null; // 将value设置为null
                    tab[i] = null;
                    size--;
                } else {
                    int h = k.threadLocalHashCode & (len - 1);
                    if (h != i) {
                        tab[i] = null;

                        // Unlike Knuth 6.4 Algorithm R, we must scan until
                        // null because multiple entries could have been stale.
                        while (tab[h] != null)
                            h = nextIndex(h, len);
                        tab[h] = e;
                    }
                }
            }
            return i;
        }

一旦将value设置为null之后，就斩断了引用与真实内存之间的强引用，就能够真正的释放空间，防止内存泄漏。

但是这只是一种被动的方式，如果这些方法都没有被调用怎么办？那你就每次使用完ThreadLocal变量之后，执行remove方法。

总结：ThreadLocalMap中的弱引用以及调用ThreadLocal各种方法后的清理只是增加了一层防护手段，还是有可能会导致内存泄露，真正想防止内存泄漏，需要编码的规范，使用完ThreadLocal后，及时调用remove()方法释放内存空间。

更多精彩内容关注本人公众号：架构师升级之路
在这里插入图片描述