ThreadLocal的内存泄漏与解决

缺乏、安全感 2023-03-01 05:53 3阅读 0赞

# 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是弱引用。

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

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

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

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMjI4MTI4NDk_size_16_color_FFFFFF_t_70 1]

## 怎么解决内存泄漏 ##

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()方法释放内存空间。

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMjI4MTI4NDk_size_16_color_FFFFFF_t_70]: /images/20230209/99d31b73d8ae445b8447a9e1f2b7403d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMjI4MTI4NDk_size_16_color_FFFFFF_t_70 1]: /images/20230209/e772f4ccd61d4dbcb632e83fd1cb8a40.png
[20200627175030665.jpg]: /images/20230209/cb084fbed320411dbd9fb583e9c72fc8.png