最近，我的服务器Full GC通常很长（大约1秒）。我发现ParNew GC处于CMS最终备注期。 ParNew的系统时间通常很长。据我所知，sys时间是内核模式的使用时间（例如：io），但该服务器使用swap在那时为零。有人可以解释吗？
2019-12-07T09:49:42.644+0800: 54818.811: [GC (CMS Final Remark) [YG occupancy: 1044459 K (2048000 K)]2019-12-07T09:49:42.645+0800: 54818.812: [GC (CMS Final Remark) 2019-12-07T09:49:42.648+0800: 54818.815: [ParNew: 1044459K->47633K(2048000K), 0.8381239 secs] 4333652K->3341991K(6144000K), 0.8445423 secs] [Times: user=0.35 sys=0.83, real=0.85 secs]
2019-12-07T09:49:43.491+0800: 54819.658: [Rescan (parallel) , 0.0302395 secs]2019-12-07T09:49:43.522+0800: 54819.688: [weak refs processing, 0.0067316 secs]2019-12-07T09:49:43.528+0800: 54819.695: [class unloading, 0.0801524 secs]2019-12-07T09:49:43.608+0800: 54819.775: [scrub symbol table, 0.0134738 secs]2019-12-07T09:49:43.622+0800: 54819.789: [scrub string table, 0.0034579 secs][1 CMS-remark: 3294357K(4096000K)] 3341991K(6144000K), 0.9888975 secs] [Times: user=0.69 sys=0.85, real=0.99 secs]
答案 0 :(得分：0)
这可能是由于其他内核任务，例如物理页碎片整理（用于THP或NUMA优化）。该数字仅是您进行调查的起点，而不是特定原因。您可以尝试查看内核统计信息，或者使用perf对应用程序+内核堆栈进行采样，以进行进一步调查。
旁注：重新扫描不是完整的GC，它是CMS老式GC周期的一部分。完整的GC仅作为备用措施。