根据 Guava 的 MapMaker.softValues() 的文档：
警告：在大多数情况下，最好设置每个缓存的最大大小，而不是使用软引用。如果您非常熟悉软引用的实际后果，则应仅使用此方法。
我对软引用有中等程度的了解——它们的行为、用途以及它们与垃圾收集的约定。但是我想知道文档所暗示的这些实际后果是什么。为什么使用最大尺寸而不是软引用更好？就实现缓存而言，软引用的算法和行为是否比硬编码上限更有效？
【问题讨论】：
标签： java caching garbage-collection soft-references
我认为他们也暗示的是，如果您使用软引用映射，您应该为最大内存使用量和可能更多的 gc 活动做好准备，因为引用只是 gc'd，因为内存需要被释放.
如果您知道您只需要缓存中的最后 n 个值，那么使用 LRU 缓存是一种更精简的方法，对正在运行的应用程序具有更可预测的资源使用情况。
此外，根据this 的说法，-server 和 -client JVM 之间的行为似乎存在细微差别。
Sun JRE 确实处理了软引用 与弱引用不同。我们 试图坚持反对 如果存在，则由 SoftReference 引用 不是对可用的压力 记忆。一个细节：政策 “-client”和“-server” JRE 是 不同：-client JRE 试图 保持你的足迹小 更喜欢清除 SoftReferences 而不是扩展堆，而 -server JRE 试图保留您的 性能高，更喜欢 扩展堆（如果可能）而不是 而不是清除 SoftReferences。一种尺寸 不适合所有人。
【讨论】：
使用 SoftReference 的一个实际问题是它们往往会被一次性全部丢弃。您拥有缓存的原因是在大多数情况下提供相当好的性能。
但是，将 SoftReferences 用于缓存可能意味着在您的应用程序停止进行 GC 后，它将缓慢运行，直到缓存重建。即，就在您需要赶上应用程序的时候。
注意：您可以使用LinkedHashMap as an LRU cache，它不必很复杂。
【讨论】：