2. GC时操作系统的活动
当发生GC时，一些操作系统的活动，比如swap，可能导致GC停顿时间更长，这些停顿可能是几秒，甚至几十秒级别。
如果你的系统配置了允许使用swap空间，操作系统可能把JVM进程的非活动内存页移到swap空间，从而释放内存给当前活动进程（可能是操作系统上其他进程，取决于系统调度）。Swapping由于需要访问磁盘，所以相比物理内存，它的速度慢的令人发指。所以，如果在GC的时候，系统正好需要执行Swapping，那么GC停顿的时间一定会非常非常非常恐怖。
下面是一段持续了29.48秒的YGC日志：
最后一行[Times: user=915.56, sys=6.35, real=29.48 secs]中real就是YGC时应用真实的停顿时间。
发生YGC的这个时间点，vmstat命令输出结果如下：
YGC总计花了29秒才完成。vmstat命令输出结果表示，可用swap空间在这个时间段减少了600m。这就意味着，在GC的时候，内存中的一些页被移到了swap空间，这个内存页不一定属于JVM进程，可能是其他操作系统上的其他进程。
从上面可以看出，操作系统上可用物理内容不足以运行系统上所有的进程，解决办法就是尽可能运行更少的进程，增加RAM从而提升系统的物理内存。在这个例子中，Old区有9G，但是只使用了1.8G（mark-sweep generation total 9437184K, used 1860619K）。我们可以适当的降低Old区的大小以及整个堆的大小，从而减少内存压力，最小化系统上的应用发生swapping的可能。
除了swapping以外，我们也需要监控了解长GC暂停时的任何IO或者网络活动情况等, 可以通过iostat和netstat两个工具来实现. 我们还能通过mpstat查看CPU统计信息，从而弄清楚在GC的时候是否有足够的CPU资源。
3. 堆空间不够
如果应用程序需要的内存比我们执行的Xmx还要大，也会导致频繁的垃圾回收，甚至OOM。由于堆空间不足，对象分配失败，JVM就需要调用GC尝试回收已经分配的空间，但是GC并不能释放更多的空间，从而又回导致GC，进入恶性循环。
应用运行时，频繁的FullGC会引起长时间停顿，在下面这个例子中，Perm空间几乎是满的，并且在Perm区尝试分配内存也都失败了，从而触发FullGC：
同样的，如果在老年代的空间不够的话，也会导致频繁FullGC，这类问题比较好办，给足老年代和永久代，不要做太抠门的人了，嘿嘿。
4. JVM Bug
什么软件都有BUG，JVM也不例外。有时候，GC的长时间停顿就有可能是BUG引起的。例如，下面列举的这些JVM的BUG，就可能导致Java应用在GC时长时间停顿。
