有关 SoftReference 的一些事实
try { Object[] ignored = new Object[(int) Runtime.getRuntime().maxMemory()];} catch (Throwable e) { // Ignore OME}?（来源：http://stackoverflow.com/questions/3785713/how-to-make-the-java-system-release-soft-references）?上面这段代码可以让 JVM 立即回收 SoftReference，很猛很暴力。?那么，常见的 JVM，例如 HotSpot 是怎么回收 SoftReference 的呢？ 谢天谢地，已经有人给出了研究结果：http://jeremymanson.blogspot.com/2009/07/how-hotspot-decides-to-clear_07.html?直接翻译一下结论，是这样的：?”发生 GC 的时候，是否清理 SoftReference 取决于两个因素：1. 引用的时间戳；2. 有多少可用内存。?计算公式非常简单，首先定义：free_heap ? ?- 堆里的空闲内存数量，单位是 MBinterval ? ? ? - 上一次 GC 时间与与引用记录的时间戳之间的时间间隔ms_per_mb - 是一个毫秒数常量，表示每 MB?空闲堆中保留的 SoftReference 数量。?判定公式是：interval <= free_heap * ms_per_mb“?其中 ms_per_mb 是一个可以设置的 JVM 参数：-XX:SoftRefLRUPolicyMSPerMB，结合公式很容易看明白，这个参数决定 FullGC 保留的 SoftReference 数量，参数值越大，GC 后保留的软引用对象就越多。?有些博客在推荐 JVM 参数时，建议 -XX:SoftRefLRUPolicyMSPerMB 配置成 0 ，这样可以避免在 GC 后保留 SoftReference。是否这样就可以完全避免软引用回收的问题？我想只有 JVM 知道了。?这里也揭示了 JVM 回收 SoftReference 的算法，注意它并不是真正淘汰最久最少访问的对象，而是根据内存余量，淘汰最近未访问的对象。相比真正的 LRU 淘汰算法，这显得比较粗放。?上面这些事实背后，我的结论是，使用 SoftReference 前需要谨慎考虑：1. 你的应用的确需要把这些对象保留在 JVM 中，如果内存够用就永不清理吗？2. 这些软引用对象会不会过分占用内存，导致你的应用内存压力增加，频繁 Full GC?3. 除了 SoftReference, 你有没有更好管理这些对象的机制？?最后，决定使用 SoftReference 的同学，请三思~