Java弱引用学习 WeakHashMap、ReferenceQueue

上一篇文章 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 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 extends WeakReference implements Map.Entry {
        V value;
        final int hash;
        Entry next;

        /**
         * Creates new entry.
         */
        Entry(Object key, V value,
              ReferenceQueue queue,
              int hash, Entry 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 e = (Entry) x;   // e -> Entry1
                int i = indexFor(e.hash, table.length);  // 找到index,假设就是0

                Entry prev = table[i];             //  index0上目前存放的第一个entry,可能是Entry1也可能不是,因为Entry1可能存放在链表的下一个节点,我们这个图例中Entry1就是第一个
                Entry p = prev;                    //   prev-> index0    p -> index0
                while (p != null) {               //    如果index0 存放的是空,那说明被回收掉的那个Entry1肯定不在这里,不做清理操作
                    Entry 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的思路来预防内存泄露。

你可能感兴趣的:(Java弱引用学习 WeakHashMap、ReferenceQueue)