ThreadLocal内存溢出(OOM)的原因

ThreadLocal是Java提供的一个线程安全类,其原理是每个线程都拥有各自的变量内存副本。其实就是每个线程Thread里都有一个ThreadLocalMap类,用于存储变量值。更新、删除操作时,都是操作各自线程里的hreadLocalMap类,互不影响,从而达到的线程安全

ThreadLocal经常用于一次调用的上下文储存场景,例如一次调用的token、traceId,在调用的各个阶段都有可能用到,但是每次调用的值都不一样,这时ThreadLocal就派上用场了

但是如果ThreadLocal使用不当,会引发内存溢出,其实ThreadLocal的作者Josh Bloch在写ThreadLocal的时候,意识到了这点,例如弱引用等,但是依然会有内存溢出的可能,下面我们来分析一下原因

看源码ThreadLocal底层都是用的Thread里的ThreadLocalMap类,其实ThreadLocal就是一个工具类而已,底层都是操作的Thread里的ThreadLocalMap类。

ThreadLocal内存溢出(OOM)的原因_第1张图片

 

再看看ThreadLocalMap的源码ThreadLocal内存溢出(OOM)的原因_第2张图片

 

当我们使用ThreadLocal.set()时,set的value与key(即业务自己定义的ThreadLocal类)会存储在ThreadLocalMap的Entry[]数组里

其中Entry是实现了一个弱引用WeakReference,Entry的key(即业务方定义的 ThreadLocal类)会被包装成一个弱引用当成Entry的key。Java的弱引用的定义是,当JVM执行垃圾回收扫描的时候,当发现只有弱引用的对象时,会立即回收此对象,这是ThreadLocal当初设计的时候防止内存溢出的一个手段

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

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

虽然key被包装成了一个弱引用会被垃圾回收机制给回收,但是value在线程(Thread)不死亡时却可能存在一条强引用链.

由于value是强引用,只要Thread不死亡时,例如线程池,这条强引用链就会存在,那么value就不会回收,可能造成内存溢出

ThreadLocal内存溢出(OOM)的原因_第3张图片

虽然ThreadLocal的作者想到了这点,也做了些优化,例如在get的时候当发现key是null的时候,会遍历一次整个Entry数组,remove掉key为null的entry,把value指向null,消除这条强引用链。源码方法为expungeStaleEntry

        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;
                    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;
        }

 

但是这个消除强引用链的动作是需要业务方在get的情况下触发的,可能业务方并不会get、也可能get是key不为空,并不会触发expungeStaleEntry类。所以开发者要养成良好的习惯,记得用完ThreadLocal时,调一次ThreadLocal.remove()方法或者ThreadLocal.set(null)

 

 

你可能感兴趣的:(ThreadLocal,内存溢出,高并发)