Java SoftReference、恐慌 GC 和 GC 行为
我想使用尽可能多的内存使用 SoftReference 编写缓存，只要效率不会太低。
尝试通过计算对象大小或获取 JVM 的一些已用内存近似值来估计已用大小是死胡同。
javadoc 甚至指出 SoftReference 对于内存感知缓存很有用，但对于 JVM 实现如何处理 SoftReference 没有硬性规定s。我只讨论 JVM 的 Oracle 实现（版本 6.22 及更高版本和版本 7）。
现在我的问题（请随意回答部分、分组或以任何您喜欢的方式）：
JVM是否考虑对象的最后访问并仅删除旧的？ Javadoc 指出：但是，鼓励虚拟机实现偏向于清除最近创建或最近使用的软引用。- 当内存紧张时会发生什么？
JVM发生恐慌并吃掉所有对象？ - 是否有一个参数告诉
JVM只吃尽可能多的食物以生存（没有OOME）并健康地生活（不让CPU只运行GC< /代码>)
I want to write a cache using SoftReferences using as much memory as possible, as long as it doesn't get too inefficient.
Trying to estimate the used size by calculating object sizes or by getting some used memory approximation of the JVM are dead ends.
The javadoc even states that SoftReferences are good for memory-aware caches, but there is no hard rule on how a JVM implementation shall handle SoftReferences. I'm only talking about the Oracle implementation of the JVM (Version 6.22 and above and Version 7).
Now my questions (please feel free to answer partial, grouped or in any way you please):
- Does the
JVMtake the last access of the object into account and only remove the old ones? Javadoc states:Virtual machine implementations are, however, encouraged to bias against clearing recently-created or recently-used soft references. - What happens when memory gets tight? The
JVMpanics and just eats all objects? - Is there a parameter for telling the
JVMto only eat as much to survive (noOOMEs) and live healthy (not having the CPU only run theGC)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为没有命令。 （虽然我不确定事件的顺序）
但是软引用发生的情况是，总是保证它们会在出现内存不足异常之前被释放。除非你有一个硬引用指向它们。
但您应该意识到，您可能会尝试访问它们，但它们却消失了。我的猜测是，垃圾收集器只会吃掉第一个适合操作所需数量的软引用。
I don't think there is an order. (I'm not sure though about the order of events)
But what happens with soft references is that it is always guaranteed that they will be released before there is an out of memory exception. Unless you have a hard reference pointing to them.
But you should be aware that you might try to access them and they are gone. My guess is that the garbage collector will just eat the first soft reference that fits the amount needed for the operation.
虽然 SoftReferences 是一个很酷的功能，但我个人不敢大规模使用它们
我不知道其他每个组件的内存要求的项目。占用内存的 SoftReference 缓存是否会导致其他部分性能不佳？
我不使用 SoftReferences，而是考虑使用 EHCache。它可以让您根据条目数量来限制特定缓存的大小，甚至可以根据内存中使用的字节数来限制（这是即将推出的 2.5 版本中的一项新功能）。当然可以配置不同的驱逐策略，比如LRU。您可以使用 EHCache 配置很多内容。
如果您使用 Spring，那么 3.1 版本还将为您提供一些不错的 @Cachable 方法级注释； EHCache 可以用作那里的缓存实现。
Although SoftReferences are a cool feature, I personally don't dare using them in large
projects where I don't know the memory requirements of every other component. Will a memory-hogging SoftReference cache make other parts perform badly?
I'd instead of using SoftReferences I'd consider using EHCache. It let's you limit the size of particular caches in terms of number of entries, or even better, the bytes used in memory (this is a new feature in the upcoming version 2.5). Different eviction strategies can be configured, of course, such as LRU. There's lots you can configure with EHCache.
If you're using Spring, then version 3.1 will also provide you with some nice @Cachable method-level annotations; EHCache can be used as a caching implementation there.
我知道 Oracle 1.6 JVM 的情况并非如此。我知道一种情况，处理并发请求的服务器使用的响应包含软引用内的实际数据。我观察到，当一个线程报告内存不足情况时，其他线程的软引用继续保留其内容（引用的对象）。
什么足以生存？您的意思是，如果需要 X 量的内存，则仅回收软引用直到 X 可用？我没有找到任何这样的调整参数，但正如我所说，当 JVM 需要回收软引用时，它似乎并没有回收所有软引用。
I know for a fact that with Oracle 1.6 JVM this is not the case. I am aware of a situation where a server that processes concurrent requests uses a response the contains the actual data inside a soft reference. I have observed that when a low memory situation is reported by one thread the other threads' soft references continue to hold on to their contents (the referenced objects).
What is enough to survive? You mean that if X amount of memory is required then only reclaim soft-references till X is available? I didn't find any such tuning parameter but as I said JVM does not seem to be reclaiming all soft references when it needs to reclaim one.