译《Understanding Weak References》

本文主要是介绍译《Understanding Weak References》，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

Understanding Weak References

以前我招聘过高级java工程师，其中一个面试题目是“你对weak reference了解多少？”。这个话题比较偏，不指望每个人都能清楚它的细节。如果面试的人说“Umm...好像和gc（垃圾回收）有点关系？”，那我就相当满意了。实际情况却是20多个5年java开发经验的工程师只有2个知道有weak reference这么回事，其中1个是真正清楚的。我试图给他们一些提示，期望有人会恍然大悟，可惜没有。不知道为什么这个特性uncommon，确切地说，是相当uncommon，要知道这是在java1.2中推出的，那是7年前的事了。

没必要成为weak reference专家，装成资深java工程师（就像茴香豆的茴字有四种写法）。但是至少要了解一点点，知道是怎么回事。下面告诉你什么是weak references，怎么用及何时用它们。

l Strong references
从强引用(Strong references)开始。你每天用的就是strong reference，比如下面的代码：StringBuffer buffer = new StringBuffer()；创建了一个StringBuffer对象，变量buffer保存对它的引用。这太小儿科了！是的，请保持点耐心。Strong reference，是什么使它们‘strong’？——是gc处理它们的方式：如果一个对象通过一串强引用链可达，那么它们不会被垃圾回收。你总不会喜欢gc把你正在用的对象回收掉吧。

l         When strong references are too strong
       我们有时候用到一些不能修改也不能扩展的类，比如final class，再比如，通过Factory创建的对象，只有接口，连是什么实现都不知道。想象一下，你正在用widget类，需要知道每个实例的扩展信息，比如它是第几个被创建的widget实例（即序列号），假设条件不允许在类中添加方法，widget类自己也没有这样的序列号，你准备怎么办？用HashMap！serialNumberMap.put(widget, widgetSerialNumber)，用变量记录新实例的序列号，创建实例时把实例和它的序列号放到HashMap中。很显然，这个Map会不断变大，从而造成内存泄漏。你要说，不要紧，在不用某个实例时就从map中删除它。是的，这可行，但是“put——remove”，你不觉得你在做与内存管理“new——delete”类似的事吗？像所有自己管理内存的语言一样，你不能有遗漏。这不是java风格。
       另一个很普遍的问题是缓存，特别是很耗内存的那种，比如图片缓存。想象一下，有个项目要管理用户自己提供的图片，比如像我正在做的网站编辑器。自然地你会把这些图片缓存起来，因为每次从磁盘读取会很耗时，而且可以避免在内存中一张图片出现多份。你应该能够很快地意识到这有内存危机：由于图片占用的内存没法被回收，内存迟早要用完。把一部分图片从缓存中删除放到磁盘上去！——这涉及到什么时候删除、哪些图片要删除的问题。和widget类一样，不是吗，你在做内存管理的工作。

l         Weak reference
    Weak reference，简单地说就是这个引用不会强到迫使对象必须保持在内存中。Gc不会碰Strong reference可达的对象，但可以碰weak reference可达的对象。下面创建一个weak reference：WeakReference weakWidget = new WeakReference(widget)，使用weakWidget.get()来取到widget对象。注意，get()可能返回null。什么？null？什么时候变成null了？——当内存不足垃圾回收器把widget回收了时（如果是Strong reference，这是不可能发生的）。你会问，变成null之后要想再得到widget怎么办？答案是没有办法，你得重新创建widget对象，对cache系统这很容易做到，比如图片缓存，从磁盘载入图片即可（内存中的每份图片要在磁盘上保存一份）。
       像上面的“widget序列号”问题，最简单的是用jdk内含的WeakHashMap类。WeakHashMap和HashMap的工作方式类似，不过它的keys（注意不是values）都是weak reference。如果WeakHashMap中的一个key被垃圾回收了，那么这个entry会被自动删除。如果使用的是Map接口，那么实例化时只需把HashMap改成WeakHashMap，其它代码都不用变，就这么简单。

l Reference queque
一旦WeakReference.get()返回null，它指向的对象被垃圾回收，WeakReference对象就一点用都没有了，如果要对这些没有的WeakReference做些清理工作怎么办？比如在WeakHashMap中要把回收过的key从Map中删除掉。jdk中的ReferenceQueue类使你可以很容易地跟踪dead references。WeakReference类的构造函数有一个ReferenceQueue参数，当指向的对象被垃圾回收时，会把WeakReference对象放到ReferenceQueue中。这样，遍历ReferenceQueue可以得到所有回收过的WeakReference。WeakHashMap的做法是在每次调用size()、get()等操作时都先遍历ReferenceQueue，处理那些回收过的key，见jdk的源码WeakHashMap# expungeStaleEntries()。

l Different degrees of weakness
上面我们仅仅提到“weak reference”，实际上根据弱的层度不同有四种引用：强（strong）、软（soft）、弱（weak）、虚（phantom）。我们已经讨论过strong和weak，下面看下soft和phantom。

n Soft reference
Soft reference和weak reference的区别是：一旦gc发现对象是weak reference可达就会把它放到ReferenceQueue中，然后等下次gc时回收它；当对象是Soft reference可达时，gc可能会向操作系统申请更多内存，而不是直接回收它，当实在没辙了才回收它。像cache系统，最适合用Soft reference。

n         Phantom reference
      虚引用Phantom reference与Soft reference和WeakReference的使用有很大的不同：它的get()方法总是返回null（不信可以看jdk的PhantomReference源码）。这意味着你只能用PhantomReference本身，而得不到它指向的对象。它的唯一用处是你能够在ReferenceQueue中知道它被回收了。为何要有这种“不同”？
       何时进入ReferenceQueue产生了这种“不同”。WeakReference是在它指向的对象变得弱可达(weakly reachable）时立即被放到ReferenceQueue中，这在finalization、garbage collection之前发生。理论上，你可以在finalize()方法中使对象“复活”（使一个强引用指向它就行了，gc不会回收它），但WeakReference已经死了（死了？不太明白作者的确切意思。在finalize中复活对象不太能够说明问题。理论上你可以复活ReferenceQueue中的WeakReference指向的对象，但没法复活PhantomReference指向的对象，我想这才是它们的“不同”）。而PhantomReference不同，它是在garbage collection之后被放到ReferenceQueue中的，没法复活。
       PhantomReferences的价值在哪里？我只说两点：1、你能知道一个对象已经从内存中删除掉了，事实上，这是唯一的途径。这可能不是很有用，只能用在某些特别的场景中，比如维护巨大的图片：只有图片对象被回收之后才有必要再载入，这在很大程度上可以避免OutOfMemoryError。2、可以避免finalize()方法的缺点。在finalize方法中可以通过新建强引用来使对象复活。你可能要说，那又怎么样？——finalize的问题是对那些重载了finalize方法的对象垃圾回收器必须判断两遍才能决定回收它。第一遍，判断对象是否可达，如果不可达，看是否有finalization，如果有则调用，否则回收；第二遍判断对象是否可达，如果不可达，则回收。由于finalize是在内存回收之前调用的，那么在finalize中可能出现OutOfMemoryError，即使很多对象可以被回收。用PhantomReference就不会出现这种情况，当PhantomReference进入ReferenceQueue之后就没法再获得所指向的对象（它已经从内存中删除了）。由于PhantomReference不能使对象复活，所以它指向的对象可以在第一遍时回收，有finalize方法的对象就不行。可以证明，finalize方法不是首选。PhantomReference更安全更有效，可以简化VM的工作。虽然好处多，但要写的代码也多。所以我坦白承认，大部分情况我还是用finalize。不管怎么样，你多了个选择，不用在finalize这棵树上吊死。