Java SoftReference，恐慌 GC 和 GC 行为答案

【问题标题】：Java SoftReference, panicing GC and GC behaviorJava SoftReference，恐慌 GC 和 GC 行为
【发布时间】：2011-10-15 13:35:34
【问题描述】：

我想使用尽可能多的内存使用SoftReferences 编写缓存，只要它不会变得太低效。

试图通过计算对象大小或通过获取JVM 的一些已用内存近似值来估计已用大小是死胡同。

javadoc 甚至声明SoftReferences 对内存感知缓存有好处，但对于JVM 实现如何处理SoftReferences 没有硬性规定。我只是在谈论JVM（6.22 及更高版本和7 版）的Oracle 实现。

现在我的问题（请随意回答部分、分组或任何你喜欢的方式）：

JVM 是否考虑到对象的最后一次访问并且只删除旧的？ Javadoc 状态：Virtual machine implementations are, however, encouraged to bias against clearing recently-created or recently-used soft references.
当内存紧张时会发生什么？ JVM 惊慌失措并吃掉所有对象？
是否有一个参数告诉JVM 只吃多少才能生存（没有OOMEs）和健康地生活（没有CPU 只运行GC）

【问题讨论】：

【解决方案1】：

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

但是软引用的情况是它总是保证在出现内存不足异常之前释放它们。除非您有硬性参考指向它们。

但您应该注意，您可能会尝试访问它们，但它们已经消失了。我的猜测是垃圾收集器只会吃掉第一个符合操作所需数量的软引用。

【讨论】：

【解决方案2】：

虽然 SoftReferences 是一个很酷的功能，但我个人不敢大量使用它们我不知道其他所有组件的内存需求的项目。占用内存的 SoftReference 缓存是否会使其他部分表现不佳？

我会考虑使用EHCache，而不是使用SoftReferences。它让您可以根据条目数限制特定缓存的大小，甚至更好的是，内存中使用的字节数（这是即将发布的 2.5 版中的新功能）。当然，可以配置不同的驱逐策略，例如 LRU。您可以使用 EHCache 配置很多内容。

如果您使用的是 Spring，那么 3.1 版还将为您提供一些不错的 @Cachable 方法级注解； EHCache 可以用作那里的缓存实现。

【讨论】：

【解决方案3】：

当内存变紧时会发生什么？ JVM 恐慌并吃掉所有对象？

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

是否有一个参数告诉 JVM 只吃多少生存（没有 OOME）并且健康地生活（没有 CPU 只运行 GC)

什么足以生存？您的意思是，如果需要 X 数量的内存，那么只回收软引用直到 X 可用？我没有找到任何这样的调优参数，但正如我所说的，JVM 在需要回收一个软引用时似乎并没有回收所有软引用。

【讨论】：