java为什么在CMS的最后一句话中使用ParNew，而sys的时间这么长？

Question

最近，我的服务器满GC通常很长（约1秒）。我发现ParNew GC处于CMS最终评论期。ParNew的系统时间通常很长。据我所知，sys time是内核模式使用时间（例如：io），但这个服务器使用交换在当时是零。有人能解释一下吗

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]

Answer 1

这可能是由于其他内核任务，例如物理页面碎片整理（用于THPs或NUMA优化）。这个数字只是给你一个调查的起点，而不是一个具体的原因。您可以尝试查看内核统计信息，或者使用perf对应用程序+内核堆栈进行采样，以进一步调查

旁注：重新扫描不是一个完整的GC，它是CMS旧一代GC循环的一部分。完整的地面军事系统只能作为一种后备措施