时间戳

首页 > 解决方案 > gc log是minor gc还是full gc

garbage-collection - gc log是minor gc还是full gc

问题描述

这是我的演示应用程序的 jvm gc 日志：

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(Allocation Failure)，因此似乎是由 eden 空间的分配失败引起的小 gc。但是，日志详细信息包含 CMS 和 Metaspace 信息，这使其类似于 Full GC。

那么谁能告诉第 4 行和第 5 行是 Minor GC（young gc）还是 Full GC（young+tenured+metaspace）？

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

如果它们是完整的 gc，那么导致完整 gc 的原因是什么？

标签： garbage-collectionjvm

解决方案

很难从您发布的内容中明确地说出，但这里有更多关于 GC 工作原理的详细信息。

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

CMS 主要是并发的，即收集的某些阶段（并发标记、预清理、清扫和重置）可以在应用程序线程运行时发生。初始标记阶段是 stop-the-world，通常由次要 GC 触发，因此直接发生在次要 GC 之后。这可能是您在此处观察到的，因此第 4 行和第 5 行将这两个事件一起记录（次要 GC 和触发 CMS 初始标记阶段）。

推荐阅读