为什么GC 异常，大家喜欢让Swap背锅呢

01

—

背景

在公司内部技术群里，经常有人时不时的问到服务某次GC时间突然很高，有什么办法排查。基本上每次都会有人怀疑会不会Swap导致的，先看看Swap，如果真的使用了Swap区域，基本上就会让Swap区域背锅了。

如果JVM堆内内存大于等于系统内存的话，Java进程出现了大量使用Swap区域对GC影响确实比较大。如果发生GC抖动时，系统没有使用Swap区域或者 Java 进程没有使用Swap区域，就能排除Swap原因。

因为我司只对系统使用Swap区域的整体情况做了监控，并未对Java进程使用Swap区域做监控，GC抖动基本上是小概率事件，所以很难从监控做出判断的。

那么其他情况，如何大致判断出来是不是Swap导致的GC异常呢？

首先，我们得了解Swap相关的基本知识。

Swap区域主要解决内部不足的问题，把部分硬盘当做虚拟内存使用。

Swap中最关键的系统参数：vm.swapiness（0-100）， 该参数值越小表示当内存不足时，倾向于通过回收cache区域，而不是把进程内存交换到Swap区域。所以该值应该设置小一点就能减少Swap可能对GC产生的影响，比如我司统一默认设置为1。

Swap内存回收算法使用的是LRU算法，他会标记处活跃页面和非活跃页面，也就是说如果内存一直被使用基本上常驻内存，不会被交换到Swap。

GC的哪些阶段可能受Swap影响

young gc

young gc的特色是较为频繁，基本上每分钟都会多次。young gc主要有两个阶段，一个是扫描阶段、一个是对象复制阶段。 扫描阶段会从 根集合扫描标记 Eden、From中的存活对象，然后对象复制阶段把存活对象copy到To区域中去。

复制阶段： 因为young gc较为频繁就会导致 Eden、From、To区域不太可能被置换到Swap区域，所以 复制阶段不太可能受到Swap区域影响；假设young gc不频繁，那么在刚刚经历了 扫描阶段， Eden、From 也 肯定会在内存中，只有To区域有可能会受到Swap影响。

相比较于复制阶段， 扫描阶段就相对复杂一点。这主要跟根集合有关系，young gc的根集合主要有线程上下文、old区域、Class、JNI引用等，像JNI引用、Class等长时间不使用 有可能被OS置换到Swap。所以该阶段有可能因为Swap影响GC。

cms gc

cms gc主要分为：初始标记、并发标记、并发预清理、重新标记、并发清理等阶段，只有初始标记和重新标记会stop the world，所以我们只需要关注这两个阶段即可。

初始标记：该阶段标记GC Roots能直接关联到的对象。所以该阶段和young gc的扫描阶段类似，也有可能因为Swap影响到GC。

重新标记： 由于在并发标记和并发预清理这个阶段，用户线程和GC 线程并发，假如这个阶段用户线程产生了新的对象，总不能被 GC 掉吧。这个阶段就是为了让这些对象重新标记。在这个阶段访问到的内存一定是之前刚刚访问过的，所以这个阶段不太可能由Swap区域导致GC异常。

04

—

总结

对于CMS GC，如果在remark阶段异常行为而InitialMark是正常的，基本上可以排除Swap导致的GC，young gc在copy阶段异常而Root Scaning正常也基本上可以排除Swap因素。

我想大家喜欢让Swap背锅的原因有两个：

• 对Swap如何影响GC以及可能影响到GC哪些阶段不太了解；

• GC时间异常情况下，确实较难分析和排除；必须要对GC的具体过程，GC工具等有较为深入的了解。