Java Metaspace全GC

Question

我和G1GC有一些问题。

2400.241: [GC concurrent-root-region-scan-start]
2400.241: [Full GC (Metadata GC Threshold) 2400.252: [GC concurrent-root-region-scan-end, 0.0101404 secs]
2400.252: [GC concurrent-mark-start]
 1151M->603M(4356M), 2.6980537 secs]
   [Eden: 0.0B(2558.0M)->0.0B(2613.0M) Survivors: 55.0M->0.0B Heap: 1151.7M(4356.0M)->603.6M(4356.0M)], [Metaspace: 259187K->92248K(1034240K)]
 [Times: user=3.92 sys=0.00, real=2.70 secs] 

这需要很长时间，每20-30分钟就有一个完整的gc由metaspace触发。我是这样配置的：

  "-XX:MaxMetaspaceSize=768M",
  "-XX:MetaspaceSize=256M"

但每当它达到256米时，它就会触发一个完整的gc。当它达到这个第一个高水位标志，它不应该使它更大，下次直到最大的大小？另外，metaspace上的完整gc会触发旧的gc吗？我在某个地方读过它，但我不确定。这使得p99响应时间比我预期的要高。

Answer 1

根据Triggering of gc on Metaspace memory in java 8，为了减少元空间的使用，需要使用完整的GC。

我的理解是，metaspace本身并不是垃圾收集。相反，在普通堆中有一些对象，这些对象包含对metaspace对象的特殊引用。当GC收集对象时，释放相应的metaspace对象。(从概念上讲，它类似于终结，其中终结器是free、-ing、metaspace对象。)

当它达到这个第一个高水位标志，它不应该使它更大，下次直到最大的大小？

显然不是。HotSpot收集器的正常策略如下：

1. 分配对象，直到达到当前堆限制
2. 运行收集器
3. 看看回收了多少空间，如果需要的话，增加(或减少)堆大小。

这里似乎也采用了同样的策略。而完整的GC导致足够多的元空间被回收，从而决定它不需要展开metaspace。

这方面的一个创可贴是尝试将-XX:MetaspaceSize和-XX:MaxMetaspaceSize设置为相同的值，但这只会降低整个GC的频率。

一个真正的解决方案是找出消耗元空间的是什么，并修复它。