JVM(五) -- GC收集器(CMS和G1)

本文参考深入理解Java虚拟机和Understanding the G1 Garbage Collector – Java 9

GC收集器

GC收集器是内存回收的具体实现，现在有很多GC回收器，但是我们这边主要学习下CMS收集器和G1收集器。

CMS

CMS（concurrent mark serrp）收集器是一种以获取最短回收停顿为目标的收集器。CMS是基于标记-清除算法实现的，整个过程分为四个步骤。

• 初始标记 会"stop the world"，仅仅只是标记GC Roots能直接关联的对象，速度很快
• 并发标记 不会"stop the world"，能与用户线程同时执行，进行GC Roots Tracking
• 重新标记 会"stop the world" ，为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。
• 并发清除阶段 不会"stop the world"，能与用户线程同时执行
  优点：并发收集，低停顿
  缺点：会与用户线程抢占cpu资源，无法处理并发清理阶段产生的浮动垃圾，标记清除会产生大量的内存碎片

G1（JDK1.7开始出现）

G1的全程是Garbage First，优先处理垃圾多的内存块。底层是基于标记-整理的算法，所以规避了CMS会产生内存碎片的问题。

• G1将新生代，老年代的物理空间划分取消了，采用了将堆划分为若干个区域（Region）。每个Region都可以是新生代或者老年代，在HotSpot的实现中，整个堆被划分成2048左右个Region，每个Region的大小在1-32MB之间，具体多大取决于堆的大小。可以用图解更清晰的展示一下

  
  
  一般GC内存分布
  
  
  G1内存分布
• 我们可以看出来每个Region导致了eden，survivor和old区的内存变成了更小的内存块，极大的方便了并发收集。上面说到CMS的可以并发清除不会stop the world，其实是只在老年代才可以，在回收年轻代的时候CMS是会stop the world。而G1整个收集全程几乎都是并行的
• 因为切分成Region之后由于GC不用回收整个大的区域，而是固定的几个Region，所以能让用户控制垃圾回收的大概时间。
• 缺点是G1比较适合内存大的JVM，因为当内存小的时候可能光回收Region并不能很好解决内存不够导致的频繁GC问题