《深入理解 Java 虚拟机 JVM 高级特性与最佳实践(第3版)》_求知之路漫漫_3.5.4 Serial Old 收集器

【摘要】 本书摘自《深入理解 Java 虚拟机 JVM 高级特性与最佳实践(第3版)》一书中第3章，第5节，周志明著。

3.5.4 Serial Old 收集器

Serial Old 是 Serial 收集器的老年代版本，它同样是一个单线程收集器，使用标记-整

理算法。这个收集器的主要意义也是供客户端模式下的 HotSpot虚拟机使用。如果在服务端 模式下，它也可能有两种用途： 一种是在JDK5 以及之前的版本中与 Parallel Scavenge 收集 器搭配使用日，另外一种就是作为CMS 收集器发生失败时的后备预案，在并发收集发生 Concurrent Mode Failure 时使用。这两点都将在后面的内容中继续讲解。Serial Old 收集器 的工作过程如图3-9所示。

3.5.5 Parallel Old 收 集 器

Parallel Old 是 Parallel Scavenge 收集器的老年代版本，支持多线程并发收集，基于 标记-整理算法实现。这个收集器是直到JDK6 时才开始提供的，在此之前，新生代 的 Parallel Scavenge收集器一直处于相当尴尬的状态，原因是如果新生代选择了Parallel Scavenge 收集器，老年代除了Serial Old(PS MarkSweep)收集器以外别无选择，其他表现 良好的老年代收集器，如CMS 无法与它配合工作。由于老年代 Serial Old 收集器在服务端 应用性能上的“拖累”,使用Parallel Scavenge 收集器也未必能在整体上获得吞吐量最大化 的效果。同样，由于单线程的老年代收集中无法充分利用服务器多处理器的并行处理能力， 在老年代内存空间很大而且硬件规格比较高级的运行环境中，这种组合的总吞吐量甚至不 一定比 ParNew 加 CMS 的组合来得优秀。

直到 Parallel Old 收集器出现后，“吞吐量优先”收集器终于有了比较名副其实的搭配 组合，在注重吞吐量或者处理器资源较为稀缺的场合，都可以优先考虑 Parallel Scavenge 加 Parallel Old 收集器这个组合。Parallel Old收集器的工作过程如图3-10所示。

3.5.6 CMS 收集器

CMS(Concurrent Mark Sweep) 收集器是一种以获取最短回收停顿时间为目标的收集器。 目前很大一部分的Java应用集中在互联网网站或者基于浏览器的 B/S 系统的服务端上，这 类应用通常都会较为关注服务的响应速度，希望系统停顿时间尽可能短，以给用户带来良 好的交互体验。CMS 收集器就非常符合这类应用的需求。

从名字(包含 “Mark Sweep”) 上就可以看出CMS收集器是基于标记-清除算法实 现的，它的运作过程相对于前面几种收集器来说要更复杂一些，整个过程分为四个步骤， 包括：

1 ) 初 始 标 记 (CMS 2 ) 并 发 标 记 (CMS 3 ) 重 新 标 记 (CMS 4 ) 并 发 清 除 (CMS

initial mark)

concurrent mark)

remark)

concurrent sweep)

其中初始标记、重新标记这两个步骤仍然需要 “Stop The World”。初始标记仅仅只是 标记 一 下GC Roots 能直接关联到的对象，速度很快；并发标记阶段就是从GC Roots 的直 接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可 以与垃圾收集线程 一 起并发运行；而重新标记阶段则是为了修正并发标记期间，因用户程 序继续运作而导致标记产生变动的那 一部分对象的标记记录(详见3 .4 .6节中关于增量更新 的讲解),这个阶段的停顿时间通常会比初始标记阶段稍长 一 些，但也远比并发标记阶段的 时间短；最后是并发清除阶段，清理删除掉标记阶段判断的已经死亡的对象，由于不需要 移动存活对象，所以这个阶段也是可以与用户线程同时并发的。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们 18664393530@aliyun.com 处理，核实后本网站将在24小时内删除侵权内容。