七大垃圾回收器

垃圾回收器的四种方式

一 serial 串行垃圾回收

它为单线程环境设计且只使用一个线程进行垃圾回收，会暂停所有的用户线程。所以不适合服务器环境

二 Parallel 并行垃圾回收

多个垃圾收集线程并行工作，此时用户线程是暂停的，适用于科学计算/大数据处理首台处理等弱交互场景

三 CMS (ConcurrentMarkSweep)并发垃圾回收

用户线程和垃圾收集线程同时执行（不一定是并行，可能交替执行），不需要停顿用户线程,互联网公司多用它，适用对响应时间有要求的场景

Serial和Parallel和CMS的区别小结

四.G1垃圾回收器（G1 Garbage Collector）

G1垃圾回收将堆内存分割成不同的区域然后并发的对其进行垃圾回收

GC约定参数说明

七种垃圾收集器

新生代和老年代分别使用的垃圾收集器

一 Serial收集器

一个单线程的收集器，在进行垃圾收集时候，必须暂停其他所有的工作线程直到它收集结束。

串行收集器是最古老，最稳定以及效率高的收集器，只使用一个线程去回收但其在进行垃圾收集过程中可能会产生较长的停顿（Stop-The-World”状态）。虽然在收集垃圾过程中需要暂停所有其他的工作线程，但是它简单高效，对于限定单个CPU环境来说，没有线程交互的开销可以获得最高的单线程垃圾收集效率，因此Serial垃圾收集器依然是java虚拟机运行在Client模式下默认的新生代垃圾收集器。

二 ParNew（并行）收集器

使用多线程进行垃圾回收，在垃圾收集时，会Stop-the-World暂停其他所有的工作线程直到它收集结束。

备注:可用 -XX:ParallelGCThreads限制线程数量,默认开启和Cpu数目相同的线程数

三 Parallel Scavenge收集器

四 Parallel Old收集器

Parallel Old收集器是Parallel Scavenge的老年代版本，使用多线程的标记-整理算法，Parallel Old收集器在JDK1.6才开始提供。 |在JDK1.6之前，新生代使用ParallelScavenge 收集器只能搭配年老代的，Serial Old收集器，只能保证新生代的吞吐量优先，无法保证整体的吞吐量。在JDK1.6之前（Parallel Scavenge+Serial Old） Parallel Old正是为了在年老代同样提供吞吐量优先的垃圾收集器，如果系统对吞吐量要求比较高，JDK1.8后可以优先考虑新生代Parallel Scavenge和年老代Parallel Old收集器的搭配策略。在JDK1.8及后（Parallel Scavenge+Parallel Old） JVM常用参数： -XX：+UseParallelOldGC 使用Parallel Old收集器，设置该参数后，新生代Parallel+老年代Parallel Old

五 并发标记清除GC(CMS)

CMS收集器（Concurrent Mark Sweep：并发标记清除）是一种以获取最短回收停顿时间为目标的收集器。 适合应用在互联网站或者B/S系统的服务器上，这类应用尤其重视服务器的响应速度，希望系统停顿时间最短。 CMS非常适合堆内存大、CPU核数多的服务器端应用，也是G1出现之前大型应用的首选收集器。

CMS内部四个步骤

CMS优缺点

优点: 并发收集低停顿

缺点:

• 由于并发进行，CMS在收集与应用线程会同时会增加对堆内存的占用，也就是说，CMS必须要在老年代堆内存用尽之前完成垃圾回收，否则CMS回收失败时，将触发担保机制，串行老年代收集器将会以STW的方式进行一次GC，从而造成较大停顿时间
• 标记清除算法无法整理空间碎片，老年代空间会随着应用时长被逐步耗尽，最后将不得不通过担保机制对堆内存进行压缩。CMS也提供了参数来指定多少次Full GC之后，进行一次压缩。(-XX:CMSFullGCsBeForeCompaction（默认0，即每次Full GC都进行内存整理）) CMS详细

六 serial old

Serial Old 题Serial垃圾收集器老年代版本，它同样是个单线程的收集器，使用标记-整理算法，这个收集器也主要是运行在Client默认的java虚拟机默认的年老代垃圾收集器。 在Server模式下，主要有两个用途（了解，版本已经到8及以后）： 1.在JDK1.5之前版本中与新生代的Parallel Scavenge 收集器搭配使用。（Parallel Scavenge+Serial Old） 2.作为老年代版中使用CMS收集器的后备垃圾收集方案。

七 G1垃圾回收器

我们知道G1是一种服务器端的垃圾收集器，应用在多处理器和大容量内存环境中，在实现高吞吐量的同时，尽可能的满足垃圾收集暂停时间的要求。 另外，它还具有以下特性：

• 像CMS收集器一样，能与应用程序线程并发执行。
• 整理空闲空间更快。
• 需要更多的时间来预测GC停顿时间。
• 不希望牺牲大量的吞吐性能。
• 不需要更大的Java Heap。

G1收集器的设计目标是取代CMS收集器，它同CMS相比在以下方面表现的更出色： G1是一个有整理内存过程的垃圾收集器，不会产生很多内存碎片。 G1的STW更可控，G1在停顿时间上添加了预测机制，用户可以指定期望停顿时间。

G1和以前垃圾收集器的特点对比

G1底层原理

主要依赖于

,最大好处是化整为零，避免全内存扫描，只需要按照区域来进行扫描即可。 详解region区域化垃圾收集器

region区域化垃圾收集器

G1回收 针对Eden区进行收集，Eden区耗尽后会被触发，主要是小区域收集+形成连续的内存块，避免内存碎片

• Eden区的数据移动到Survivor区，假如出现Survivor区空间不够，Eden区数据会部会晋升到Old区
• Survivor区的数据移动到新的Survivor区，部会数据晋升到Old区
• 最后Eden区收拾干净了，GC结束，用户的应用程序继续执行。

G1垃圾回收比较详细的步骤

简单将老年代的步骤

G1参数设置

G1 垃圾收集器架构和如何做到可预测的停顿(阿里)

G1的另一个显著特点他能够让用户设置应用的暂停时间，为什么G1能做到这一点呢？也许你已经注意到了，G1回收的第4步，它是“选择一些内存块”，而不是整代内存来回收，这是G1跟其它GC非常不同的一点，其它GC每次回收都会回收整个Generation的内存(Eden, Old), 而回收内存所需的时间就取决于内存的大小，以及实际垃圾的多少，所以垃圾回收时间是不可控的,G1通过控制回收的内存大小来大概可以满足这个停顿时间。