上一篇文章 Java内存泄露学习 ThreadLocal真的会内存泄露吗 提到ThreadLocal内存泄露的问题。我们也知道导致内存泄露的一个关键点就是ThreadLocalMap.Entry的key是弱引用，如果gc回收key以后，value无法被访问也没有回收就会内存泄露。
那么jdk里面除了ThreadLocal还有其他地方有使用弱引用的吗？它们是怎么解决内存泄露呢？除了ThreadLocal的手动remove，还有没有其他好的办法？
其实还有一个常见的类WeakHashMap，从名字上就可以看出它是HashMap的一个变种，翻阅源码可以看见核心实现就是Entry使用了弱引用，并且配合了ReferenceQueue来很好地解决内存泄露的问题。
关于Java的四种引用的区别这里不做讨论，针对弱引用等相关的ReferenceQueue我们来了解一下。
在WeakReference类的构造方法中我们看到，可以传入一个ReferenceQueue。它的作用是当弱引用指向的referent被回收以后，这个弱引用会被添加到queue里面。
如果我们读取这个queue，就可以做跟这个referent相关联的对象的回收工作。这么说可能不太好理解，我们用jdk自带的WeakHashMap来学习一下。
/**
* Reference queue for cleared WeakEntries
*/
private final ReferenceQueue<Object> queue = new ReferenceQueue<>();
// 上面定义了一个queue，然后在下面Map的Entry里面继承了WeakReference并调用父类构造方法传入queue，
// 所以当key被回收的时候，Entry这个reference对象就会被添加到queue里面，读取这个队列就可以做清理工作
// 这是WeakHashMap的内部类，实现了同HashMap.Entry类似的功能（hashmap1.8以后优化采用了红黑树，跟1.8之前的hashmap类似），
// 区别就是继承了WeakReference使得内存不足的时候条目可以被回收
private static class Entry<K,V> extends WeakReference<Object> implements Map.Entry<K,V> {
V value;
final int hash;
Entry<K,V> next;
/**
* Creates new entry.
*/
Entry(Object key, V value,
ReferenceQueue<Object> queue,
int hash, Entry<K,V> next) {
super(key, queue);
this.value = value;
this.hash = hash;
this.next = next;
}
我们简单图解一下WeakHashMap的结构，Table[]数组+Entry链表的实现。由于Entry的key是弱引用，当Entry1的key被gc回收以后，其实这个Entry已经没有存在的意义了，但是还是占着一个size，value也会造成内存泄露。
WeakHashMap.png
那么怎么样才能回收掉这个Entry呢，WeakHashMap有一个核心方法expungeStaleEntries()，我们用Entry1 Entry2来代入，看看这段代码的逻辑
/**
* Expunges stale entries from the table.
*/
private void expungeStaleEntries() {
for (Object x; (x = queue.poll()) != null; ) { // 假设Entry1的key被gc 那么Entry1就会被放入queue，这里x返回Entry1 即需要被清理的entry
synchronized (queue) { // 同步操作 保证线程安全
@SuppressWarnings("unchecked")
Entry<K,V> e = (Entry<K,V>) x; // e -> Entry1
int i = indexFor(e.hash, table.length); // 找到index，假设就是0
Entry<K,V> prev = table[i]; // index0上目前存放的第一个entry，可能是Entry1也可能不是，因为Entry1可能存放在链表的下一个节点，我们这个图例中Entry1就是第一个
Entry<K,V> p = prev; // prev-> index0 p -> index0
while (p != null) { // 如果index0 存放的是空，那说明被回收掉的那个Entry1肯定不在这里，不做清理操作
Entry<K,V> next = p.next; // 找到next 是Entry2
if (p == e) { // 如果被回收的Entry1 就是index0的第一个entry，那么进入分支逻辑进行回收操作
if (prev == e) // index0位置上的table[0] 直接指向 next，即Entry2
table[i] = next;
else
prev.next = next;
// Must not null out e.next;
// stale entries may be in use by a HashIterator
e.value = null; // Help GC value引用释放掉帮助gc回收
size--; // Entry被回收了一个，size要减1
break; // 做完这个entry的清理操作，继续poll()进行下一轮操作
}
prev = p; // 如果被回收的Entry1不是index0的第一个entry，那么继续next往下找
p = next;
}
}
}
}
那么这个expungeStaleEntries方法是在何时被调用的呢，从调用层级图中我们看到get(),put(),remove()等方法都有被调用到，也就是说在正常使用api的时候就会默认做entry的清理工作，防止内存泄露。
image.png
看到这里，也许会想，既然有天然的ReferenceQueue支持，那么ThreadLocal为啥不采用这种方法来解决内存泄露呢？具体原因就不知道了，个人看法是可以采用ReferenceQueue的，或许ThreadLocalMap的结构比较简单，且ThreadLocal官方推荐的就是static用法，并提供了相应的remove()方法来清理内存，也是一种解决思路。
总结
- ThreadLocal依靠半自动的无效entry清理+remove方法解决内存泄露。
- WeakHashMap依靠jdk提供的ReferenceQueue来清理无效entry解决内存泄露。
- ThreadLocal能否使用WeakHashMap的思路呢？个人认为可以，不过jdk的实现差别我们不去揣摩。
- 如果平时业务代码中有需要使用到弱引用软引用等，可以参考WeakHashMap的思路来预防内存泄露。
网友评论