如何利用“软引用统计”和“弱引用统计”改进Java应用程序

Question

我专注于

• 通过足迹分析获得对Java应用程序的体系结构理解
• 通过调优内存占用、优化Java集合和Java缓存使用来提高应用程序性能

为此，我在Java应用程序上使用Java堆分析工具存储器分析器，运行了一个负载测试，并分析了Java堆转储快照，该应用程序使用WebSphere应用服务器v7。

我想问的是，“软引用统计”和“弱引用统计”是否有助于实现我的目标，即:了解应用程序java代码或应用程序服务器的配置中是否有问题或需要修复(或只是改进)。

想知道如何利用这些数据的建议将是非常感谢的。

软参考统计 总共找到了11.416个java.lang.ref.SoftReference对象，其中软引用了393个对象。只有通过软引用才能保留总计122，9KB的2.414个对象(保持活动)。没有任何对象(总计为0B)被软引用，也没有通过软引用强保留(保持活着)。 弱参考统计 总共发现了28.849个java.lang.ref.WeakReference对象，其中弱引用了11.663个对象。只有通过弱引用才能保留总计7，4MB的132.437个对象(保持活动)。没有任何总计为0B的对象是弱引用的，也没有通过弱引用强保留(保持活着)的对象。

Answer 1

第一条规则:不要使用软推荐信。一个太阳的家伙补充说，他们后悔自己的决定，因为他们是无用的，使GC更昂贵。

弱的推荐信没问题。

问题是:如果您确实需要内存中的所有数据，尝试减少内存占用将导致额外的CPU、网络或磁盘开销，因为您需要将数据存储在其他地方。

这个应用程序的堆有多大，你需要让它表现得更好吗？当GC启动时，您能够接受的最大延迟是什么？你试过调整GC吗？

编辑

为什么不使用软引用。软引用是不好的，因为

• 它们要求收集两个GC周期。第一个GC周期标记它们，第二个周期实际收集内存。(这与MarkSweep收集器没有任何关系)
• 它们在完整的GC之后被标记为收集。

如果您实际上需要在SoftReference中保存数据，那么加载SF、满载GC、load SF的循环将重新启动，这将是糟糕的结果。该应用程序可能不会因为OOME而崩溃，但它将接近不可用。

弱引用更好，因为它们只有在“弱”可访问时才清除，而不是在应用程序内存不足时清除。我所知道的使用弱引用的框架的最好(也是唯一的)例子是罗布托 (一个安卓测试框架)。