垃圾回收器

发表于 | 更新于

使用场景总览

总览

serial 收集器

  1. 可以使用在新生代
  2. 单线程
  3. 进行收集操作的时候 stop the world
  4. 使用复制算法

serial_old

  1. 老年代版本的serial 收集器
  2. 单线程
  3. 使用标记-整理算法
  4. 主要用途是在jdk1.5 之前parallel scavenge配合，还有作为CMS的后备收集器，在并发收集时发生concurrent Mode Failure时使用，

ParNew 收集器

  1. 用在新生代，使用复制算法
  2. serial的多线程版本，
  3. 新生代的首选，除了serial,只有他可以和CMS配合使用，实际上，在CMS作为老年代收集器后新生代只能选择serial和parNew
  4. -XX：ParallelGCThreads可以限制回收的线程数

Parallel Scavenge

  1. 用在新生代，使用复制算法,使用多线程
  2. 别的收集器关注点在于降低STW的时间，而Parallel Scavenge关注的是吞吐量，吞吐量=运行用户代码时间/（用户代码时间+垃圾回收时间）
  3. Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX：MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX：GCTimeRatio参数。
  4. -XX：+UseAdaptiveSizePolicy 就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX：SurvivorRatio）、晋升老年代对象年龄（-XX：PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量
  5. 无法与CMS配合使用，原因是Parallel Scavenge没有使用原本HotSpot其它GC通用的那个GC框架，所以不能跟使用了那个框架的CMS搭配使用

parallel scavenge old

  1. 用在老年代，多线程，标记整理算法
  2. 在1.6后提供，在此之前都只能使用serial_old作为老年代来配合parallel scavenge，效率并不高

CMS

  1. 目的时减少停顿时间，用于老年区

  2. 阶段包括：
    1.初始标记。标记下GC ROOT直接可达的对象，速度快
    2.并发标记。进行GC root trace
    3.重新标记. 是为了修正并发标记期间用户程序运行产生的垃圾变动，
    4.并发清除
    初始标记，重新标记仍然需要STW，

  3. 缺点：
    1. 无法处理浮动垃圾，即在并发清除时产生的垃圾，出现concurrent mode failure,所以CMS需要给并发清除预留一部分内存，所以CMS不能像别的收集器一样满了之后才运行，而是在达到阙值后就启动，-XX：CMSInitiatingOccupancyFraction可以设置阙值
    2. 由于基于标记清除算法，所以可能出现太多碎片，导致大的对象无法分配内存，为了处理这种情况，提供-XX：+UseCMSCompactAtFullCollection ，在每次FUll GC之前进行，碎片整理，和XX：CMSFullGCsBeforeCompaction，这个参数是用于设置执行多少次不压缩的Full GC后，跟着来一次带压缩的

G1收集器

在内存上将内存分为大小相等的region，新生代和老年代都是一部分不需要连续的的region，G1 可以有计划的避免在整个堆中进行回收，而是维护一个优先队列，每次根据运行的时间，优先回收价值最大的region，

这里作者提出一个问题：如果分为region，那么每个region里的对象肯定不是孤立的，而是互相有依赖，那么如果想回收新生代，岂不是也要扫描老年代？实际上G1和其他收集器在虚拟机中都是使用remembered set 来记录引用关系，如果虚拟机检测到对引用的修改，那么就立刻更新remembered set ,这样就可以保证不需要扫描全内存。

  1. G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果
  2. G1从整体来看是基于标记—整理算法实现的收集器，从局部（两个Region之间）上来看是基于复制算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片
  3. 停顿时间可预测，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒 ，

  4. 操作主要包括：
    1.初始标记，标记GC root直接可达的对象，并改变next top at mark start,STW，时间很短
    2.并发标记，进行可达性分析，将引用的变化情况记录在remembered set log
    3.最终标记，将remember set log 和remember set合并，STW
    4.筛选回收，也可以停顿也可以并行，主要对region回收价值排序，并在用户指定的停顿时间来制定回收计划

  5. 相对于CMS，碎片更少空间利用更高，停顿时间可控，

关于吞吐率和停顿时间　　

停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务,
看到parallel scavenge 注重的时吞吐率，而其他收集器注重停顿时间，觉得这两个不应该是同一种东西吗，减少了停顿时间不就提高了吞吐率吗，但这俩个应该算是两个维度，GC的时间应该是停顿时间的超集。