CMS收集器
CMS收集器是一种获取最短回收停顿时间为目标的收集器,基于的是标记-清除算法。它的运作过程相对于去墙面集中收集器来说更为复杂一些,分为四个步骤:
- 初始标记:标记GC Roots能够直接关联到的对象
- 并发标记:进行GC Roots Tracing的过程
- 重新标记:修正并发标记期间因用户程序继续运作而导致标记变动的那一部分对象的标记记录,即让线程正确的到达safe point
- 并发清除:
其中初始标记与重新标记这两步仍然需要停止其他所有线程。
注意:!!!!并发过程(并发标记和并发清理)是不用将其余线程停下来工作的
具体过程如下:

虽然CMS可以并发收集并且停顿低,但仍然有几个明显的缺点:
- CMS对CPU资源非常敏感,因为在并发阶段,虽然它不会导致用户线程停顿,但是会因为占用一部分线程而导致应用程序变慢,从而导致总的吞吐量降低。
- CMS收集器无法处理浮动垃圾。在CMS的GC阶段,由于是并发标记,一旦其他线程在标记之后产生了垃圾,CMS就无法在当此对其回收,而这些在标记之后无法回收的垃圾就叫做浮动垃圾。
- 由于CMS是基于标记-清除算法,因此会产生大量的内存碎片
G1收集器
G1是一款面向服务端应用的垃圾收集器,与其他GC收集器相比,G1具备如下特点:
- 并行与并发:能利用多CPU多核环境下的硬件优势来尽可能的缩短停顿时间。
- 分代收集。
- 空间整合。采用“标记-整理”算法
- 可预测的停顿。G1能够建立一个可预测的停顿时间模型,能让使用者明确指定在一个长度为M毫秒的时间片段内,消耗在垃圾手机上的时间不得超过N毫秒。
与其他收集器不同的时,虽然G1还保留了新生代和老年代的概念,但是同时它将JAVA堆划分为多个大小相等的独立区域(region),并且此时新生代和老年代不再是物理隔离的了,他们都是一部分region的集合。
G1将各个region按优先级进行划分,在后台维护一个优先列表,每次根据允许的收集时间,优先回收价值最大的Region。G1中每个Region都有一个与之对应的Remebered Set,用来避免全堆扫描。
虚拟机如果发现程序在对Reference类型的数据进行写操作的时候,会产生一个暂时写终端,检查reference引用的对象是否处于不同的Region,如果是,便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set之中。
如果不考虑维护RSet的操作,G1的运作大致可划分为以下几步:
- 初始标记
- 并发标记
- 最终标记
-
筛选回收
类似CMS,具体运行如下图所示
image
网友评论