gc日志是次要gc或完整gc

Question

下面是我的演示应用程序的jvm日志：

CommandLine flags: -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:CompressedClassSpaceSize=44040192 -XX:+DisableExplicitGC -XX:InitialHeapSize=10485760 -XX:LargePageSizeInBytes=134217728 -XX:MaxHeapSize=10485760 -XX:MaxMetaspaceSize=52428800 -XX:MaxNewSize=5242880 -XX:MaxTenuringThreshold=6 -XX:MetaspaceSize=52428800 -XX:NewSize=5242880 -XX:OldPLABSize=16 -XX:-OmitStackTraceInFastThrow -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:ThreadStackSize=256 -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseFastAccessorMethods -XX:+UseParNewGC 
2019-12-03T21:43:04.462-0800: 0.279: [GC (Allocation Failure) 2019-12-03T21:43:04.462-0800: 0.279: [ParNew: 4048K->512K(4608K), 0.0020396 secs] 4048K->722K(9728K), 0.0021283 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] 
2019-12-03T21:43:04.469-0800: 0.286: [GC (Allocation Failure) 2019-12-03T21:43:04.469-0800: 0.286: [ParNew: 4608K->418K(4608K), 0.0022851 secs] 4818K->3190K(9728K), 0.0023372 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 
2019-12-03T21:43:04.475-0800: 0.291: [GC (Allocation Failure) 2019-12-03T21:43:04.475-0800: 0.291: [ParNew: 4514K->4514K(4608K), 0.0000198 secs]2019-12-03T21:43:04.475-0800: 0.291: [CMS: 2771K->2764K(5120K), 0.0040364 secs] 7286K->2764K(9728K), [Metaspace: 4253K->4253K(1056768K)], 0.0041089 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
2019-12-03T21:43:04.481-0800: 0.297: [GC (Allocation Failure) 2019-12-03T21:43:04.481-0800: 0.297: [ParNew: 4096K->4096K(4608K), 0.0000200 secs]2019-12-03T21:43:04.481-0800: 0.297: [CMS: 2764K->2721K(5120K), 0.0031319 secs] 6860K->2721K(9728K), [Metaspace: 4253K->4253K(1056768K)], 0.0032046 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

一切都在预料之中，除了第4行和第5行。因为它的标题是gc (分配失败)，所以它似乎是由伊甸园空间的分配失败引起的一个小gc。但是，日志详细信息包含CMS和Metaspace信息，这使得它看起来像一个完整的GC。

那么，谁能说出第4行和第5行是次要GC(年轻gc)还是完整GC(young+tenured+metaspace)？

如果它们是次要gc，那么第2行、第3行和第4、5行有什么区别？

如果他们是完全gc，是什么导致了完全gc？

Answer 1

很难从你发布的内容中确切地说出来，但这里有更多关于GC如何工作的细节。

对于CMS，其想法是避免完整的GC。CMS的完整GC发生在占用率和碎片太高而无法使VM轻松地为旧gen中的新对象分配空间时。此时，VM将暂停所有应用程序线程，并执行完全压缩收集，通过将对象移动到内存中的连续位置来消除所有碎片。这不是你在这里看到的。

CMS大部分是并发的，即在应用程序线程运行时，可能会发生收集的某些阶段(并发标记、预清理、清理和重置)。初始标记阶段是stop- The -world，通常由次要GC触发，因此紧跟在次要GC之后。这可能是您在这里观察到的，因此第4行和第5行一起记录了两个事件(次要GC和CMS初始标记阶段的触发)。