理解Java的弱引用

Java四种引用

Java提供了四种引用， 这些引用的目的是配合JVM的GC，实现更加便利的内存管理。

• Strong Reference，是最常见的引用，一般场景下都会使用强引用。如果一个对象具有强引用，那就类似于必不可少的生活用品，垃圾回收器绝不会回收它。当内存空 间不足，Java 虚拟机宁愿抛出 OutOfMemoryError 错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足问题。
• Weak Reference，这个引用的“强度”其实是在 Soft Reference之下的，但是其还是较为常用的。其行为就是在GC后失效，所谓失效是 weakReference.get() return null。WeakReference类的一个典型用途就是规范化映射（canonicalized mapping）。另外，对于那些生存期相对较长而且重新创建的开销也不高的对象来说，弱引用也比较有用。关键之处在于，垃圾收集器运行时如果碰到了弱可及对象，将释放WeakReference引用的对象。然而，请注意，垃圾收集器可能要运行多次才能找到并释放弱可及对象。这里关键是要理解弱可及，请看下面一个例子。

 String content = new String("weak");
        WeakReference weakReference = new WeakReference(content);
        content = null; // 语句1
        System.gc();  // 语句2
        System.out.println(weakReference.get());

假如没有语句1，只有语句2，那么content 所引用的对象仍然是强可及，那么随后的 weakReference.get()返回的对象不为null。仅有语句1，而没有语句2，即假使weakReference.get()之前没有经过gc，那么即使此时content所引用的对象已经是弱可即，但是仍然是可以访问，可以这么理解，弱可及的对象不经过GC处理就可以被访问到。

• Soft Reference : Soft Reference 类的一个典型用途就是用于内存敏感的高速缓存。 Soft Reference 的原理是：在保持对对象的引用时保证在 JVM 报告内存不足情况之前将清除所有的软引用。关键之处在于，垃圾收集器在运行时可能会（也可能不会）释放软可及对象。对象是否被释放取决于垃圾收集器的算法 以及垃圾收集器运行时可用的内存数量。
• Phantom Reference : Phantom Reference 类只能用于跟踪对被引用对象即将进行的收集。同样，它还能用于执行 pre-mortem 清除操作。 Phantom Reference 必须与 ReferenceQueue 类一起使用。需要 ReferenceQueue 是因为它能够充当通知机制。当垃圾收集器确定了某个对象是虚可及对象时， Phantom Reference 对象就被放在它的 ReferenceQueue 上。将 Phantom Reference 对象放在 ReferenceQueue 上也就是一个通知，表明 PhantomReference 对象引用的对象已经结束，可供收集了。这使您能够刚好在对象占用的内存被回收之前采取行动。 Reference与 ReferenceQueue 的配合使用。

GC, Reference 与 ReferenceQueue 的交互

• GC无法删除存在强引用的对象的内存。
• GC发现一个只有软引用的对象内存，那么：
  
  • SoftReference对象的 referent 域被设置为 null ，从而使该对象不再引用heap
  • SoftReference引用过的 heap 对象被声明为 finalizable 。
  • 当 heap 对象的 finalize() 方法被运行而且该对象占用的内存被释放， SoftReference 对象就被添加到它的 ReferenceQueue （如果后者存在的话）。
• GC发现一个只有弱引用的对象内存，那么：
  
  • WeakReference对象的 referent 域被设置为 null , 从而使该对象不再引用heap 对象。
  • WeakReference引用过的 heap 对象被声明为 finalizable
  • 当heap 对象的 finalize() 方法被运行而且该对象占用的内存被释放时， WeakReference 对象就被添加到它的 ReferenceQueue （如果后者存在的话）。
• GC发现一个只有虚引用的对象内存，那么：
  
  • PhantomReference引用过的 heap 对象被声明为 finalizable 。
  • PhantomReference在堆对象被释放之前就被添加到它的 ReferenceQueue 。

值得注意的地方有以下几点：

• GC 在一般情况下不会发现软引用的内存对象，只有在内存明显不足的时候才会发现并释放软引用对象的内存。
• GC 对弱引用的发现和释放也不是立即的，有时需要重复几次 GC ，才会发现并释放弱引用的内存对象。
• 软引用和弱引用在添加到 ReferenceQueue 的时候，其指向真实内存的引用已经被置为空了，相关的内存也已经被释放掉了。而虚引用在添加到 ReferenceQueue 的时候，内存还没有释放，仍然可以对其进行访问。

下文转自：Understanding Weak References Blog
Some time ago I was interviewing candidates for a Senior Java Engineer position. Among the many questions I asked was “What can you tell me about weak references?” I wasn’t expecting a detailed technical treatise on the subject. I would probably have been satisfied with “Umm… don’t they have something to do with garbage collection?” I was instead surprised to find that out of twenty-odd engineers, all of whom had at least five years of Java experience and good qualifications, only two of them even knew that weak references existed, and only one of those two had actual useful knowledge about them. I even explained a bit about them, to see if I got an “Oh yeah” from anybody – nope. I’m not sure why this knowledge is (evidently) uncommon, as weak references are a massively useful feature which have been around since Java 1.2 was released, over seven years ago.
Now, I’m not suggesting you need to be a weak reference expert to qualify as a decent Java engineer. But I humbly submit that you should at least know what they are – otherwise how will you know when you should be using them? Since they seem to be a little-known feature, here is a brief overview of what weak references are, how to use them, and when to use them.

Strong references

First I need to start with a refresher on strong references. A strong reference is an ordinary Java reference, the kind you use every day. For example, the code:

StringBuffer buffer = new StringBuffer();

creates a new StringBuffer() and stores a strong reference to it in the variable buffer. Yes, yes, this is kiddie stuff, but bear with me. The important part about strong references – the part that makes them “strong” – is how they interact with the garbage collector. Specifically, if an object is reachable via a chain of strong references (strongly reachable), it is not eligible for garbage collection. As you don’t want the garbage collector destroying objects you’re working on, this is normally exactly what you want.
When strong references are too strong
It’s not uncommon for an application to use classes that it can’t reasonably extend. The class might simply be markedfinal, or it could be something more complicated, such as an interface returned by a factory method backed by an unknown (and possibly even unknowable) number of concrete implementations. Suppose you have to use a class Widget and, for whatever reason, it isn’t possible or practical to extendWidget to add new functionality.
What happens when you need to keep track of extra information about the object? In this case, suppose we find ourselves needing to keep track of each Widget’s serial number, but theWidget class doesn’t actually have a serial number property – and because Widget isn’t extensible, we can’t add one. No problem at all, that’s what HashMapsare for:

serialNumberMap.put(widget, widgetSerialNumber);

This might look okay on the surface, but the strong reference towidget will almost certainly cause problems. We have to know (with 100% certainty) when a particular Widget’s serial number is no longer needed, so we can remove its entry from the map. Otherwise we’re going to have a memory leak (if we don’t remove Widgets when we should) or we’re going to inexplicably find ourselves missing serial numbers (if we remove Widgets that we’re still using). If these problems sound familiar, they should: they are exactly the problems that users of non-garbage-collected languages face when trying to manage memory, and we’re not supposed to have to worry about this in a more civilized language like Java.
Another common problem with strong references is caching, particular with very large structures like images. Suppose you have an application which has to work with user-supplied images, like the web site design tool I work on. Naturally you want to cache these images, because loading them from disk is very expensive and you want to avoid the possibility of having two copies of the (potentially gigantic) image in memory at once.
Because an image cache is supposed to prevent us from reloading images when we don’t absolutely need to, you will quickly realize that the cache should always contain a reference to any image which is already in memory. With ordinary strong references, though, that reference itself will force the image to remain in memory, which requires you (just as above) to somehow determine when the image is no longer needed in memory and remove it from the cache, so that it becomes eligible for garbage collection. Once again you are forced to duplicate the behavior of the garbage collector and manually determine whether or not an object should be in memory.

Weak references

A weak reference, simply put, is a reference that isn’t strong enough to force an object to remain in memory. Weak references allow you to leverage the garbage collector’s ability to determine reachability for you, so you don’t have to do it yourself. You create a weak reference like this:
WeakReference weakWidget = new WeakReference(widget);

and then elsewhere in the code you can useweakWidget.get() to get the actual Widgetobject. Of course the weak reference isn’t strong enough to prevent garbage collection, so you may find (if there are no strong references to the widget) that weakWidget.get()suddenly starts returning null.
To solve the “widget serial number” problem above, the easiest thing to do is use the built-in WeakHashMap class.WeakHashMap works exactly like HashMap, except that the keys (not the values!) are referred to using weak references. If a WeakHashMap key becomes garbage, its entry is removed automatically. This avoids the pitfalls I described and requires no changes other than the switch fromHashMap to a WeakHashMap. If you’re following the standard convention of referring to your maps via theMap interface, no other code needs to even be aware of the change.

Reference queues

Once a WeakReference starts returning null, the object it pointed to has become garbage and the WeakReference object is pretty much useless. This generally means that some sort of cleanup is required; WeakHashMap, for example, has to remove such defunct entries to avoid holding onto an ever-increasing number of dead WeakReferences.
The ReferenceQueue class makes it easy to keep track of dead references. If you pass a ReferenceQueue into a weak reference’s constructor, the reference object will be automatically inserted into the reference queue when the object to which it pointed becomes garbage. You can then, at some regular interval, process the ReferenceQueue and perform whatever cleanup is needed for dead references.

Different degrees of weakness

Up to this point I’ve just been referring to “weak references”, but there are actually four different degrees of reference strength: strong, soft, weak, and phantom, in order from strongest to weakest. We’ve already discussed strong and weak references, so let’s take a look at the other two.

Soft references

A soft reference is exactly like a weak reference, except that it is less eager to throw away the object to which it refers. An object which is only weakly reachable (the strongest references to it are WeakReferences) will be discarded at the next garbage collection cycle, but an object which is softly reachable will generally stick around for a while.
SoftReferences aren’t required to behave any differently than WeakReferences, but in practice softly reachable objects are generally retained as long as memory is in plentiful supply. This makes them an excellent foundation for a cache, such as the image cache described above, since you can let the garbage collector worry about both how reachable the objects are (a strongly reachable object will never be removed from the cache) and how badly it needs the memory they are consuming.

Phantom references

A phantom reference is quite different than either SoftReference or WeakReference. Its grip on its object is so tenuous that you can’t even retrieve the object – its get() method always returns null. The only use for such a reference is keeping track of when it gets enqueued into a ReferenceQueue, as at that point you know the object to which it pointed is dead. How is that different from WeakReference, though?
The difference is in exactly when the enqueuing happens. WeakReferences are enqueued as soon as the object to which they point becomes weakly reachable. This is before finalization or garbage collection has actually happened; in theory the object could even be “resurrected” by an unorthodox finalize() method, but the WeakReference would remain dead. Phantom References are enqueued only when the object is physically removed from memory, and the get() method always returns null specifically to prevent you from being able to “resurrect” an almost-dead object.
What good are Phantom References? I’m only aware of two serious cases for them: first, they allow you to determine exactly when an object was removed from memory. They are in fact the only way to determine that. This isn’t generally that useful, but might come in handy in certain very specific circumstances like manipulating large images: if you know for sure that an image should be garbage collected, you can wait until it actually is before attempting to load the next image, and therefore make the dreaded OutOfMemoryError less likely.
Second, Phantom References avoid a fundamental problem with finalization: finalize()methods can “resurrect” objects by creating new strong references to them. So what, you say? Well, the problem is that an object which overrides finalize() must now be determined to be garbage in at least two separate garbage collection cycles in order to be collected. When the first cycle determines that it is garbage, it becomes eligible for finalization. Because of the (slim, but unfortunately real) possibility that the object was “resurrected” during finalization, the garbage collector has to run again before the object can actually be removed. And because finalization might not have happened in a timely fashion, an arbitrary number of garbage collection cycles might have happened while the object was waiting for finalization. This can mean serious delays in actually cleaning up garbage objects, and is why you can get OutOfMemoryErrors even when most of the heap is garbage.
With Phantom Reference, this situation is impossible – when a Phantom Reference is enqueued, there is absolutely no way to get a pointer to the now-dead object (which is good, because it isn’t in memory any longer). Because Phantom Reference cannot be used to resurrect an object, the object can be instantly cleaned up during the first garbage collection cycle in which it is found to be phantomly reachable. You can then dispose whatever resources you need to at your convenience.
Arguably, the finalize() method should never have been provided in the first place. Phantom Referencesare definitely safer and more efficient to use, and eliminating finalize() would have made parts of the VM considerably simpler. But, they’re also more work to implement, so I confess to still using finalize() most of the time. The good news is that at least you have a choice.

Conclusion

I’m sure some of you are grumbling by now, as I’m talking about an API which is nearly a decade old and haven’t said anything which hasn’t been said before. While that’s certainly true, in my experience many Java programmers really don’t know very much (if anything) about weak references, and I felt that a refresher course was needed. Hopefully you at least learned a little something from this review.