Java 垃圾收集器 :old generation becomes larger and larger and cannot be reclaimed

Question

我正在编写我的 servlet 程序并使用 jconsole 和 jmap 来监视其内存状态。我发现当我的程序运行时，内存池“PS Old Gen”变得越来越大，最后我的 servlet 无法响应任何请求.

这是我的 JConsole 输出的截图:

当我点击“执行 GC”按钮时，没有任何反应。

因此，为了查看详细信息，我使用 jmap 转储详细信息:

这是我的 JConsole VM 摘要输出: 任何人都可以帮助我找出可能是什么问题？你知道，GC“PS MarkSweep”和“PS ​​SCavenge”是我的服务器 JVM 的默认 GC。

谢谢。

---

我发现一个很奇怪的现象:从昨天18:00到今天09:00这15个小时里，“PS Old Gen”上的GC好像从来没有发生过，这使得old generation占用的内存越来越多越来越大，我刚刚手动点击了“Perform GC”按钮，看来这个GC相当有效，回收了很多内存。但是为什么老年代GC这么长时间都没有自动发生呢？可以看到在昨天18:00之前，老年代GC是正常工作的。

Answer 1

假设你在取jmap的时候没有加选项-histo:live，会导致取报告时有garbage + live objects，指的是当你手动点击“Perform GC”时发生的memory drop "按钮，我怀疑应用程序没有内存泄漏，但从年轻代到老代的对象提升率不佳。最终老一代将被填满并运行完整的 GC，结果应用程序无响应。

如果我的假设是正确的，我认为你的策略应该是尽量减少将对象提升到老一代。而不是担心如何清除更昂贵的老一代。引用您提到的以下评论，我认为您的应用程序的内存占用量较小(< 0.5G )相对于最大分配内存 7G 。

"All my data-intensive variables are defined in method. When method returned , these variables should be reclaimed, right?"

所以你能做的事情很少。

• 调整应用程序以最小化事务的响应时间，以便对象在提升到老一代之前被垃圾收集

• 增加年轻一代的规模。既然你有大约 7 GB 的空间可以玩，为什么不一开始就给 Young Gen 分配大约 2 - 3 GB 的空间(即 -XX:NewSize=2g )。较大的 New Size 会降低 PCSacavenge(年轻集合)的频率，并会降低 Activity 对象的老化速度。

• 然后开始调整 -XX:MaxTenuringThreshold=n 。您可以使用 -XX:+PrintTenuringDistribution 使用 gc.log。调整幸存者比率 -XX:SurvivorRatio=n。请注意，默认情况下 -XX:+UseAdaptiveSizePolicy 处于启用状态，这将动态改变 Survivor Ratio 的初始大小。或者，您可以跳过调整幸存者比率的大小，让 AdaptiveSizePolicy 来完成这项工作。但我不是 AdaptiveSizePolicy 的忠实粉丝。

• 与 AdaptiveSizePolicy 一起，您可以使用 -XX:MaxGCPauseMillis=n 以向垃圾收集器提供有关清除老一代时您在应用程序中预期的暂停的指示。通过这种方式，收集器将尝试通过不等到有太多工作要做来实现 MaxGCPauseMillis。

• 或者您可以切换到 CMS 收集器，它是为处理此类响应时间问题而构建的。

好吧，我认为如果前两个步骤解决了您的问题，那么您可以将其余的放在一边。您不能通过添加一些额外的东西来破坏运行良好的应用程序。重要的是您必须逐步调整 GC。