JVM之垃圾收集器

1、Serial收集器

新生代的收集器，最早的收集器，单线程的，工作时需要暂停用户线程，会存在卡顿的现象，性能效率不高。是client模式的默认垃圾收集器，对应参数-XX:UseSerialGC

2、ParNew收集器

新生代的收集器，是Serial的多线程版本，Serial和ParNew可以配合CMS共同工作，在使用CMS的时候会默认使用ParNew作为新生代的收集器。

3、Parallel Scavenge收集器

新生代收集器，基于复制算法的并行多线程收集器，侧重于达到一个可控吞吐量，如虚拟机运行100分钟，垃圾收集执行1分钟，是JVM默认的垃圾收集器，则吞吐量为99%。可通过参数-XX:MaxGCPauseMillis，设置一个大于0的毫秒数，虚拟机在执行的时候，尽量不超过这个毫秒数，这个数不是越小越好，值越小GC越频繁，-XX:UseAdaptiveSizePolicy自适应新生代大小策略，默认这个参数是开启的，当这个参数开启之后，就不需要人工指定新生代的大小，Eden和Survivor比例，晋升老年代对象大小等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间来获得最大的吞吐量，这个调整的方式称为垃圾收集的自适应调整策略。使用参数-XX:UseParallelGC。

4、Serial Old收集器

是Serial收集器的老年代版本，采用标记整理算法，可以作为CMS收集器发生失败是的后备预案，在并发收集发生Concurrent Mode Failure时使用。

5、Parallel Old收集器

老年代收集器可以和Parallel Scavenge组合使用，多线程，标记整理算法，1.6开始才提供。在注重吞吐量和CPU资源的情况下可以进行组合使用

6、CMS收集器

多线程老年代收集器，Concurrent Mark Sweep，它是追求最短回收停顿时间为目标的收集器，互联网B/S结构的服务器端特别适合此收集器，垃圾回收会带来STW，所以CMS采取的是垃圾回收线程和系统工作线程尽量同时执行的模式来处理的，基于标记清除算法。运作过程主要分为四个阶段。
第一阶段： 初始标记，stw，标记GCRoots能关联到的对象，这些对象也就是需要存活的对象，这个速度很快。
第二阶段： 并发标记，不会STW，和用户线程并发执行，追踪GCRoots的整个链路，从直接关联对象开始遍历整个对象引用链，这个过程耗时较长，但不需要暂停用户线程，可以与垃圾收集线程一起并发执行。
第三阶段： 重新标记，STW，修正并发标记期间，因为用户线程运行而导致变化的那一部分，这个阶段停顿时间比初始标记稍长，但是远比并发标记时间短
第四阶段： 并发清除，不STW，清理删除掉标记阶段判断已经死亡的对象，这个阶段其实是耗时的，但由于不需要移动存活对象，所以这个阶段也是与用户线程并发执行的
只有在初始阶段和重新标记阶段会STW，总体来说STW时间很短。
缺点：并发收集会抢占CPU资源，导致性能下降。同时会产生浮动垃圾，因为并发清除的时候用户线程还在产生垃圾，而且不能让老年代填满了再清除，要给用户线程预留空间，所以JDK1.5之后，默认老年代68%就触发回收，1.6提升到92%。同时基于标记清除算法，会导致产生内存碎片，可设置参数-XX:CMSFullGCBeforeCompaction设置CMS收集器若干次不整理空间的FullGC后，下一次FullGC会先进行碎片整理，默认值为0，表示每次进行FullGC的时候都进行碎片整理。

G1收集器

Garbage First，既收集新生代，也收集老年代，是目前可用于生产环境的最前沿最先进的垃圾收集器，JDK1.8u40才正式完成，开始可以使用，JDK9发布时，G1取代了Parallel Scavenge加Parallel Old的组合，称为服务端模式下的默认的垃圾收集器，而CMS则被声明为不推荐使用的收集器。
基本原理： G1是一个可以让我们设置垃圾回收的预期停顿时间的垃圾收集器，通过参数-XX:MaxGCPauseMillis,默认为200ms。其实我们对内存合理分配，优化JVM参数就是为了尽可能减少新生代或者整个老年代再或者这个堆，尽量减少GC带来的系统同盾，避免影响系统处理用户请求，G1可以指定垃圾回收导致的系统停顿时间不能超过多久，不管垃圾的多或少，垃圾回收的时间都不能超过我们设置的值，这个值由开发人员全权负责，相当于我们可以直接控制垃圾收集器对系统性能的影响。G1会尽量把垃圾回收造成的系统影响控制在指定的时间范围内，同时在有限的时间内尽可能的回收更多的垃圾。

G1收集器是怎么做到可预测停顿时间

G1收集器最大的特点就是将整个Java堆内存拆分成多个大小相等的Region(区域)，G1会追踪每个Region的中的对象会有多少是垃圾，如果对这个Region回收需要耗费多长时间，可以回收掉多少垃圾（回收价值）。G1收集器之所以能建立可预测的停顿时间模型，是因为它将Region作为垃圾回收的最小单元，每次可以选择一部分Region进行收集，避免在整个Java堆中进行全区域的垃圾手机，让G1收集器去跟踪各个Region里面的垃圾的回收价值，然后根据用户设定的收集停顿时间，在后台维护一个优先级列表，优先处理回收价值大的Region，这种使用Region划分堆内存空间，基于回收价值的回收方式，保证 了G1收集器在有限的时间内尽可能回收更多的垃圾。

G1收集器对新生代的垃圾回收

G1的新生代也有Eden和Survivor，触发垃圾回收的机制也是类似的，随着不停地在新生代Eden对应的Region中放对象，JVM就会不停的给新生代加入更多的Region，当Eden区满了的时候就会触发新生代的GC，G1依然会用复制算法进行垃圾回收，进入STW状态，然后将Eden对应Region中的存活对象放入到S0对应的Region中，然后回收掉Eden对用Region中的垃圾对象，但是这个过程和之前是有区别的，因为设定了GC停顿时间，所以通过追踪回收每个Region的回收时间和可以回收多少个对象，来选择性的回收一部分Region。

G1收集器对分代区的资源分配

Region中存在一种专门用于存储大对象的区域，为Humongous，G1认为只要大小超过了一个Region容量的一半，那么这个对象就可以判定为为大对象，每个Region的大小可以通过参数-XX:G1HeapRegionSize设定，取值范围为1MB~32MB，而对于超过了整个Region容量的大对象，会被存放在N个连续的Region中。最多可以存在2048个Region，默认新生代占比5%，大约200个Region，系统运行时会不停的给新生代增加对象，那么占比也会增加，但是最大值不会超过60%，并且一旦Region进行回收，此时占比也会下降。

G1收集器对老年代的垃圾回收

1、初始标记，需要STW，仅仅标记GCRoots直接引用的对象，这个过程很快，而且是借用进行MinorGC的时候同步完成的，所以G1收集器在这个阶段实际并没有什么额外的停顿
2、并发标记，不需要STW，这个阶段GCRoots开始追踪所有的存活对象，从上一步中直接的引用开始追踪，这个阶段耗时，但是因为是并发运行，所以对性能影响不大。
3、重新标记，需要STW，标记最终有哪些存活对象，哪些是垃圾对象。
4、筛选回收，需要STW，对各个Region的回收价值和成本进行排序，根据用户设定的期望停顿时间制定回收计划，然后把决定回收的那一部分Region的存活对象复制到空的Region中，再清理掉这个Region的全部空间。

G1收集器中的混合垃圾回收

即mixed GC，它不是一个oldGC，除了回收这个新生代Region，还会回收一部分的老年代的Region，G1有一个参数是-XX:InitiatingHeapOccupancyPercent默认值是45%，就是如果老年代占据了堆内存45%的Region的时候，此时会尝试触发一个新生代+老年代一起的混合回收阶段。

G1中的Full GC

在进行Mixed回收的时候，无论是新生代还是老年代，都基于复制算法进行回收，把各个Region中存活的对象复制到其他空闲的Region中，如果复制时没有空闲Region可以存放存活对象了，那么就会停止用户线程，采用单线程进行标记清除和压缩整理，清理出一批空闲的Region，这个过程很慢。

使用G1垃圾收集器的场景

1、针对大内存，多处理器的机器推荐使用G1垃圾收集器，比如堆内存大小至少6G或以上。
2、超过50%的对空间都被活动数据占用。
3、在要求低延迟的场景。
4、对象在堆中分配频率或年代升级频率变化比较大，方式高并发下应用雪崩的现象。

ZGC垃圾收集器

低延迟为首要目标的一款垃圾收集器，基于动态Region内存布局，暂时不设内存分代，使用读屏障、染色指针和内存多重映射等技术来实现可并发的标记整理算法收集器，还存在于实验阶段，主要特点是回收TB级内存(最大4T)，停顿时间不超过10ms

Shenandoah收集器

不是Oracal研发团队研发的收集器，Oracal明确拒绝在JDK12中支持此收集器，只有OpenJDK才包含此收集器，能实现任何堆内存大小下都把垃圾回收停顿时间控制在10ms以内