Java垃圾收集器G1GC花费很长时间来处理'Object Copy'（撤离暂停）

本文介绍了Java垃圾收集器G1GC花费很长时间来处理'Object Copy'（撤离暂停）的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 我不是Java newby，但我只知道一点垃圾收集。现在我想用一些实际的经验来改变这一点。我的目标是延迟小于0.3秒，或者在极端情况下，0.5也可以。 我有一个应用程序，带-Xmx50gb（-Xms50gb），并设置其他以下GC选项： -XX：+ UseG1GC -Xloggc：somewhere.gc.log -XX：+ PrintGCDateStamps 但是现在我偶尔会因为垃圾回收而在5秒内停留很长时间，尽管似乎有足够的内存可用。我发现的一个原因是： $ p $ [GC暂停（G1撤离暂停）（年轻）42G-> 40G（48G），5.9409662为什么GCG1仍然在为此做一个停止世界？ （或者至少我看到它正好在这个时候停止了我的应用程序），并且为什么它会做这样的负面清除，如果它不是真的需要，因为有12％的可用RAM是免费的。此外，我认为 -XX：MaxGCPauseMillis 的默认值是200毫秒，为什么这个值超过了29倍甚至50倍（见下文）？ 延迟的另一个原因是： [GC暂停（元数据GC阈值）（年轻）（初始标记）40G-> 39G（48G），10.4667233秒] 这可能会通过这个答案来解决 只是增加元数据空间 -XX：MetaspaceSize = 100M BTW：使用JSE 1.8.0_91-b14 更新：这类活动的详细GC记录 2016-08-12T09：20：31.589 + 0200：1178.312：[GC暂停（G1撤退暂停）（年轻）1178.312：[G1人机工程学（CSet构造）开始选择CSet，_pending_cards：3159，预测基准时间：1.52 ms ，剩余时间：198.48毫秒，目标暂停时间：200.00毫秒] 1178.312：[G1人机工程学（CSet Construction）将年轻区域添加到CSet，eden：136个区域，幸存者：20个区域，预测年轻区域时间：1924.75毫秒] 1178.312：[G1人机工程学（CSet Construction）完成选择CSet，eden：136个地区，幸存者：20个地区，旧地区：0个地区，预计暂停时间：1926.27毫秒，目标暂停时间：200.00毫秒] 1185.330 ：[G1人体工学（堆大小）尝试堆扩展，原因：在GC之后最近的GC开销高于阈值，最近的GC开销：21.83％，阈值：10.00 ％，未提交：0字节，计算扩展量：0字节（20.00％）] 1185.330：[G1人机工程学（并发循环）不要求并发循环启动，理由：仍然做混合收集，占用：42580574208字节，请求：0字节，阈值：23592960000字节（45.00％），来源：GC结束] 1185.330：[G1人机工程学（混合GC）不启动混合GC，原因：可回收百分比未超过阈值，候选旧区域： 1区域，可回收：3381416字节（0.01％），阈值：5.00％] ，7.0181903秒] [并行时间：6991.8毫秒，GC工作人员：10] [GC Worker Start ms）：Min：1178312.6，Avg：1178312.8，Max：1178312.9，Diff：0.2] [Ext Root Scanning（ms）：Min：1.1，Avg：1.5，Max：2.3，Diff：1.2，Sum：15.0 ] [更新RS（ms）：最小值：0.0，平均值：0.3，最大值：1.3，差值：1.3，总和值：3.4] [已处理的缓冲区：最小值：0，平均值：2.1， 5，Diff：5，Sum：21] [Scan RS（ms）：Min：0.0，Avg：0.0，Max：0.1， （ms）：Min：0.0，Avg：0.2，Max：0.4，Diff：0.4，Sum：1.7] [对象复制（ms） ：Min：6964.1，Avg：6973.0，Max：6989.5，Diff：25.3，Sum：69730.4] [终止（ms）：Min：0.0，Avg：16.4，Max：25.3，Diff：25.3，Sum：164.4 ] [终止尝试次数：最小值：1，平均值：3.2，最大值：13，区别：12，总和值：32] [GC Worker Other（ms）：Min：0.0，Avg：0.0，Max [GC Worker Total（ms）：Min：6991.5，Avg：6991.6，Max：6991.7，Diff：0.2，Sum：69915.5] [GC Worker：0.0，Diff：0.0，Sum：0.2] [Code Root Fixup：0.1 ms] [代码根净化：0.0 ms] [代码根修正：0.1 ms]最小值：1185304.3，平均值：1185304.3，最大值：1185304.3， [其他：26.0 ms] [选择CSet：0.0 ms] [Ref Proc：25.3 ms] [Ref Enq：0.1 ms] $ [Humongous Register：0.2 ms] [Humongous Reclaim：0.0 ms] [Free CSet：0.2 ms] [Eden：2176.0M（2176.0M） - > 0.0B（2176.0M）幸存者：320.0M-> 320.0M堆：40.6G（48.8G） - > 40.0G（48.8G）] [Times：user = 0.55 sys = 46.58，real = 7.02 secs] 阅读 here 关于它：复制（停止世界事件） - 这些是停止世界暂停将真人物体撤离或复制到新的未使用地区。这可以通过记录为[GC暂停（年轻）]的年轻一代地区来完成。或者同时记录为[GC暂停（混合）]的年轻和老一代地区。 为什么GCG1仍然在为这个停止世界？ 由于G1不是 pauseless 收藏夹，它只是一个 em> collector。这是，但它只是一个目标，而不是保证。许多事情可能导致它无法实现这一目标。不管怎样，GC调整的过程始于启用详细的GC日志记录，通过 p> -Xloggc：< gc日志文件的路径> -XX：+ PrintAdaptiveSizePolicy -XX：+ PrintGCDateStamps -XX：+ PrintGCTimeStamps -XX：+ PrintGCDetails ，然后通过 GCViewer 获得总体概述，然后返回到阅读单个日志条目（有关此主题的许多答案/博客文章）找出可能导致最坏行为的原因。根据原因，可以尝试各种补救措施。 对于如何追踪垃圾收集器的一般理解以及G1对于避免货物查询是必要的。如果这实际上是原因，那么当前的虚拟机有一些实验选项可以更快地收回它们。 / p> Because G1 is not a pauseless collector, it is just a low-pause collector.It is, but it's just a goal, not a guarantee. Many things can cause it to fail to meet that goal. You got a fairly large heap, this makes things more difficult, i.e. failures are easier to provoke.Anyway, the GC tuning journey starts with enabling verbose GC logging via-Xloggc:<path to gc log file>-XX:+PrintAdaptiveSizePolicy-XX:+PrintGCDateStamps-XX:+PrintGCTimeStamps-XX:+PrintGCDetailsand then running the resulting log through GCViewer to get a general overview and then going back to reading individual log entries (there are many answers/blog posts on this topic) to figure out what might be causing the worst behavior. Depending on the cause various remedies can be tried.Some general understanding of how tracing garbage collectors work in general and G1 will be necessary to avoid cargo-culting.If that actually is the cause then current VMs have some experimental options to reclaim them sooner.This means it's spends most of the time in the kernel when doing something that should mostly consist of memory accesses and not system calls. So swap activity or transparent huge pages are likely suspects. 这篇关于Java垃圾收集器G1GC花费很长时间来处理'Object Copy'（撤离暂停）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！