弱引用，软引用及虚引用对GC的影响
在应用程序中使用非强引用会导致一系列的问题，对GC的响应时间及吞吐量都会有所影响。尽管这类引用在某些场景下可以减少OutOfMemoryError的出现频率，但过度的使用则会严重影响到垃圾回收，从而导致应用程序的性能遭受影响。
应该注意什么？
在使用弱引用时，你最好了解一下它是如何被回收的。一旦垃圾回收器发现有一个对象是弱可达的，也就是说，它只剩下弱引用了，这个对象就会被放到一个相应的ReferenceQueue中，这样它就可以被析构并回收了。随后它可能会被从队列中取出，并进行相关的清理活动。这类清理任务的一个典型例子便是清除缓存中的无效KEY。
这里还有一个小技巧就是在这个对象最终被回收前，你还能再新建一个强引用来指向它，因此垃圾回收器在回收前还必须得进行二次确认。
其实弱引用要比你想象的常见得多。许多缓存方案都是通过弱引用来解决的，所以即便你没有在代码中创建过弱引用对象，但很可能你的应用程序中就大量使用到了它们。
而说到软引用，你需要知道的是它的回收速度要比弱引用慢一些。它具体会何时回收是不确定的，这取决于具体的JVM实现。通常来说在多次回收内存后空间仍然不足的话会触发软引用的回收。也就是说，你可能会面临比预期的更频繁且时间更长的GC暂停。
而对于虚引用，你可能就得手动进行内存管理并将它们标记为允许回收才行了。虚引用非常危险，如果你只是简单地看一眼文档的话，你会觉得使用它是非常安全的：
为了确保可回收对象保持原状，虚引用指向的对象必须无法被获取到：虚引用的get方法应当始终返回null。
但很奇怪的是，许多开发人员都忽略了该文档中接下来的一段说明(加粗部分）:
与弱引用和软引用不同，虚引用在加入回收队列后，是无法被垃圾回收器自动清除的。虚引用可达的对象会一直维持原状，直到这类引用都被清除或者它们自身也不可达。
没错，我们必须手动地[clear()](http://docs.oracle.com/javase/7/docs/api/java/lang/ref/Reference.html#clear()虚引用，否则便会让JVM陷入内存耗尽的处境。虚引用存在的意义首先就在于这是确定对象是否已经不可达的唯一途径。与弱引用和软引用不同，虚引用对象是决不可能“复活”的。
看几个例子
我们来看下这个demo程序，它会创建大量的对象，但在新生代GC中就会被回收掉。但是还有个调整持久代的提升比率阈值的小窍门，让我们用-Xmx24m -XX:NewSize=16m -XX:MaxTenuringThreshold=1这个参数来运行下这个程序，来看看它的GC日志：
.330: [GC (Allocation Failure) 20933K->8229K(22528K), 0.0033848 secs]
.335: [GC (Allocation Failure) 20517K->7813K(22528K), 0.0022426 secs]
.339: [GC (Allocation Failure) 20101K->7429K(22528K), 0.0010920 secs]
.341: [GC (Allocation Failure) 19717K->9157K(22528K), 0.0056285 secs]
.348: [GC (Allocation Failure) 21445K->8997K(22528K), 0.0041313 secs]
.354: [GC (Allocation Failure) 21285K->8581K(22528K), 0.0033737 secs]
.359: [GC (Allocation Failure) 20869K->8197K(22528K), 0.0023407 secs]
.362: [GC (Allocation Failure) 20485K->7845K(22528K), 0.0011553 secs]
.365: [GC (Allocation Failure) 20133K->9501K(22528K), 0.0060705 secs]
.371: [Full GC (Ergonomics) 9501K->2987K(22528K), 0.0171452 secs]
这种情况下是几乎没有Full GC的。然而，一旦程序开始创建弱引用的话(-Dweak.refs=true)，情况将彻底发生变化。这种情况很常见，比如说用作弱哈希表的KEY或者分析对象创建的性能。但不管是什么情况，弱引用的引入都会导致这样的结果：
.059: [Full GC (Ergonomics) 20365K->19611K(22528K), 0.0654090 secs]
.125: [Full GC (Ergonomics) 20365K->19711K(22528K), 0.0707499 secs]
.196: [Full GC (Ergonomics) 20365K->19798K(22528K), 0.0717052 secs]
.268: [Full GC (Ergonomics) 20365K->19873K(22528K), 0.0686290 secs]
.337: [Full GC (Ergonomics) 20365K->19939K(22528K), 0.0702009 secs]
.407: [Full GC (Ergonomics) 20365K->19995K(22528K), 0.0694095 secs]
正如你所看到的，现在出现了大量的Full GC，并且回收的时间也增加了一个数量级。显然这是一次过早提升（premature promotion），不过却有点棘手。当然，罪魁祸首就是弱引用。在没使用它们之前，应用所创建的对象在提升到老生代前就已经被回收掉了。但是使用了弱使用之后，这些对象会多存活一次GC周期才能被正确地回收掉。一个简单的解决方案就是增加新生代的大小，-Xmx64m -XX:NewSize=32m：
.328: [GC (Allocation Failure) 38940K->13596K(61440K), 0.0012818 secs]
.332: [GC (Allocation Failure) 38172K->14812K(61440K), 0.0060333 secs]
.341: [GC (Allocation Failure) 39388K->13948K(61440K), 0.0029427 secs]
.347: [GC (Allocation Failure) 38524K->15228K(61440K), 0.0101199 secs]
.361: [GC (Allocation Failure) 39804K->14428K(61440K), 0.0040940 secs]
.368: [GC (Allocation Failure) 39004K->13532K(61440K), 0.0012451 secs]
于是这些对象便又能在新生代GC中被回收掉了。
在下一个DEMO程序中我们用到了软引用，而情况就更为严重了。除非应用面临即将抛出OutOfMemoryError异常的风险，否则软可达的对象是不会被回收的。用软引用替换掉弱引用之后，DEMO程序立即便出现了更多的FULL GC事件：
.162: [Full GC (Ergonomics) 31561K->12865K(61440K), 0.0181392 secs]
.184: [GC (Allocation Failure) 37441K->17585K(61440K), 0.0024479 secs]
.189: [GC (Allocation Failure) 42161K->27033K(61440K), 0.0061485 secs]
.195: [Full GC (Ergonomics) 27033K->14385K(61440K), 0.0228773 secs]
.221: [GC (Allocation Failure) 38961K->20633K(61440K), 0.0030729 secs]
.227: [GC (Allocation Failure) 45209K->31609K(61440K), 0.0069772 secs]
.234: [Full GC (Ergonomics) 31609K->15905K(61440K), 0.0257689 secs]
从第三个DEMO程序中不难看出，虚引用是当之无愧的王者。使用相同的JVM参数运行这个程序，结果和弱引用的非常类似。由于我们在本节前面中所提到的两者在回收阶段的区别，因此事实上这里出现的Full GC暂停要更少一些。
不过，一旦加上停止清除虚引用的标记（-Dno.ref.clearing=true）之后，结果马上就变成了这样：
.180: [Full GC (Ergonomics) 57343K->57087K(61440K), 0.0879851 secs] .269: [Full GC (Ergonomics) 57089K->57088K(61440K), 0.0973912 secs] .366: [Full GC (Ergonomics) 57091K->57089K(61440K), 0.0948099 secs] Exception in thread "main" java.lang.OutOfMemoryError: Java heap space 虚引用的使用一定要慎之又慎，并且一定要及时清理虚可达对象。否则的话，等着你的就会是OutOfMemoryError了。相信我，不这么做的话你很快就会栽在这里：处理引用队列的那个线程抛出了一个异常，而等着你的只是一个挂掉的应用。
我的JVM会不会受到影响？
通常我们会建议使用-XX:+PrintReferenceGC这个JVM选项来分析不同的引用类型对垃圾回收所带来的影响。如果从弱引用的例子开始就加入这个选项的话，你会看到:
.173: [Full GC (Ergonomics) 2.234: [SoftReference, 0 refs, 0.0000151 secs]2.234: [WeakReference, 2648 refs, 0.0001714 secs]2.234: [FinalReference, 1 refs, 0.0000037 secs]2.234: [PhantomReference, 0 refs, 0 refs, 0.0000039 secs]2.234: [JNI Weak Reference, 0.0000027 secs][PSYoungGen: 9216K->8676K(10752K)] [ParOldGen: 12115K->12115K(12288K)] 21331K->20792K(23040K), [Metaspace: 3725K->3725K(1056768K)], 0.0766685 secs] [Times: user=0.49 sys=0.01, real=0.08 secs]
.250: [Full GC (Ergonomics) 2.307: [SoftReference, 0 refs, 0.0000173 secs]2.307: [WeakReference, 2298 refs, 0.0001535 secs]2.307: [FinalReference, 3 refs, 0.0000043 secs]2.307: [PhantomReference, 0 refs, 0 refs, 0.0000042 secs]2.307: [JNI Weak Reference, 0.0000029 secs][PSYoungGen: 9215K->8747K(10752K)] [ParOldGen: 12115K->12115K(12288K)] 21331K->20863K(23040K), [Metaspace: 3725K->3725K(1056768K)], 0.0734832 secs] [Times: user=0.52 sys=0.01, real=0.07 secs]
.323: [Full GC (Ergonomics) 2.383: [SoftReference, 0 refs, 0.0000161 secs]2.383: [WeakReference, 1981 refs, 0.0001292 secs]2.383: [FinalReference, 16 refs, 0.0000049 secs]2.383: [PhantomReference, 0 refs, 0 refs, 0.0000040 secs]2.383: [JNI Weak Reference, 0.0000027 secs][PSYoungGen: 9216K->8809K(10752K)] [ParOldGen: 12115K->12115K(12288K)]
通常来说，只有当你确信自己的应用程序的吞吐量或者响应时延已经受到GC的影响时，才有必要去分析这类信息。只有在这种情况下，你才有必要去检查此类日志。一般情况下，每次GC周期中所回收的引用数都不多，大多数情况下都是0。如果应用程序花费了大量的时间在进行引用的清理或者出现大量引用被回收的情况，那就需要进行进一步的分析了。
解决方案
一旦你确认自己的程序出现了误用、滥用弱引用，软引用或虚引用的情况，这通常就需要调整一下应用的内部实现逻辑了。一般这都得视应用的具体情况而定，很难给出什么通用的建议。不过，应该牢记如下几条原则：
- 弱引用：如果问题的现象是某个内存池的使用量上升的话，那么通常增加一下池的大小（或话干脆把整个堆调大）就能解决问题。正如上述示例中所见，增加堆的大小或者新生代的大小可以缓解此类问题。
- 虚引用：一定要确认是否清除了引用。稍不留神便会忽略了某些情况，从而导致清理的线程无法及时地清除引用队列，或者甚至没有清理，从而将负担扔给了垃圾回收器，进而便会导致抛出OutOfMemoryError异常。
- 软引用：一旦发现软引用是罪魁祸首，那就只能去修改下应用的实现逻辑了。
