案例背景

应用每次产生Full GC，持续的时间非常长，大概需要20多秒才能完成。那么会产生一个报警，但是一开始只是偶尔一次，我们也没有注意，随着时间越来越长，每周就会产生一次Full GC，时间都是20多秒。这种情况下，我们不得不去解决一下。

机器配置

机器是一个4C 8G的配置，但是老年代分配的内存分配了6G，其他都是中规中矩的操作。通过开启GC日志寻找问题，结合机器的各种指标（CPU、内存、磁盘、线程等等），这些是由监控工具来产生。没有的可以通过普罗米修斯等等一些东西来看。

问题发现

每次只要产生FullGC的时候，CPU有上升，内存有上升，但是内存的SWAP区内存有下降。

【补充】：
SWAP交换分区：通常被称为交换分区，这是一块特殊的硬盘空间，即当物理内存不够用的时候，操作系统会从物理内存中取出一部分暂时不用的数据，放在交换分区中，从而为当前运行的程序腾出足够的内存空间。

突破点

难道JVM会用到SWAP，SWAP会导致回收缓慢？
具体来看SWAP被程序使用的情况，随着内存的上升，JAVA使用了300多M的SWAP。OOM发生问题的时候，OCS（开放缓存服务）发现内存不足时，会把内存中暂时不用的数据交换出去，放到SWAP区中。这个过程就称为SWAP-OUT。当某个进程又需要这个数据，且又发现内存中有的时候，它就会从SWAP区将其交换回来。这个就是内存与SWAP进行交换的一个过程。

尝试解决问题

发现这个问题之后，抽查了所有发生Full GC的机器，都是SWAP区上升，内存下降。那么这时候我们先把SWAP区关掉，尝试下看看会不会产生问题。通过修改操作系统的VM参数去禁用SWAP, 然后再启动测试，发现问题得到解决。

只要我们将SWAP关闭或者释放，那么我们的FullGC立刻进行了一个完完全全的回收而且还非常快。也就是我们所有需要回收的东西都在内存中。这个时候，我们就相当于把内存中的FullGC时间20秒一下降到了100ms。SWAP区不再使用，并且内存也够用。

所以最终FullGC整体时间偏长的问题得到了解决。

【补充】：
Full GC指的是针对新生代、老年代、永久代的全体内存空间的垃圾回收，所以称之为Full GC。

参考资料：JVM实战调优案例，面试可吹！