垃圾收集器

最新推荐文章于 2024-09-05 17:28:41 发布

原创最新推荐文章于 2024-09-05 17:28:41 发布 · 503 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#垃圾收集器 #java虚拟机

java虚拟机专栏收录该内容

18 篇文章

订阅专栏

JVM垃圾收集器发展历程

第一阶段，Serial（串行）收集器
串行收集器是最简单的，它设计为在单核的环境下工作（32位或者windows），你几乎不会使用到它。它在工作的时候会暂停整个应用的运行，因此在所有服务器环境下都不可能被使用。
使用方法：-XX:+UseSerialGC

在jdk1.3.1之前，java虚拟机仅仅能使用Serial收集器。 Serial收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅是说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。

第二阶段，Parallel（并行）收集器
这是JVM默认的收集器，跟它名字显示的一样，它最大的优点是使用多个线程来扫描和压缩堆。缺点是在minor GC和Full GC的时候都会暂停应用的运行。并行收集器最适合用在可以容忍程序停滞的环境中使用，它占用较低的CPU因而能提高应用的吞吐量。

使用方法：-XX:+UseParallelGC

Parallel收集器也称吞吐量收集器，相比Serial收集器，Parallel最主要的优势在于使用多线程去完成垃圾清理工作，这样可以充分利用多核的特性，大幅降低gc时间。

第三阶段，CMS（并发的标记与清除）收集器
这个算法使用多个线程并发地（concurrent）扫描堆，标记不使用的对象，然后清除它们回收内存。在两种情况下会使应用暂停（Stop the World, STW）：

当初次开始标记根对象时initial mark。
当在并行收集时应用又改变了堆的状态时，需要它从头再确认一次标记了正确的对象final remark。

这个收集器最大的问题是在年轻代与老年代收集时会出现的一种竞争情况（race condition），称为提升失败promotion failure。对象从年轻代复制到老年代称为提升promotion，但有时侯老年代需要清理出足够空间来放这些对象，这需要一定的时间，它收集的速度可能赶不上不断产生的要提升的年轻代对象的速度，这时就需要做STW的收集。STW正是CMS想避免的问题。为了避免这个问题，需要增加老年代的空间大小或者增加更多的线程来做老年代的收集以赶上从年轻代复制对象的速度。

除了上文所说的内容之外，CMS最大的问题就是内存空间碎片化的问题。CMS只有在触发FullGC的情况下才会对堆空间进行compact。如果线上应用长时间运行，碎片化会非常严重，会很容易造成promotion failed。为了解决这个问题线上很多应用通过定期重启或者手工触发FullGC来触发碎片整理。

对比并行收集器，CMS收集器的一个坏处是需要占用比较多的CPU。对于大多数长期运行的服务器应用来说，这通常是值得的，因为它不会导致应用长时间的停滞。但是它不是JVM的默认的收集器。

CMS收集器在Minor GC时会暂停所有的应用线程，并以多线程的方式进行垃圾回收。在Full GC时不再暂停应用线程，而是使用若干个后台线程定期的对老年代空间进行扫描，及时回收其中不再使用的对象。

第四阶段，G1（并发）收集器
如果你的堆内存大于4G的话，那么G1会是要考虑使用的收集器。它是为了更好支持大于4G堆内存在JDK 7 u4引入的。G1收集器把堆分成多个区域，大小从1MB到32MB，并使用多个后台线程来扫描这些区域，优先会扫描最多垃圾的区域，这就是它名称的由来，垃圾优先Garbage First。

如果在后台线程完成扫描之前堆空间耗光的话，才会进行STW收集。它另外一个优点是它在处理的同时会整理压缩堆空间，相比CMS只会在完全STW收集的时候才会这么做。

使用过大的堆内存在过去几年是存在争议的，很多开发者从单个JVM分解成使用多个JVM的微服务（micro-service）和基于组件的架构。其他一些因素像分离程序组件、简化部署和避免重新加载类到内存的考虑也促进了这样的分离。

除了这些因素，最大的因素当然是避免在STW收集时JVM用户线程停滞时间过长，如果你使用了很大的堆内存的话就可能出现这种情况。另外，像Docker那样的容器技术让你可以在一台物理机器上轻松部署多个应用也加速了这种趋势。

G1收集器（或者垃圾优先收集器）的设计初衷是为了尽量缩短处理超大堆（大于4GB）时产生的停顿。相对于CMS的优势而言是内存碎片的产生率大大降低。

使用方法：－XX:+UseG1GC

JVM垃圾收集器种类

新生代的垃圾收集器

Serial (第一代) Serial串行收集器-复制算法

Serial收集器是新生代单线程收集器，优点是简单高效，算是最基本、发展历史最悠久的收集器。它在进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集完成。
Serial收集器依然是虚拟机运行在Client模式下默认新生代收集器，对于运行在Client模式下的虚拟机来说是一个很好的选择。
在这里插入图片描述

PraNew (第二代) ParNew收集器-复制算法

ParNew收集器是新生代并行收集器，其实就是Serial收集器的多线程版本。
除了使用多线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与Serial 收集器完全一样。
在这里插入图片描述

Parallel Scavenge (第三代)（并行回收）收集器-复制算法

Parallel Scavenge收集器是新生代并行收集器，追求高吞吐量，高效利用 CPU。

该收集器的目标是达到一个可控制的吞吐量（Throughput）。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）

停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量则可用高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

老年代的垃圾收集器

Serial Old (第一代)收集器-标记整理算法

Serial Old是Serial收集器的老年代版本，它同样是一个单线程(串行)收集器，使用标记整理算法。这个收集器的主要意义也是在于给Client模式下的虚拟机使用。

如果在Server模式下，主要两大用途：

（1）在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用

（2）作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用

Parallel Old (第二代)收集器-标记整理算法

Parallel Old 是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。这个收集器在1.6中才开始提供。

CMS (第三代)标记清除算法

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。
目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务器的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。
CMS收集器是基于“标记-清除”算法实现的，它的运作过程相对前面几种收集器来说更复杂一些，整个过程分为4个步骤：
（1）初始标记

（2）并发标记

（3）重新标记

（4）并发清除
其中，初始标记、重新标记这两个步骤仍然需要“Stop The World”
在这里插入图片描述
CMS收集器主要优点：

并发收集
低停顿

CMS三个明显的缺点：
（1）CMS收集器对CPU资源非常敏感。CPU个数少于4个时，CMS对于用户程序的影响就可能变得很大，为了应付这种情况，虚拟机提供了一种称为“增量式并发收集器”的CMS收集器变种。
（2）CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。在JDK1.5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活。
（3）CMS是基于“标记-清除”算法实现的收集器，手机结束时会有大量空间碎片产生。空间碎片过多，可能会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前出发FullGC。

G1（Garbage First）收集器 (第四代)新生代和老年代垃圾收集器-标记整理算法

JDK1.7后全新的回收器, 用于取代CMS收集器。

G1收集器的优势：
G1最大的特点是引入分区的思路，弱化了分代的概念。
合理利用垃圾收集各个周期的资源，解决了其他收集器甚至CMS的众多缺陷。
独特的分代垃圾回收器,分代GC: 分代收集器, 同时兼顾年轻代和老年代
使用分区算法, 不要求eden, 年轻代或老年代的空间都连续
并行性: 回收期间, 可由多个线程同时工作, 有效利用多核cpu资源
空间整理: 回收过程中, 会进行适当对象移动, 减少空间碎片
可预见性: G1可选取部分区域进行回收, 可以缩小回收范围, 减少全局停顿

G1相比较CMS的改进
算法： G1基于标记-整理算法, 不会产生空间碎片，分配大对象时不会无法得到连续的空间而提前触发一次FULL GC。

停顿时间可控： G1可以通过设置预期停顿时间（Pause Time）来控制垃圾收集时间避免应用雪崩现象。

并行与并发：G1能更充分的利用CPU，多核环境下的硬件优势来缩短stop the world的停顿时间。

CMS和G1的区别
CMS中，堆被分为PermGen，YoungGen，OldGen；而YoungGen又分了两个survivo区域。在G1中，堆被平均分成几个区域(region)，在每个区域中，虽然也保留了新老代的概念，但是收集器是以整个区域为单位收集的。
G1在回收内存后会马上同时做合并空闲内存的工作、而CMS默认是在STW（stop the world）的时候做。
G1会在Young GC中使用、而CMS只能在O区使用。

G1收集器的应用场景
G1垃圾收集算法主要应用在多CPU大内存的服务中，在满足高吞吐量的同时，尽可能的满足垃圾回收时的暂停时间。

就目前而言、CMS还是默认首选的GC策略、可能在以下场景下G1更适合：

服务端多核CPU、JVM内存占用较大的应用（至少大于4G）
应用在运行过程中会产生大量内存碎片、需要经常压缩空间
想要更可控、可预期的GC停顿周期，防止高并发下应用雪崩现象

G1收集器的运作大致可划分为一下步骤：
在这里插入图片描述
G1收集器的阶段分以下几个步骤：

1、初始标记（这个阶段是STW(Stop the World )的，所有应用线程会被暂停，它标记了从GC Root开始直接可达的对象）

2、并发标记（从GC Roots开始对堆中对象进行可达性分析，找出存活对象，耗时较长）

3、最终标记（标记那些在并发标记阶段发生变化的对象，将被回收）

4、筛选回收（首先对各个Regin的回收价值和成本进行排序，根据用户所期待的GC停顿时间指定回收计划，回收一部分Region）
回收整个Java堆(新生代和老年代)的垃圾收集器是G1收集器，就是说发生Full GC的时候，使用G1垃圾收集器进行垃圾回收

G1的堆内存算法
G1之前的JVM内存模型
在这里插入图片描述
新生代：伊甸园区(eden space) + 2个幸存区
老年代
持久代(perm space)：JDK1.8之前
元空间(metaspace)：JDK1.8之后取代持久代
G1收集器的内存模型

G1堆内存结构
堆内存会被切分成为很多个固定大小区域（Region），每个是连续范围的虚拟内存
堆内存中一个区域(Region)的大小可以通过-XX:G1HeapRegionSize参数指定，大小区间最小1M、最大32M，总之是2的幂次方。
默认把堆内存按照2048份均分。

G1堆内存分配
每个Region被标记了E、S、O和H，这些区域在逻辑上被映射为Eden，Survivor和老年代。
存活的对象从一个区域转移（即复制或移动）到另一个区域。区域被设计为并行收集垃圾，可能会暂停所有应用线程。
如上图所示，区域可以分配到Eden，survivor和老年代。此外，还有第四种类型，被称为巨型区域（Humongous Region）。Humongous区域是为了那些存储超过50%标准region大小的对象而设计的，它用来专门存放巨型对象。如果一个H区装不下一个巨型对象，那么G1会寻找连续的H分区来存储。为了能找到连续的H区，有时候不得不启动Full GC。

G1中提供了两种垃圾回收模式，Young GC和Mixed GC，两种都是Stop The World(STW)的。
.
YoungGC年轻代收集

在分配一般对象（非巨型对象）时，当所有eden region使用达到最大阀值并且无法申请足够内存时，会触发一次YoungGC。每次younggc会回收所有Eden以及Survivor区，并且将存活对象复制到Old区以及另一部分的Survivor区。

YoungGC的回收过程如下：

根扫描,跟CMS类似，Stop the world，扫描GC Roots对象。
处理Dirty card,更新RSet.
扫描RSet,扫描RSet中所有old区对扫描到的young区或者survivor区的引用。
拷贝扫描出的存活的对象到survivor2/old区
处理引用队列，软引用，弱引用，虚引用
mixed gc
当越来越多的对象晋升到老年代old region时，为了避免堆内存被耗尽，虚拟机会触发一个混合的垃圾收集器，即mixed gc，该算法并不是一个old gc，除了回收整个young region，还会回收一部分的old region，这里需要注意：是一部分老年代，而不是全部老年代，可以选择哪些old region进行收集，从而可以对垃圾回收的耗时时间进行控制。

G1没有fullGC概念，需要fullGC时，调用serialOldGC进行全堆扫描（包括eden、survivor、o、perm）。

G1的第一个重要特点是**为用户的应用程序的提供一个低GC延时和大内存GC的解决方案。**这意味着堆大小6GB或更大，稳定和可预测的暂停时间将低于0.5秒。

如果应用程序使用CMS或ParallelOld垃圾回收器具有一个或多个以下特征，将有利于切换到G1：

Full GC持续时间太长或太频繁
对象分配率或年轻代升级老年代很频繁
不期望的很长的垃圾收集时间或压缩暂停（超过0.5至1秒）
注意：如果你正在使用CMS或ParallelOld收集器，并且你的应用程序没有遇到长时间的垃圾收集暂停，则保持与您的当前收集器是很好的，升级JDK并不必要更新收集器为G1。

通常来说你需要根据你的业务，进行基于垃圾回收器的性能测试，然后再做选择。下面给出配置回收器时，经常使用的参数：

-XX:+UseSerialGC：在新生代和老年代使用串行收集器

-XX:+UseParNewGC：在新生代使用并行收集器

-XX:+UseParallelGC ：新生代使用并行回收收集器，更加关注吞吐量

-XX:+UseParallelOldGC：老年代使用并行回收收集器

-XX:ParallelGCThreads：设置用于垃圾回收的线程数

-XX:+UseConcMarkSweepGC：新生代使用并行收集器，老年代使用CMS+串行收集器

-XX:ParallelCMSThreads：设定CMS的线程数量

-XX:+UseG1GC：启用G1垃圾回收器