使用软引用有什么“实际后果”?

时间:2011-07-06 06:02:45

标签: java caching garbage-collection soft-references

根据番石榴MapMaker.softValues()的文档:

  

警告:在大多数情况下,最好设置每缓存最大大小而不是使用软引用。如果您熟悉软引用的实际后果,则应该只使用此方法。

我对软引用有一个中间的理解 - 它们的行为,用途以及它们与垃圾收集的契约。但是我想知道这些实际后果是由博士提到的。为什么使用最大尺寸而不是软参考更好?在实现缓存方面,软引用的算法和行为是否使得它们的使用更加高效?硬编码上限?

2 个答案:

答案 0 :(得分:4)

我认为它们所暗示的是,如果你使用Soft参考映射,你应该为最大内存使用量和可能更多gc活动做好准备,因为引用只是gc'd,因为内存需要被释放

如果您知道只需要缓存中的最后n个值,那么使用LRU缓存是一种更精简的方法,可以为正在运行的应用程序提供更可预测的资源使用。

此外,根据this,似乎-server和-client JVM之间的行为存在细微差别。

  

Sun JRE确实对待SoftReferences   与WeakReferences不同。我们   试图抓住对象   如果存在,则由SoftReference引用   对现有的压力不大   记忆。一个细节:政策   “-client”和“-server”JRE是   不同:-client JRE尝试   保持你的足迹小   更喜欢清除SoftReferences   而不是扩大堆,而   -server JRE试图让你的   优先考虑的表现   扩展堆(如果可能的话)   比清除SoftReferences。一个尺寸   并不适合所有人。

答案 1 :(得分:4)

使用SoftReferences的一个实际问题是它们往往会被丢弃。您拥有缓存的原因是在大多数情况下提供相当好的性能。

但是,对于缓存使用SoftReferences可能意味着在应用程序停止运行GC之后,它将缓慢运行,直到重建缓存为止。即在您需要申请时赶上。

注意:您可以使用LinkedHashMap as an LRU cache,它不一定非常复杂。