ReferenceQueue适用于对象池吗？

我想在我的库中使用缓冲池并考虑使用SoftReference来实现对象的隐式返回和池大小平衡。ReferenceQueue适用于对象池吗？

因此，通过 “合适的” 我的意思是：

他们是相当高性能的比较明确的ArrayBlockingQueue，它例如？（小于数量级）
它们在现代虚拟机（如Hotspot，Dalvik和ART）中的可靠性是否足以比WeakReference更“柔和”？

对我来说，这不是“不成熟的优化”，只是一种架构选择，可以减少将对象返回池的麻烦，但如果不符合指定的要求，将会消除池的任何好处。

2017-03-15 Pavlus

你如何计划在那里使用软引用？我认为我们可以放心地说，这些构造并非设计时考虑到了任何形式 - 它们是一个定型构造，并且与任何类型的定型一样，您不能期望它在任何合理的时间范围内执行或就此而言，所发生的事情取决于大量的JVM和GC特定配置。 –

没有理由认为SoftReference或WeakReference不适用于任何Java（TM）平台或Android平台。有一个Android bug report讨论了Java（tm）和Android行为之间的区别：Android比Java（tm）更“热切”地清除软引用。然而，分析指出，差别是：

通过设计，并且本说明书的“语义包络”内
;即Java（tm）javadocs。

但是，我不明白的是你如何建议使用Reference对象来实现返回对象（到池）。如果已分配缓冲区的代码删除其对对象的（强）引用，那么弱引用或软引用将在引用入队前被清除。这意味着在缓冲池的ReferenceQueue得知它之前，缓冲区将被GC'd。另一方面，如果你只是使用弱/软引用，以便池不是内存泄漏......没关系。 SoftReference是正确的选择。

SoftReference对显式池大小无效。软引用仅对内存压力做出响应，而您对此无法控制。

最后，引用队列和引用队列产生可观的GC开销。虽然它们不间断，但GC必须在遇到它们时标记它们。当GC打破它们时，在排队它们和处理排队参考文件时会产生可观的开销。

来源

2017-03-15 13:59:53

我的意思是说SR对于隐式池大小的调整很有用 - 如果没有足够的内存 - 它们将被清除。 – Pavlus

由于各种原因，仅依靠SR进行泳池大小调整可能会导致性能问题。明确的池大小会更好，可能还有SR。但是，管理费用很难衡量，因为它们会显示为额外的GC超前。 –

通过“返回池”我的意思是说，一旦没有对象的强引用（它不再被第三方代码使用），它将被GC排队，并且由于SoftReference仍然可以，如果没有收集到，我们可以使用队列中的参考来重新获取那些“故意丢失”的对象。如果没有足够的记忆和大量未使用的物体 - 它们将被收集。 – Pavlus

ReferenceQueue适用于对象池吗？

回答

相关问题