原文地址：https://mp.weixin.qq.com/s/fP--JJnkTR92NWdZtdEgqQ
作者：阿飞的博客
对于许多企业级应用，尤其是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秒才完成：
