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()方法释放内存空间。
更多精彩内容关注本人公众号：架构师升级之路
