Java SoftReference,用于处理GC和GC行为

时间:2011-10-15 13:35:34

标签: java garbage-collection soft-references g1gc

我想使用尽可能多的内存使用SoftReference来编写缓存,只要它的效率不会太低。

尝试通过计算对象大小或通过获取JVM的一些已用内存近似来估计使用的大小是死路一条。

javadoc甚至声明SoftReference对于内存感知缓存很有用,但JVM实现如何处理SoftReference没有硬性规则。我只讨论JVM(版本6.22及更高版本和版本7)的Oracle实现。

现在我的问题(请随意回答部分,分组或以任何方式请你):

  1. JVM是否考虑了对象的最后一次访问权限并且只删除了旧对象? Javadoc说:Virtual machine implementations are, however, encouraged to bias against clearing recently-created or recently-used soft references.
  2. 当记忆力变紧时会发生什么? JVM恐慌,只吃所有物品?
  3. 是否有一个参数告诉JVM只能吃多少才能生存(没有OOME s)并且活得健康(没有CPU只运行GC

3 个答案:

答案 0 :(得分:1)

我认为没有订单。 (我不确定事件的顺序)

但是软引用会发生什么,它始终保证在内存不足异常之前释放它们。除非你有一个指向他们的硬参考。

但是你应该知道你可能会尝试访问它们而它们已经消失了。我的猜测是垃圾收集器只会吃第一个符合操作所需数量的软参考。

答案 1 :(得分:0)

虽然SoftReferences是一个很酷的功能,但我个人不敢大声使用它们 我不知道每个其他组件的内存要求的项目。内存占用SoftReference缓存是否会使其他部分表现不佳?

我不会使用SoftReferences而是考虑使用EHCache。它允许您根据条目数限制特定缓存的大小,甚至更好地限制内存中使用的字节(这是即将发布的2.5版本中的新功能)。当然,可以配置不同的驱逐策略,例如LRU。您可以使用EHCache进行配置。

如果您使用的是Spring,那么3.1版本也会为您提供一些不错的@Cachable方法级注释; EHCache可以在那里用作缓存实现。

答案 2 :(得分:0)

  

当记忆力变紧时会发生什么? JVM恐慌,只吃所有   对象

我知道使用Oracle 1.6 JVM的情况并非如此。我知道处理并发请求的服务器使用包含软引用中的实际数据的响应的情况。我观察到当一个线程报告一个低内存情况时,其他线程的软引用继续保持其内容(引用的对象)。

  

是否有一个参数告诉JVM只吃多少   生存(没有OOME)和健康的生活(没有CPU只运行   GC)

什么才能生存?你的意思是如果需要X量的内存,那么只回收软引用直到X可用?我没有找到任何这样的调整参数,但正如我所说的,当JVM需要回收时,JVM似乎没有回收所有软引用。