如何利用“软参考统计”和“弱参考统计”来改进Java EE应用程序

Question

我专注于

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

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

我在问“软参考统计”和“弱参考统计”是否有助于我的目标，即： 了解我们是否有问题，或者在应用程序java代码或应用程序服务器的configurazione中有什么需要修复（或只是改进）。

建议如何弄清楚如何利用这些数据

  

软参考统计

     

共找到11.416个java.lang.ref.SoftReference对象，   它轻柔地引用393个对象。   总共122.9 KB的2.414个对象仅通过软引用保留（保持活动状态）。没有柔和引用总共0 B的对象   也通过软参考强烈保留（保持活力）。

     

弱参考统计

     

共找到28.849个java.lang.ref.WeakReference对象，   弱引用11.663个对象。   总共7,4 MB的132.437个对象仅通过弱引用保留（保持活动状态）。没有总共0 B的对象被弱引用   也通过弱引用强烈保留（保持活着）。

Answer 1

第一条规则：绝不使用柔软的参考。太太加入了这些人后悔他们的决定，因为他们没用，让GC更贵。

弱参考是可以的。

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

应用程序堆有多大，你需要让它的性能更好？当GC启动时，你能够接受的最大延迟是多少？您是否尝试过调整GC？

---

修改

为什么不使用软引用。软引用很糟糕，因为

• 它们需要收集2个GC循环。第一个GC循环标记它们，第二个GC循环实际收集内存。 （这与MarkSweep收藏家没有任何关系）
• 完整GC后，它们会被标记为收集。

如果您确实需要SoftReference中保存的数据，则加载SF，完全GC，再次加载SF的循环，将启动完整的GC，这样会很糟糕。该应用程序可能不会因为OOME而崩溃，但它将接近无法使用。

弱引用更好，因为它们只有在“弱”可达时才会被清除，而不是在应用程序内存不足时清除。我所知道的使用弱引用的框架的最佳（也是唯一）示例是Robotium（一个android测试框架）。