JVM（三）—— 垃圾收集器

垃圾收集器

3.5 垃圾收集器

• 垃圾收集算法属于方法，而垃圾收集器属于方法的具体实现。虚拟机规范没有对垃圾收集器如何实现给出明确的规定，不同的厂商、不同的版本提供的垃圾收集器会有不同的差别，用户可以根据厂商提供的参数和回收数据的特点自由组合不同的垃圾收集器。如图所示的基于JDK1.7Update14之后的垃圾收集器。
• 图中连线的收集器是可以自由组合的，到现在为止并没有一种收集器是最好的。不同的收集器适合于不同的场景。

3.5.1 Serial收集器

• 线程类型：单线程收集器
  • 它只会使用一个CPU或一条线程去完成垃圾收集工作，并且在进行垃圾收集时，会暂停其他的所有工作线程，直到它的线程收集结束。“Stop the world”，虚拟机会在后台自动发起的和自动完成的，在用户不可见的情况下把用户正常工作的线程全部停掉。
• 收集算法：复制算法
• 优点：
  • 简单而高效（与其他收集器的单线程相比），对于限定的单个CPU的环境，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。
• 应用：
  • 运行在Client模式下的默认的新生代的收集器。

3.5.2 ParNew收集器

• 线程类型：多线程收集器（实际上就是Serial收集器的多线程版本）
• 收集算法：复制算法
• 比较于Serial收集器:
  • 相同：控制参数、收集算法、Stop the world、对象分配规则、回收策略
  • 区别：线程类型区别
• 优点：
  • 多线程的实现垃圾收集
• 应用：
  • 运行在Server模式下的默认的新生代的收集器——除了Serial之外唯一能和CMS配合的收集器
• 补充：
  • 并发：用户线程与垃圾收集线程同时执行，用户程序在继续运行，垃圾收集程序运行在另一个CPU
  • 并行：多条垃圾收集线程并行工作，但此时用户线程仍然属于等待状态。

3.5.3 Parallel Scavenge收集器

• 线程类型：多线程类型
• 收集算法：复制算法
• 比较于CMS收集器：
  • CMS收集器关注点在尽量缩短垃圾收集时用户线程停顿的时间
  • Parallel Scavenge关注点在吞吐量，CPU执行用户程序时间与CPU总耗时间的比值
• 比较于ParNew收集器：
  • 自适应调节策略
• 控制吞吐量的两个参数：-XX:MaxGCPauseMills和-XX：GCTimeRatio
  • MaxGCPauseMills：是一个大于0的毫秒数，收集器将尽可能保证最大垃圾收集停顿时间不超过此设定值。此值越小，收集停顿时间会减小，但是吞吐量和新生代空间都会减小。
  • GCTimeRatio：是一个大于0小于100的整数，就是垃圾收集时间占总时间的比率，相当于吞吐量的倒数。
• 自适应调节策略：Parallel Scavenge收集器有一个参数-XX:UseAdaptiveSizePolicy。当此参数打开之后，就需要手动指定新生代的大小（-Xmn）、Eden和Survivor的比例（-XX：SurvivorRatio）、晋升老年代对象年龄（-XX：PretenureSizeThreshold），虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大吞吐量。

3.5.4 Serial Old收集器

• 是Serial收集器的老年代版本，是一个单线程的收集器，使用的“标记-整理”收集算法。
• 应用：
  • Client模式下的虚拟机使用
  • 配合JDK1.5之前的Parallel Scanvenge，
  • 作为CMS收集器的后备预案

3.5.5 Parallel Old收集器

• 是Parallel Scanvenge收集器的老年代版本，是一个多线程的收集器，使用“标记-整理”收集算法
• 应用：
  • 配合Parallel Scanvenge收集器

3.5.6 CMS收集器（并发低停顿收集器）

• 是以获取最短的回收停顿时间为目标的收集器。主要应用在互联网站和B/S系统的服务端上。回收停顿时间短能给用户更好的体验。使用“标记-清除”算法。
• 执行过程：
  • 初始标记：仅仅是标记一下和GC Roots能直接关联到的对象，速度很快
  • 并发标记：进行GC Roots Tracing的过程，
  • 重新标记：为了修正并发标记期间因用户程序继续执行而导致的标记产生变动的那一部分对象的标记记录。此停顿时间会比初始标记时间稍长，远比并发标记时间短。
  • 并发清除
• 特点：由于并发标记和和并发清除过程收集器线程都可以和用户线程一块工作，所以总体上的CMS收集器的内存回收过程是与用户线程一起并发执行的。
• 三缺点：
  • CMS收集器对CPU资源十分敏感：并发程序都对CPU资源比较敏感，由于CMS收集器是和用户线程并发执行的，CMS收集器默认启动的回收线程是（CPU数量＋３）/4，当CPU的数量超过4个之后，收集线程占有的CPU资源不会少于25%,如果CPU数量少于4个时，CMS收集器占有的相对线程就会增多，分给用户的相对执行线程就会减少。
  • CMS收集器无法处理浮动垃圾，可能会出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生：由于CMS并发清理阶段用户还在运行着，用户线程还是会产生垃圾，这些垃圾叫做浮动垃圾，CMS收集器无法收集这些浮动垃圾。由于CMS收集器并发执行的过程中，用户程序还要执行，所以需要预留空间给用户线程产生垃圾存储空间。所以CMS不能等到老年代空间快满的时候才启动。这里就涉及到老年代占有空间对CMS启动的触发点，如果设置老年代空间较大就有可能预留给用户线程的空间少出现“Concurrent Mode Failure”，此时需要启动后备方案也就是Servial Old收集器。如果老年代空间设置较小，那么CMS触发点低，就会频繁的出现垃圾收集，性能降低。
  • CMS基于“标记-清除”收集算法，所以会产生内存碎片。

3.5.7 G1收集器

• G1收集器是面对服务端应用的垃圾收集器，目的是为了替换掉CMS。
• 对比于其他GC收集器：
  • 并行与并发：G1能充分利用多CPU、多核环境的硬件优势，缩短Stop-The-World停顿时间，可以通过并发方式让用户线程执行。
  • 分代收集：不需要配合其他收集器就可以独立管理整个GC堆。
  • 空间整合：G1整体上是基于“标记-整理”算法实现，局部是基于“复制”算法。
  • 可预测的停顿：降低了停顿时间，还建立了可预测停顿的模型，能让使用者明确指定在一个长度为M毫秒的时间段内，消耗在垃圾收集上的时间不得超过N毫秒。
• 执行过程：
  • 初始标记：仅仅是标记一下GC Roots能直接关联的到的对象且修改TAMS（Next Top at Mark Start）的值，让下一阶段的用户程序并发运行时，能在正确可用的Region中创建对象，需要停顿线程，时间很短。
  • 并发标记：从GC Roots开始对堆进行可达性分析，找出存活的对象，消耗时间长，但可以和用户线程并发执行。
  • 最终标记：为了修正在并发标记期间因用户程序继续执行运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程Remembered Set Logs，需要把Remembered Set Logs的数据合并到Remembered Set中，需要停顿线程，但可并行执行。
  • 筛选标记：首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来指定回收计划。