解决fullgc_一些长时间GC停顿问题的排查及解决办法

写在前面：2020年面试必备的Java后端进阶面试题总结了一份复习指南在Github上，内容详细，图文并茂，有需要学习的朋友可以Star一下！

GitHub地址：abel-max/Java-Study-Note

对于许多企业级应用，尤其是OLTP应用来说，长暂停很可能导致服务超时，而对这些运行在JVM上的应用来说，垃圾回收（GC）可能是长暂停最主要的原因。本文将描述一些可能碰到GC长暂停的不同场景，以及说明我们如何排查和解决这些GC停顿的问题。

下面是一些应用在运行时，可能导致GC长暂停的不同场景。

1. 碎片化

这个绝对要排在第一位。因为，正是因为碎片化问题--CMS最致命的缺陷，导致这个统治了OLAP系统十多年的垃圾回收器直接退出历史舞台（CMS已经是deprecated，未来版本会被移除，请珍惜那些配置了CMS的JVM吧），面对G1以及最新的ZGC，天生残(碎)缺(片)的CMS毫无还手之力。

对于CMS，由于老年代的碎片化问题，在YGC时可能碰到晋升失败（promotion failures，即使老年代还有足够多有效的空间，但是仍然可能导致分配失败，因为没有足够连续的空间），从而触发Concurrent Mode Failure，发生会完全STW的FullGC。FullGC相比CMS这种并发模式的GC需要更长的停顿时间才能完成垃圾回收工作，这绝对是Java应用最大的灾难之一。

为什么CMS场景下会有碎片化问题？由于CMS在老年代回收时，采用的是标记清理（Mark-Sweep）算法，它在垃圾回收时并不会压缩堆，日积月累，导致老年代的碎片化问题会越来越严重，直到发生单线程的Mark-Sweep-Compact GC，即FullGC，会完全STW。如果堆比较大的话，STW的时间可能需要好几秒，甚至十多秒，几十秒都有可能。

接下来的cms gc日志，由于碎片率非常高，从而导致promotion failure，然后发生concurrent mode failure，触发的FullGC总计花了17.1365396秒才完成：

{Heap before GC invocations=7430 (full 24):

parnew generation total 134400K, used 121348K[0x53000000, 0x5c600000, 0x5c600000)

eden space 115200K, 99% used [0x53000000, 0x5a07e738, 0x5a080000)

from space 19200K, 32% used [0x5a080000, 0x5a682cc0, 0x5b340000)

to space 19200K, 0% used [0x5b340000, 0x5b340000, 0x5c600000)

concurrent mark-sweep generation total 2099200K, used 1694466K [0x5c600000, 0xdc800000, 0xdc800000)

concurrent-mark-sweep perm gen total 409600K, used 186942K [0xdc800000, 0xf5800000, 0xfbc00000)

10628.167: [GC Before GC:

Statistics for BinaryTreeDictionary:

----