Java 了解G1垃圾收集器在特定GC阶段长时间暂停的原因

我试图在服务器端JVM中使用G1型垃圾收集器，一般来说，gc暂停时间很短，但偶尔会出现问题

我在下面给出了其中一个长暂停的中断，总时间为27.79秒，其中23.923秒用于[Other:23923.6 ms]中Other指示的阶段

如果有人能告诉我如何进一步理解这一特定GC循环阶段的原因，或者我如何改善GC状况，这似乎在大多数情况下都会发生，我将非常感激

[GC pause (G1 Evacuation Pause) (young)
Desired survivor size 524288 bytes, new threshold 0 (max 0)
, 25.0957244 secs]
     [Parallel Time: 1087.3 ms, GC Workers: 4]
   [GC Worker Start (ms): Min: 5050906.2, Avg: 5050906.4, Max: 5050906.5, Diff: 0.2]
   [Ext Root Scanning (ms): Min: 1.0, Avg: 190.7, Max: 415.2, Diff: 414.2, Sum: 762.8]
   [Update RS (ms): Min: 308.9, Avg: 565.0, Max: 650.3, Diff: 341.4, Sum: 2259.8]
      [Processed Buffers: Min: 56, Avg: 69.2, Max: 82, Diff: 26, Sum: 277]
   [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]
   [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
   [Object Copy (ms): Min: 0.8, Avg: 310.7, Max: 414.8, Diff: 414.0, Sum: 1242.9]
   [Termination (ms): Min: 0.0, Avg: 15.6, Max: 20.8, Diff: 20.8, Sum: 62.4]
      [Termination Attempts: Min: 1, Avg: 1.0, Max: 1, Diff: 0, Sum: 4]
   [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]
   [GC Worker Total (ms): Min: 1066.9, Avg: 1082.0, Max: 1087.2, Diff: 20.3, Sum: 4328.2]
   [GC Worker End (ms): Min: 5051973.4, Avg: 5051988.4, Max: 5051993.4, Diff: 20.0]
[Code Root Fixup: 0.2 ms]
[Code Root Purge: 0.0 ms]
[String Dedup Fixup: 2.0 ms, GC Workers: 4]
   [Queue Fixup (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
   [Table Fixup (ms): Min: 0.1, Avg: 0.9, Max: 1.9, Diff: 1.8, Sum: 3.7]
[Clear CT: 82.6 ms]
[Other: 23923.6 ms]
   [Choose CSet: 0.0 ms]
   [Ref Proc: 415.2 ms]
   [Ref Enq: 0.0 ms]
   [Redirty Cards: 0.1 ms]
   [Humongous Register: 0.1 ms]
   [Humongous Reclaim: 0.1 ms]
   [Free CSet: 0.2 ms]
[Eden: 119.0M(119.0M)->0.0B(133.0M) Survivors: 0.0B->0.0B Heap: 572.3M(2391.0M)->456.2M(2666.0M)]
[Times: user=0.00 sys=1.29, real=27.79 secs] 

[次数：用户=0.00系统=1.29，实际=27.79秒]

它在垃圾收集上几乎不花费CPU周期，在内核中的所有时间，甚至更多的挂机时间，这表明进程在内核中被阻塞了。主要嫌疑犯是您的系统交换

其他潜在原因：

被其他进程占用CPU的系统 IO被闲置硬盘阻塞，必须加速 超过配额-特别是在集装箱或虚拟机环境中 THP压缩-虽然这不太可能，因为它通常通过更高的内核负载来体现

---

您还可以尝试使用-XX:G1LogLevel=fine/finer/finest来增加GC日志的详细程度，看看这是否指向某个特定的问题，但症状指向系统级问题，而不是特定于VM的问题。

感谢您的回复。如果您知道的话，在那个时候观察系统交换程度的最佳方法是什么？vmstat。对于一般的系统管理问题，您可能应该询问超级用户。com@Roshan交换太糟糕了，很可能另一个原因是CPU忙于其他工作。为进程获取更多内存或减小其大小。@maaartinus但它似乎还没有真正缺少内存，是吗？它显示了堆：572.3M2391.0M->456.2M2666.0M，这意味着它使用了当前2GB堆的1/4-15。它只分配了4GB中的2GB。或者，你的意思是别的？@maaartinus下次长GC暂停发生时，我会检查交换性，100%确定，尽管我非常确定可用内存不是问题。我尝试在15GB的机器上使用2-4GB，并且没有任何其他繁重的进程在运行。