垃圾收集器无法清除垃圾，导致完全频繁的gc

Question

我们将并行gc与1.7.0_71一起使用。

java -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -version
-XX:InitialHeapSize=258222272 -XX:MaxHeapSize=4131556352 -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -XX:+UseCompressedOops -XX:+UseParallelGC 
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)

在适当的负载下，每隔几分钟我们就会在应用程序中看到大量垃圾的产生。次要gc每隔几秒钟触发一次，主要gc每2分钟触发一次。通过分析，我们发现堆中剩余了180万个大小为173K的char数组对象。次要gc无法恢复它们。在获取heapdump时，我们在Eclipe MAT的其余部分中找到了许多对象。MAT直方图显示了许多char数组（它们是呈现为html的），但是无法访问所有传入引用和char数组的gc根的合并路径，但是只有完整的GC才能恢复它们，而较小的GC则无法恢复。当没有引用的对象时，为什么次要GC无法恢复它们？附有Eclipse MAT图片。请查看所有引用均不可用。

有一些对请求对象的引用，通过设置null清除它们。

在修复之前，有对HttpServletRequest对象的悬挂引用。

与该问题相关的所有图像：https : //www.dropbox.com/sh/qgsitzb7x27j8kc/AABoQwR1qPwTPiDtO6B0_Pm7a?dl=0

整体堆

堆直方图视图 现在的问题是

1. 您是否认为这与垃圾收集器有关？我们将JBoss 7.1.1升级到Wildfly 8.2.0.Final。gc策略和JDK版本未更改。为什么gc不能在指向不可访问引用的地方回收内存。

2. 我们可以将XX：NewRatio减小为1。但是，由于全gc经常发生，因此我们不确定这是否会起作用

3. 您认为转用G1 GC会有所帮助吗？吞吐量会降低吗？G1 GC的最佳选择是什么。我们的堆大小-Xms：1024m，-Xmx 2048m Perm gen 512m我们没有看到内存泄漏，没有内存不足错误。附加完整的gc日志输出

   2015-05-10 19:32:41 IST| 459.939: [Full GC [PSYoungGen: 8123K->0K(680960K)] [ParOldGen: 782136K->359065K(766464K)] 790260K->359065K(1447424K) [PSPermGen: 202932K->202930K(441344K)], 1.0738240 secs] [Times: user=3.37 sys=0.01, real=1.07 secs]
   2015-05-10 19:32:42 IST| 462.306: [GC [PSYoungGen: 672768K->10534K(685056K)] 1031833K->369600K(1451520K), 0.0450800 secs] [Times: user=0.15 sys=0.00, real=0.04 secs]
   2015-05-10 19:32:44 IST| 463.641: [GC [PSYoungGen: 682790K->9093K(685568K)] 1041856K->373085K(1452032K), 0.0570820 secs] [Times: user=0.16 sys=0.00, real=0.06 secs]
   2015-05-10 19:32:45 IST| 464.936: [GC [PSYoungGen: 681349K->9812K(686080K)] 1045341K->377511K(1452544K), 0.0439060 secs] [Times: user=0.12 sys=0.00, real=0.04 secs]
   2015-05-10 19:32:46 IST| 466.283: [GC [PSYoungGen: 683092K->10733K(686080K)] 1050791K->383554K(1452544K), 0.0464700 secs] [Times: user=0.14 sys=0.00, real=0.05 secs]
   2015-05-10 19:32:48 IST| 467.659: [GC [PSYoungGen: 684013K->11283K(685568K)] 1056834K->388651K(1452032K), 0.1381130 secs] [Times: user=0.30 sys=0.00, real=0.14 secs]
   2015-05-10 19:32:50 IST| 469.734: [GC [PSYoungGen: 684051K->9652K(686080K)] 1061419K->393759K(1452544K), 0.0466800 secs] [Times: user=0.13 sys=0.00, real=0.05 secs]
   2015-05-10 19:32:51 IST| 471.087: [GC [PSYoungGen: 682420K->11253K(685568K)] 1066527K->400087K(1452032K), 0.0589180 secs] [Times: user=0.11 sys=0.00, real=0.06 secs]
   2015-05-10 19:32:52 IST| 472.325: [GC [PSYoungGen: 684021K->7957K(686080K)] 1072855K->403018K(1452544K), 0.0436140 secs] [Times: user=0.13 sys=0.00, real=0.04 secs]
   2015-05-10 19:32:54 IST| 473.606: [GC [PSYoungGen: 680725K->9177K(685056K)] 1075786K->406493K(1451520K), 0.0524990 secs] [Times: user=0.13 sys=0.00, real=0.05 secs]
   
   2015-05-10 19:34:34 IST| 573.526: [GC [PSYoungGen: 684217K->10956K(686080K)] 1440629K->771626K(1452544K), 0.0416620 secs] [Times:  user=0.14 sys=0.00, real=0.04 secs]
    2015-05-10 19:34:34 IST| 573.568: [Full GC [PSYoungGen: 10956K->0K(686080K)] [ParOldGen: 760670K->364958K(818688K)] 771626K->364958K(1504768K) [PSPermGen: 203069K->203069K(420864K)], 0.8001740 secs] >[Times: user=2.46 sys=0.01, real=0.80 secs]
   2015-05-10 19:34:36 IST| 575.600: [GC [PSYoungGen: 674304K->10465K(686592K)] 1039262K->375423K(1505280K), 0.0410330 secs] [Times: user=0.13 sys=0.00, real=0.04 secs]
   2015-05-10 19:36:35 IST| 694.277: [GC [PSYoungGen: 684413K->9342K(687104K)] 1490469K->820033K(1505792K), 0.2160320 secs] [Times: user=0.55 sys=0.08, real=0.21 secs]
   2015-05-10 19:36:36 IST| 695.664: [GC [PSYoungGen: 684670K->8323K(687104K)] 1495361K->823380K(1505792K), 0.0454050 secs] [Times: user=0.11 sys=0.00, real=0.05 secs]
   2015-05-10 19:36:37 IST| 695.710: [Full GC [PSYoungGen: 8323K->0K(687104K)] [ParOldGen: 815056K->363295K(838144K)] 823380K->363295K(1525248K) [PSPermGen: 203095K->203095K(401920K)], 0.8133080 secs] [Times: user=2.43 sys=0.01, real=0.81 secs]
   2015-05-10 19:36:38 IST| 697.669: [GC [PSYoungGen: 675328K->10586K(686592K)] 1038623K->373882K(1524736K), 0.0436000 secs] [Times: user=0.13 sys=0.00, real=0.04 secs]
   ...
   ....
   

Answer 1

为什么在没有引用对象的情况下，minor GC 无法回收它们？

很可能是因为他们属于老一代。Minor GC 仅处理年轻代中无法访问的对象。

当对象的寿命比由于保有权而可以保留在年轻代中的时间长时，通常会发生这种情况。例如，如果涉及将结果保留一段时间的缓存，或者当请求的生存期超过GC interval * tenuring threshold.

-XX:+PrintTenuringDistribution可能会提供丰富的信息。

首先，您可以尝试通过简单地提供暂停时间目标-XX:MaxGCPauseMillis=...。ParallelGC或许能够满足它。

如果这没有帮助，您可以重构代码以减少对象生命周期或降低分配率以减少次要 GC 的频率。

请注意，最重要的 ParallelGC 是吞吐量收集器，就 CPU 周期而言，它比并发收集器更高效，但它通常无法满足如此低的暂停时间目标。

您认为转向 G1 GC 有帮助吗？

如果您很担心暂停时间。您可能还想尝试 CMS。

如果您想尝试 G1，您可能应该切换到 java 8，它的启发式方法随着时间的推移已经有了很大的改进，并且仍在成熟中。

吞吐量会下降吗？

可能。这取决于是否有空闲的 CPU 容量以及您如何定义/测量吞吐量。即使在不太有利的情况下，下降幅度也可能不会很大。

G1 GC 有哪些最佳选项。

G1 应该能够自我调整（超出也适用于 ParallelGC 的用户提供的暂停和吞吐量目标）。因此，只需启用它，看看它是否提供可接受的性能。