JVM垃圾收集器

HotSpot收集器

一、Serial收集器

特点：stop the world

增是jdk1.3.1之前，新生代收集器的唯一选择，单线程处理，且要求所有用户线程都暂停。

但是并不意味着其就是老而无用的，他也有着独特的优势，简单高效。他依然是在client模式下，新生代默认的收集器。因为其没有线程交互的开销，停顿时间完全可以控制在几十毫秒至一百毫秒

二、ParNew收集器

Serial的多线程版     

三、Parallel Scavenge收集器

四、Serial Old收集器（标记-整理算法）

五、ParNew Old收集器

六、CMS收集器（Concurrent Mark Sweep）

是一种以获取最短回收停顿时间为目标的收集器

收集算法：采用的是标记-清除算法实现

收集步骤：

1. 初始标记（GMS initial mark）
2. 并发标记（GMS concurrent mark）
3. 重新标记（GMS remark）
4. 并发清除（GMS concurrent sweep）

其中初始标记和重新标记仍需要stop the world

GMS收集器无法处理浮动垃圾，可能出现”Concurrent mode failure”失败而导致一次Full GC产生。

原因是GMS清除阶段，用户线程还在运行着，所以不断会有新的垃圾产生，而这一部分垃圾是没有办法在这一次清除，只好留到下一次再清理。也是由于GMS并发清除时，用户线程还在运行着，所以要为用户线程保留足够的内存空间。默认设置下，GMS在老年代使用了68%的空间后激活，如果应用中老年代增涨不是很快，可以适当调高该值：-XX:CMSInitiatingOccupancyFraction

若GMS运行期间，预留的空间满足不了应用程序的需求，就会触发一次”Concurrent mode failure”，这时候虚拟机启动备选方案，临时启用SerialOld收集器来重新进行老年代的垃圾收集。如果-XX:CMSInitiatingOccupancyFraction设置过高，很容易导致Concurrent mode failure，反而降低性能

GMS还有一个缺点：由于GMS采用的是标记清除算法，这意味着每次回收可能产生大量的碎片，导致可能找不到足够大的内存区域分配给大对象，这时不得不提前出发一次Full GC

七、G1收集器（基于标记-整理算法实现）

G1收集器采用标记整理算法实现，也就是不会产生内存碎片

G1将java堆（包括年轻代和老年代）划分为多个大小固定的区域，并且跟踪这些区域的垃圾程度，后台维护一个优先级列表，优先回收垃圾最多的区域