JAVA的垃圾收集器与内存分配策略【一篇文章直接看懂】( 五 ) _收集

CMS收集器（标记-清除算法）
CMS( Mark Sweep)一种以获取最短回收停顿时间为目标的收集器，集中在B/S系统的服务端上，较为关注服务的响应速度，带来良好的交互体验。
整个过程分为四个步骤：
初始标记（CMSmark）并发标记（CMSmark）重新标记（CMS ）并发清除（CMSsweep）
初始标记只是标记GC Roots直接关联的对象，速度很快
并发标记从直接关联的对象遍历对象图，不需要停顿用户线程，并发运行。
重新标记为了修正并发标记期间，用户线程导致标记有变动的对象标记记录，时间停顿比初试标记稍长，远比并发标记短
清除阶段为了删除在标记阶段判断的已死亡的对象，不需要移动存活对象，所以与用户线程并发
因此耗时最长的并发标记和并发清除都是可以与用户线程一起工作的
并发收集、停顿，但也有如下的缺点：
对处理器的资源非常敏感：【面向并发设计的程序都对处理器资源比较敏感】，并发时，占用了一部分线程、导致程序变慢、CMS中，在4核的情况下，GC线程只占用不超过25%，随着核心变多而下降。但是不足4个时，分出一半了。由此，产生了 "增量式并发收集器(Mark Sweep/i-CMS)"的变种，模仿OS的抢占式多任务。在``并发标记、清除`时，让GC与用户讲题运行->时间变慢，下降幅度不明显无法处理“浮动垃圾”（），因为并发，所以在GC时需要给用户线程留足够内存空间，所以不能等老年代快被填满时收集，JDK 5默认下是68%（偏保守了）
浮动垃圾：在CMS中，有可能出现“Con- ”失败进而导致另一次完全“Stop The World”的Full GC的产生。在运行自然就还会伴随有新的垃圾对象不断产生，但是出现在标记过程结束以后。CMS无法在当次收集中处理掉它们，只好留待下一次垃圾收集时再清理掉。
因为采用的标记-清除，因此有大量空间碎片产生。所以需要内存碎片合并过程。但是在移动存活对象，是无法并行的，所以在默认情况，每次进入Full GC先进行整理【-XX:-负责，要求CMS收集器在执行过若干次（数量由参数值决定）不整理空间的Full GC之后，下一次进入Full GC前会先进行碎片整理】First收集器（整体标记-整理，局部标记-复制）
简称G1，里程碑式的成果，号称全功能的垃圾收集器(Fully-)，开创了收集器面向局部收集的设计思路，和基于的内存布局形式，它是主要面向服务端应用的垃圾收集器。
核心思想：回收的衡量不再是属于哪个分代，而是取决于哪块的内存中的垃圾数量最多，回收收益最大，称为G1的Mixed GC模式
关键点：基于的堆内存布局【G1将连续的JAVA堆划分为多个大小相同的独立区域（），每个可以根据需要扮演新生代的Eden、、老年代空间】。中的区域专门存放大对象【大小超过的一半】

文章插图
分区示意图：
在应用G1收集器所解决的问题：
步骤：
初始标记（）：标记GC Root直接关联的对象，并修改TAMS指针的值，与Minor GC同步完成并发标记（）：从GC Root开始对堆进行可达性分析，耗时长可与用户并发进行，扫描后进行SATB处理最终标记（Final ）：对用户进行短暂的暂停，处理并发后遗留的SATB记录筛选回收（Live DataAnd ）：更新的统计数据，对其回收价值/成本进行排序，根据用户的需求制定回收计划。在这使用标记-复制算法后清除整个旧，设计对象移动，暂停用户，多条GC线程并行完成。
达到延迟可控的情况下，尽可能提高吞吐量的目的。需求从一次把整个JAVA堆清干净，变为能够应付应用的内存分配速率（ Rate）即可。与CMS的“标记-清除”算法不同，G1从整体来看是基于“标记-整理”，但从局部（两个之间）基于“标记-复制”，因此G1运作期间不会产生内存空间碎片。但G1在GC时的内存占用（）和程序运行的负载（）都比CMS高