JVM经典的垃圾收集器

最新推荐文章于 2024-08-26 22:40:20 发布

码农@攻城狮

最新推荐文章于 2024-08-26 22:40:20 发布

阅读量948

点赞数 8

分类专栏： JVM 文章标签： jvm

本文链接：https://blog.csdn.net/weixin_43915808/article/details/141499413

版权

JVM 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

经典垃圾收集器

Serial收集器

Serial收集器是一个单线程工作的收集器，但它的“单线程”的意义并不仅仅是说明它只会使用一个处理器或一条线程去完成垃圾收集工作，更重要的是强调在它进行垃圾收集时，必须暂停其他所有工作线程，直到它收集结束。

以下是Serial/Serial Old收集器运行示意图：

在这里插入图片描述

📌注意：
新生代采取复制算法暂停所有用户线程

老年代采取标记-整理算法暂停所有用户线程

Serial收集器时HotPost虚拟机运行在客户端模式下的默认新生代收集器，有着优于其他收集器的地方，那就是简单而高效（与其他收集器的单线程相比），对于内存资源受限的环境，它是所有收集器里额外内存消耗最小的；对于单核处理器核心数较少的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。

ParNew收集器

ParNew收集器实质上是Serial收集器的多线程并行版本。

以下是ParNew/Serial Old收集器运行示意图：

在这里插入图片描述

PraNew收集器除了支持多线程并行收集之外，其他的与Serial收集器相比没有太多创新之处，它可以与CMS收集器配合在服务端模式下工作。

JDK9开始，ParNew加CMS收集器组合不再是官方推荐的服务端模式下的收集器解决方案。甚至取消了ParNew加Serial Old和Serial加CMS收集器组合。

Parallel Scavenge收集器

Parallel Scavenger收集器也是一款新生代收集器，同样是基于标记复制算法实现的收集器，也是能够并行收集的多线程收集器。

Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量。所谓吞吐量就是处理用于运行用户代码的时间与处理总消耗时间的比值。

Serial Old收集器

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

以下是Serial/Serial Old收集器运行示意图：

在这里插入图片描述

📌注意：
新生代采取复制算法暂停所有用户线程

老年代采取标记-整理算法暂停所有用户线程

Parallel Old收集器

Parallel Old是Parallel Scavenge收集器的老年代版本，支持多线程并发收集，基于标记-整理算法实现。

以下是Parallel/Parallel Old收集器运行示意图：

在这里插入图片描述

CMS 收集器

CMS(Concurrent Mark Sweep)收集器是一种以获取最短时间回收停顿时间为目标的收集器。

CMS收集器是基于标记-清除算法实现的，它的运作过程相对于前面几种收集器来说要更复杂一些，整个过程分为四个步骤：

初始标记（CMS initial mark）
并发标记（CMS concurrent mark）
重新标记（CMS remark）
并发清除（CMS concurrent sweep）

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

以上标记阶段是基于可达性算法实现的。

以下是CMS收集器运行示意图：

在这里插入图片描述

CMS三个明显的缺点：

CMS收集器对处理器资源非常敏感。事实上，面向并发设计的程序都对处理器资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但却会因为占用了一部分线程（或者说处理器的计算能力）而导致应用程序变得慢，降低总吞吐量。CMS默认启动的回收线程数量是（处理器核心数量+3）/4，也就是说，如果处理器核心数在四个或以上，并发回收时垃圾收集线程只占用不超过25%的处理器运算资源，并且随着处理器核心数量的增加而降低。但是当处理器核心数量不足四个时，CMS对用户程序的影响可能变得很大。
CMS收集器无法处理“浮动垃圾”，有可能出现“Concurrent Mode Failure”失败进而导致另一次完全“Stop The Word”的Full GC的产生。浮动垃圾就是在CMS进行并发标记和并发清除的时候用户线程产生的死亡对象。这些对象可能超过空闲空间的大小，导致Full GC。JDK5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活，到了JDK6，CMS收集器的启动阈值默认为92%，这样的话风险大大提高。
CMS基于标记-清除算法实现的，所以机会有标记-清除算法的缺点。

Garbage First收集器

Garbage First收集器，简称G1收集器，G1是一款主要面向服务端应用的垃圾收集器。

G1收集器出现之前的所有其他收集器，包括CMS在内，垃圾收集的目标范围要么是整个新生代（Minor GC），要么就是整个老年代（Major GC），再要么就是整个java堆（Full GC）。而G1跳出了这个樊笼，它可以面向对内存任何部分来组成回收集（Collection Set）进行回收，衡量标准不再是它属于哪个分代，而是哪块内存中存放的垃圾数量最多，回收受益最大，这就是G1收集器的Mixed GC模式。

G1虽然仍遵循分代收集理论设计的，但是其堆内存的布局与其他收集器有非常明显的差异：
G1不在坚持固定大小以及固定数量的分代区域划分，而是把连续的java堆划分为多个大小相等的独立区域（Region），每个Region都可以根据需要，扮演新生代的Eden空间，Survivor空间，或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理，这样无论是新创建的对象还是已经存活了一段时间，熬过多次收集的旧对象都能获取很好的收集效果。

Region中还有一类特殊的Humongous区域，专门用来存储大对象。G1认为只要大小超过了一个Region容量一半的对象即可判定为大对象。每个Region的大小可以通过参数-XX:G1HeapRegionSize设定，取值范围为1MB~32MB，且应为2的N次幂。而对于那些超过了整个Region容量的超级大对象，将会被存放在N个连续的Humongous Region之中，G1的大多数行为都把Humongous Region作为老年代的一部分来进行看待。

G1收集器的运作过程大致可分为四个步骤：