Serial
Serial是最基本、发展历史最悠久的收集器。在JDK 1.3.1之前是JAVA虚拟机新生代收集的唯一选择
新生代：Serial，采用复制算法。
老年代：Serial Old，采用标记整理算法
参数：
-XX:+UseSerialGC，新生代、老年代都会使用串行回收器。
特点：
- 在进行垃圾收集时，必须
暂停其他所有工作线程; -
单线程。“单线程”并不仅仅说明它只会使用一个CPU或一个收集线程去完成垃圾收集工作； - 简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，没有线程交互的开销，专心做GC，自然可以获得最高的单线程效率。
- Serial收集器对于运行在client模式下的应用是一个很好的选择（到目前为止，它依然是虚拟机运行在
client模式下的默认新生代收集器）
ParNew
ParNew收集器其实就是Serial收集器的多线程版本。
新生代：ParNew，采用复制算法
老年代：不可用
参数：
-XX:+UseParNewGC 新生代开启ParNew收集器+老年代串行
-XX:ParallelGCThreads 设置并行收集线程数量
特点：
- 在进行垃圾收集时，必须
暂停其他所有工作线程; -
并行多线程，其余的行为、特点和Serial收集器一样，两个收集器共用了许多代码； - 指定使用CMS后，会默认使用ParNew作为新生代收集（-XX:+UseConcMarkSweepGC）；
- 在
Server模式下，ParNew收集器是一个非常重要的收集器，因为除Serial外，目前只有它能与CMS收集器配合工作； - 多条GC线程并行垃圾清理，速度比Serial有一定的提升。单个CPU环境中，存在线程交互开销，不会比Serail收集器有更好的效果。
Parallel Scavenge
新生代多线程并行收集器
新生代：Parallel Scavenge，采用复制算法
老年代：Parallel Old，才用标记整理算法
参数：
-XX:+UseParallelGC 使用Parallel收集器+ 老年代串行
-XX:+UseParallelOldGC 新生代和老年代都使用并行收集器
-XX:GCTimeRadio 设置吞吐量大小
-XX:MaxGCPauseMillis 设置最大GC停顿时间
-XX:+UseAdaptiveSizePolicy 开启GC 自适应的调节策略。
特点：
- 在进行垃圾收集时，必须
暂停其他所有工作线程; -
并行多线程。 - 追求高
吞吐量。CMS等收集器的关注点更多的是用户线程的停顿时间（提高用户体验），而Parallel Scavenge关注的是吞吐量（用户线程时间/(用户线程时间+GC线程时间)）。 - 在
server模式下，默认采用Parallel Scavenge收集器 -
自适应的调节策略。只要设置最大堆(-Xmx)和MaxGCPauseMillis或GCTimeRadio,收集器会自动调整新生代的大小、Eden和Survior的比例、对象进入老年代的年龄,以最大程度上接近我们设置的MaxGCPauseMillis或GCTimeRadio
CMS
以最短回收停顿时间为目标的多线程并发收集器
新生代：不可用
老年代：Concurrent Mark Sweep，采用标记清除算法
参数：
-XX:+UseConcMarkSweepGC 开启CMS收集器
-XX:+ UseCMSCompactAtFullCollection 默认开启。并发收集顶不住进行Full GC后（CMS并发GC不是“full GC”），进行一次碎片整理。整理过程是独占的，会引起停顿时间变长
-XX:CMSFullGCsBeforeCompaction 在上一次压缩后，再执行多少次不压缩的full GC后，才会做压缩。默认是0，也就是在默认配置下每次CMS GC顶不住了而要转入full GC的时候都会做压缩
-XX:CMSInitiatingOccupancyFraction 内存占用率达到多少的时候开始CMS收集
-XX:+UseCMSInitiatingOccupancyOnly 设定回收阈值(CMSInitiatingOccupancyFraction指定),如果不指定,JVM仅在第一次使用设定值,后续则自动调整.
-XX:ParallelCMSThreads：并行收集时的线程数
步骤：
- 初始标记
暂停所有的其他线程，初始标记仅仅标记GC Roots能直接关联到的对象，速度很快 - 并发标记
进行GC Roots Tracing的过程 - 重新标记
暂停所有的其他线程，修正并发标记期间用户程序继续运行产生变动的部分对象的标记记录（采用多线程并行执行来提升效率） - 并发清除
开启用户线程，同时GC线程开始对为标记的区域做清扫，回收所有的垃圾对象
特点：
- 初始标记、重新标记两个阶段必须
暂停其他所有工作线程; -
并发多线程。 - 追求高
响应速度。希望系统停顿时间最短，以给用户带来较好的体验
缺点：
-
CPU资源敏感。回收线程占用一定线程资源，吞吐量下降，默认回收线程数是(CPU数+3)/4。 - 无法处理
浮动垃圾。在并发清除时，用户线程新产生的垃圾，称为浮动垃圾。可能出现“Concurrent Mode Failure”而导致另一次Full GC。因此CMS不能像其他收集器那样等到老年代几乎填满再进行收集，需要预留一部分空间提供并发收集期间程序运行使用。JDK1.5时，空间使用68%后CMS会被激活（JDK1.6后为92%）。如果收集期间内存不足，则会出现“Concurrent Mode Failure”失败，临时启用Serial Old收集器。 -
空间碎片。CMS是基于“标记+清除”算法来回收老年代对象的，因此长时间运行后会产生大量的空间碎片问题。
内存模型
Young : Old = 1:2
Eden区：Survivor区 = 8:1
收集过程：
- 对象首先在Eden中分配
- 如果Eden区空间不足了，进行一次Minor GC，把Eden区的存活对象转移到其中一个Survivor区（称为From区），非存活对象进行清理，然后在Eden区给新创建的对象分配空间
- 随着对象的增多，Eden区空间又不足了，进行一次Minor GC，把Eden区和From区的存活对象转移到另一个Survivor区（称为To区），非存活对象进行清理，然后From变成To，To变成From，然后在Eden区给新创建的对象分配空间
- 进入老年代
4.1 To区空间不足，将存活对象移入老年代
4.2 大对象直接进入老年代（PretenureSizeThreshold指定，默认3M）
4.3 长期存活对象移入老年代，每经过一次Minor GC年龄加1。年龄增加到一定程度(MaxTenuringThreshold指定，默认15)移入老年代
4.4 From空间中，相同年龄所有对象的大小总和大于From空间总和的一半 - 如果进入老年代时，老年代空间不足进行Full GC。
参数：
-XX:PretenureSizeThreshold 大于这个值得对象直接进入老年代，避免新生代发生大量复制
-XX:MaxTenuringThreshold 晋升老年代的年龄
-XX:MetaspaceSize Metaspace扩容时触发FullGC的初始化阈值
-Xms 初始分配的堆内存，默认是物理内存的1/64
-Xmx最大分配的堆内存，默认是物理内存的1/4
