Full GC 频繁发生答案

【问题标题】：Full GC is occurring frequentlyFull GC 频繁发生
【发布时间】：2016-06-02 22:42:36
【问题描述】：

详细日志显示每 7 秒发生一次 Full GC -

], 7.3933980 secs] [Times: user=89.17 sys=1.16, real=7.39 secs] 79959.910：[全GC [PSYOUNGGEN：390144K-> 194442K（451584K）] [1572852K - > 1572852K（1572864K）] 1962798K-> 1767294K（2024448K）[Pspermgen：103569K-> 103569K（103936K），7.9599570秒] [时间：user=95.28 sys=1.09, real=7.96 secs] 79984.776：[全GC [PSYOUNGGEN：390144K-> 196124K（451584K）] [1572864K-> 1572544K（1572864K）] 1962996K-> 1768668K（2024448K）[PSPermgen：103569K-> 103569K（103936K），7.6023130秒] [时间：用户=91.82 系统=1.22，真实=7.60 秒] 80007.996：[PSYOUNGGEN：390144K-> 194969K（451584K）] [帕尔林：157254K-> 1572734K（1572864K）1962688K-> 1767703K（2024448K）[Pspermgen：103569K-> 103569K（103936K），8.0980790秒] [时间：user=98.03 sys=1.28, real=8.10 secs]

我在 Linux 上使用这个 JVM 参数和 Oracle 热点 64 位，RAM 大小为 30688332 KB 和 java 版本 1.7.0_91-

-server -Xmx2048m -Xms2048m -XX:NewRatio=3 -XX:MaxPermSize=512m -XX:+UseParallelGC -Djava.awt.headless=true

jstack 结果显示 -

我尝试将 NewRatio 更改为 2 或 3 并将 Xmx 更改为

详细的 gc 日志显示老年代正在努力重新分配内存。下一步应该是什么？请推荐！

【问题讨论】：

如果您需要更多 RAM，则需要更多 RAM。您的应用程序要么非常消耗内存，要么存在内存泄漏。启动 JVisualVM，分析内存分配，找出它是什么。
第一步始终是生成堆转储并弄清楚发生了什么。
分析您的应用程序，找到分配发生的位置并减少分配。
如果你的机器有 30 GB，默认的 JVM 大小是这个的 1/4。即〜8 GB。由于您已经调低了内存量并且看起来这还不够，我会尝试增加最大大小或根本不设置它。我还会尝试删除 NewRatio 并在再次设置之前设置它的运行方式。注意：您的旧代已满 99.98%。
您的 permgen 看起来不错，因为只使用了 103 MB。

标签： java performance memory-leaks garbage-collection jvm

【解决方案1】：

明智地使用可用资源。

您使用的最大内存为 2048MB，我认为这对于当今的应用程序来说相当少。如果您的应用程序需要更多内存并且您有更多可用内存（我认为您有大约 30GB）那么恕我直言，那么您应该分配它。

尝试这种优化作为最后的手段。我认为您应该尝试将 xmlx 大小加倍，然后比较结果。考虑到系统上没有其他应用程序，将一半的可用系统内存分配给您的应用程序并没有什么坏处。

如果增加内存不起作用（由于内存泄漏），则使用分析器/堆转储和内存分析器或静态代码分析器来分析您的应用程序。

【讨论】：

【解决方案2】：

您的代码是否在任何地方调用 System.gc()？如果是这样，它多久被调用一次？我的代码在完成一项大任务时调用了 gc，但后来的更改意味着它的调用频率比预期的要高得多，导致花费大量时间进行无用的 GC。

简单的解决方法是删除对 System.gc() 的调用并让 JVM 处理它。一个聪明的解决方法是调用一个辅助方法来检查自上次调用 GC 以来的时间，并且只有在足够的时间过去后才调用。这可能不是必需的，因此只需先尝试简单的修复即可。

【讨论】：

最简单的解决方法是使用 JVM 选项 -XX:-DisableExplicitGC 运行，以便在不更改应用程序的情况下忽略这些调用。