Java ReferenceQueue适合对象池吗？

我想在我的库中使用缓冲池，并考虑使用

SoftReference

s来实现对象的隐式返回和池大小平衡

所以，我所说的“合适”是指：

例如，与显式ArrayBlockingQueue相比，它们的性能是否相当好？（小于数量级）

它们在现代虚拟机（如Hotspot、Dalvik和ART）中是否足够可靠，从而表现出比WeakReference更“软”的行为

---

对我来说，这不是“过早优化”，只是一种架构选择，它可以减少将对象返回池的麻烦，但如果不满足指定的要求，它将否定池的任何好处。

没有理由认为

SoftReference

或

WeakReference

不适用于任何Java（tm）平台或Android。关于Java（tm）和Android行为之间的区别有一个说法：Android比Java（tm）更“急切地”清除软引用。然而，分析指出，不同之处在于：

• 通过设计，以及
• 在规范的“语义封套”内；i、 e.Java（tm）javadocs

但是，我不明白的是，您建议如何使用引用对象来实现对象（到池）的返回。如果分配了缓冲区的代码删除了对对象的（强）引用，那么在引用排队之前，弱引用或软引用将被清除。这意味着缓冲区将在缓冲池的引用队列听到它之前被GC'd

另一方面，如果您只是使用弱/软引用，以便池不是内存泄漏。。。没关系<代码>软参考是正确的选择

SoftReference对于显式池大小调整不有用。软引用只对内存压力做出响应，而您对此几乎没有控制权

---

最后，引用和引用队列会产生可观的GC开销。当它们未被破坏时，GC必须在遇到它们时标记它们。当GC破坏它们时，在获取它们和处理排队引用时会有相当大的开销。

您如何实际计划在那里使用软引用？我想我们可以有把握地说，这些构造在设计时没有考虑任何类型的池-它们是一个终结构造，就像任何类型的终结一样，你不能真的期望它在任何合理的时间范围内执行，或者就此而言，因为发生的情况取决于大量JVM和GC特定配置。我的意思是，SR对于隐式池大小调整非常有用——如果内存不足——它们将被清除。出于各种原因，仅依赖SRs进行池大小调整可能会导致性能问题。显式池大小会更好，可能还有SRs。然而，开销很难衡量，因为它们会表现为额外的GC oherheads。我所说的“返回池”是指，一旦没有对对象的强引用（第三方代码不再使用该对象），它将被GC排队，并且由于SoftReference可能仍然可以变得强，如果还没有收集的话，我们可以使用队列中的引用来重新获取那些“故意丢失”的对象。如果没有足够的内存和大量未使用的对象，它们将被收集。可能存在某种滞后现象，最小池大小可以在每次获取时从ReferenceQueue重新填充，也可以由显式返回对象的人重新填充。否。您对“返回游泳池”的说法不正确。包javadoc声明“软引用和弱引用在添加到注册它们的队列（如果有的话）之前由收集器自动清除。”