JVM:常用的四种垃圾回收机制

1.CMS (Concurrent Mark Sweep)：并行 标记清除 老年代垃圾回收机制

cms是一个基于标记-清除 算法的综合多种算法的老年代垃圾回收器

适用场景：重视服务器响应速度，要求系统停顿时间最短。
这里要说明下，这是一个老年代算法，年轻代怎么处理？不回收了嘛？这里其实年轻代是采用的其它算法，具体看策略，Java 参数可以选择策略。这里下文也会涉及到

主要的pipeline如下

1、初始标记（CMS initial mark）
“Stop The World”，仅仅只是标记一下 GC Roots 能直接关联到的对象，也就是根集合可直接到达的对象，但不会直接到叶子节点，还有遍历新生代对象，标记可达的老年代对象；速度很快。

这些灰色的节点就是初始标记的节点
2.并发标记
再进行GC RootTracing的过程中，继续标记这些对象可以到达的对象，做可达性分析（可达性分析的思路就是通过引用链路判断对象是否可被触达，如果能触达说明该对象当前正在被使用，不可回收；反之，没有触达到的对象则认为是无使用的，可以回收。）

3、重新标记（CMS remark）
“Stop The World”，为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。

这里有一个讨论：重新标记的意义在哪？主要是标记那些数据？
remark阶段应该是以当前的gc roots开始再标记，但会跳过初始标记中已经被标记的数据，这样可以保证不会漏标。对于从存活到垃圾的这些对象来说，只能下次GC标记了。

4、并发清除（CMS concurrent sweep）
并行清理数据垃圾，回收内存。

优点：
并发收集
低停顿
缺点：

CPU 资源消耗过大
并发设计会对CPU敏感，CMS 默认启动的回收线程数：（CPU数量+3）/4，也就是当 CPU 在4个以上时，并发回收时垃圾收集线程不少于 25%。
CMS 收集器无法处理浮动垃圾
并发期间不用暂停，那么会导致这段期间产生的垃圾将不会被回收，只能下一次回收，这称作浮动垃圾。
产生空间碎片
本质上是一个标记-清除 垃圾回收算法，意味着收集结束时会有大量空间碎片产生，给大对象分配空间带来麻烦，如果老年代无空间可存放大对象，得不提前触发一次 Full GC 。当然CMS也提供来一些Java 参数来帮助解决，比如顶不住压力时开启内存碎片的合并整理过程、多少次回收后使用该整理算法。

CMS（不带压缩）可以与Serial和ParNew进行组合，共2种组合垃圾回收算法。

2.Serial回收器：串行回收

Serial收集器是最基本、历史最悠久的垃圾收集器了，JDK1.3之前回收新生代唯一的选择
Serial收集器采用复制算法、串行回收，和"Stop一 the一World"机制的方式执行内存回收。
这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束（Stop The World ）。

Serial回收器的优势
简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。
运行在Client模式下的虛拟机是个不错的选择。
在用户的桌面应用场景中，可用内存一般不大（几十MB至一两百MB）， 可以在较短时间内完成垃圾收集（几十ms至一百多ms） ，只要不频繁发生，使用串行回收器是可以接受的。
在HotSpot虛拟机中，使用-XX： +UseSerialGC 参数可以指定年轻代和老年代都使用串行收集器。
等价于新生代用Serial GC，且老年代用Serial Old GC
控制台输出 -XX:InitialHeapSize=268435456 -XX:MaxHeapSize=4294967296 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseSerialGC
Serial回收器总结
这种垃圾收集器大家了解，现在已经不用串行的了。而且在限定单核cpu才可以用。现在都不是单核的了。
对于交互较强的应用而言，这种垃圾收集器是不能接受的。一般在Javaweb应用程序中是不会采用串行垃圾收集器的。

3.ParNew回收器:并行回收

Par是Parallel的缩写，New表示只能处理的是新生代

ParNew收集器除了采用并行回收的方式执行内存回收外，两款垃圾收集器之间几乎没有任何区别。ParNew收集器在年轻代中同样也是采用复制算法、"Stop一 the一World"机制。
ParNew是很多JVM运行在Server模式下新生代的默认垃圾收集器。
对于新生代，回收次数频繁，使用并行方式高效。
对于老年代，回收次数少，使用串行方式节省资源。（CPU并行 需要切换线程，串行可以省去切换线程的资源）

由于ParNew收集器是基于并行回收，那么是否可以断定ParNew收集器的回收效率在任何场景下都会比Serial收集器更高效？
➢ParNew 收集器运行在多CPU的环境下，由于可以充分利用多CPU、 多核心等物理硬件资源优势，可以更快速地完成垃圾收集，提升程序的吞吐量。
➢但是在单个CPU的环境下，ParNew收 集器不比Serial收集器更高 效。虽然Serial收集器是基于串行回收，但是由于CPU不需要频繁地做任务切换，因此可以有效避免多线程交互过程中产生的一些额外开销。
除Serial Old外，目前ParNew GC还可以与CMS收集器配合工作

---

4.g1垃圾回收机制

---

所有的垃圾回收器的目的都是朝着减少STW的目的而前进，G1(Garbage
First)回收器的出现颠覆了之前版本CMS、Parallel等垃圾回收器的分代收集方式，从2004年Sun发布第一篇关于G1的论文后，直到2012年JDK7发布更新版本，花了将近10年的时间G1才达到商用的程度，而到JDK9发布之后，G1成为了默认的垃圾回收器，CMS也变相地相当于被淘汰了。**

G1抛弃了之前的分代收集的方式，面向整个堆内存进行回收，把内存划分为多个大小相等的独立区域Region。
一共有4种Region：
自由分区Free Region
年轻代分区Young Region，年轻代还是会存在Eden和Survivor的区分
老年代分区Old Region
大对象分区Humongous Region
每个Region的大小通过-XX:G1HeapRegionSize来设置，大小为1~32MB，默认最多可以有2048个Region，那么按照默认值计算G1能管理的最大内存就是32MB*2048=64G。

对于大对象的存储，存在Humongous概念，对G1来说，超过一个Region一半大小的对象都被认为大对象，将会被放入Humongous Region，而对于超过整个Region的大对象，则用几个连续的Humongous来存储（如下图H区域）。

G1最大的优势就在于可预测的停顿时间模型，我们可以自己通过参数-XX:MaxGCPauseMillis来设置允许的停顿时间(默认200ms)，G1会收集每个Region的回收之后的空间大小、回收需要的时间，根据评估得到的价值，在后台维护一个优先级列表，然后基于我们设置的停顿时间优先回收价值收益最大的Region。

回收过程
G1的回收过程分为以下四个步骤：

初始标记：标记GC ROOT能关联到的对象，需要STW
并发标记：从GCRoots的直接关联对象开始遍历整个对象图的过程，扫描完成后还会重新处理并发标记过程中产生变动的对象
最终标记：短暂暂停用户线程，再处理一次，需要STW
筛选回收：更新Region的统计数据，对每个Region的回收价值和成本排序，根据用户设置的停顿时间制定回收计划。再把需要回收的Region中存活对象复制到空的Region，同时清理旧的Region。需要STW。

相对于之前我们存在分代概念的GC来说，G1其实也是类似的过程，总体可以分为这两种：

年轻代GC，年轻代Region在超过我们默认设置的最大大小之后就会触发GC，还是用的我们熟悉的复制算法，Eden和Survivor来回倒腾，这里不再赘述。
Mixed GC混合回收，混合回收类似于之前我们的Full GC概念，既会回收年轻代的Region，也会回收老年代的Region，还有我们新的Humongous大对象区域。触发规则根据参数-XX:InitiatingHeapOccupancyPercent(默认45%)值，也就是说老年代Region达到整个堆内存的45%时触发Mixed GC。