JVM 垃圾收集器与收集算法初探

最新推荐文章于 2023-03-14 22:09:16 发布

雨夜星空丶月

最新推荐文章于 2023-03-14 22:09:16 发布

阅读量110

点赞数 1

分类专栏：学习文章标签： java

本文链接：https://blog.csdn.net/qq_37335177/article/details/127266762

版权

学习专栏收录该内容

31 篇文章 1 订阅

订阅专栏

JVM 垃圾收集器与收集算法初探

垃圾收集器
垃圾收集算法

垃圾收集器

YoungGC
YoungGC并不是说现有的Eden区放满了就会马上触发，G1会计算下现在Eden区回收大概要多久时间，如果回收时间远远小于参数-XX:MaxGCPauseMills设定的值，那么增加年轻代的region，继续给新对象存放，不会马上做YoungGC，直到下一次Eden区放满，G1计算回收时间接近参数-XX:MaxGCPauseMills设定的值，那么就会触发YoungGC
MixedGC(G1 收集器才有)
不是Full GC，老年代的堆占有率达到参数(-XX:InitiatingHeapOccupancyPercent)设定的值则触发，回收所有的Young和部分Old(根据期望的GC停顿时间确定old区垃圾收集的优先顺序)以及大对象区，正常情况G1的垃圾收集是先做MixedGC，主要使用复制算法，需要把各个region中存活的对象拷贝到别的region里去，拷贝过程中如果发现没有足够的空region能够承载拷贝对象就会触发一次Full GC
Full GC
停止系统程序，然后采用单线程进行标记、清理和压缩整理，好空闲出来一批Region来供下一次MixedGC使用，这个过程是非常耗时的。(Shenandoah优化成多线程收集了)

Serial收集器

	Serial（串行）收集器是最基本、历史最悠久的垃圾收集器了。大家看名字就知道这个收集器是一个单线程收集器了。它的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程（ "Stop The World" ），直到它收集结束

新生代算法：复制算法
老年代算法:标记-整理算法

优点简单且高效

由于没有线程交互的开销，自然可以获得很高的单线程收集效率

Parallel Scavenge收集器

	其实就是Serial收集器的多线程版本
	Parallel Scavenge收集器关注点是吞吐量（高效率的利用CPU）
	所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值

新生代算法:复制算法
老年代算法:标记-整理算法

JDK8默认的新生代和老年代收集器

ParNew收集器

ParNew收集器其实跟Parallel收集器很类似

新生代算法:复制算法

区别主要在于它可以和CMS收集器配合使用

CMS收集器

	CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器
	它非常符合在注重用户体验的应用上使用，它是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。

老年代算法:标记-清除算法
过程分为6个步骤
- 初始标记：在这个阶段,需要虚拟机停顿正在执行的任务,官方的叫法STW(Stop The Word).这个过程从垃圾回收的"根对象"开始,只扫描到能够和"根对象"直接关联的对象,并作标记.所以这个过程虽然暂停了整个JVM,但是很快就完成了.
- 并发标记：这个阶段紧随初始标记阶段,在初始标记的基础上继续向下追溯标记.并发标记阶段,应用程序的线程和并发标记的线程并发执行,所以用户不会感受到停顿.
- 并发预清理：并发预清理阶段仍然是并发的.在这个阶段,虚拟机查找在执行并发标记阶段新进入老年代的对象(可能会有一些对象从新生代晋升到老年代, 或者有一些对象被分配到老年代).通过重新扫描,减少下一个阶段"重新标记"的工作,因为下一个阶段会Stop The World.
- 重新标记：这个阶段会暂停虚拟机,收集器线程扫描在CMS堆中剩余的对象.扫描从"根对象"开始向下追溯,并处理对象关联.
- 并发清理：清理垃圾对象,这个阶段收集器线程和应用程序线程并发执行.
- 并发重置：这个阶段,重置CMS收集器的数据结构,等待下一次垃圾回收.

优点

并发收集、低停顿

缺点

对CPU资源敏感（会和服务抢资源）
无法处理浮动垃圾(在并发标记和并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次gc再清理了)
它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生，当然通过参数-XX:+UseCMSCompactAtFullCollection可以让jvm在执行完标记清除后再做整理 
执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full gc，也就是"concurrent mode failure"，此时会进入stop the world，用serial old垃圾收集器来回收 
    需要在程序设定时指定-XX:CMSInitiatingOccupancyFraction:当老年代使用达到该比例时会触发FullGC（默认是92，这是百分比） 该参数预留部分空间,避免该情况发生

核心参数

-XX:+UseConcMarkSweepGC：启用cms
-XX:ConcGCThreads：并发的GC线程数
-XX:+UseCMSCompactAtFullCollection：FullGC之后做压缩整理（减少碎片）
-XX:CMSFullGCsBeforeCompaction：多少次FullGC之后压缩一次，默认是0，代表每次FullGC后都会压缩一次
-XX:CMSInitiatingOccupancyFraction:当老年代使用达到该比例时会触发FullGC（默认是92，这是百分比）
-XX:+UseCMSInitiatingOccupancyOnly：只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设定的值)，如果不指定，JVM仅在第一次使用设定值，后续则会自动调整
-XX:+CMSScavengeBeforeRemark：在CMSGC前启动一次minorgc，目的在于减少老年代对年轻代的引用，降低CMSGC的标记阶段时的开销，一般CMS的GC耗时80%都在标记阶段
-XX:+CMSParallellnitialMarkEnabled：表示在初始标记的时候多线程执行，缩短STW
-XX:+CMSParallelRemarkEnabled：在重新标记的时候多线程执行，缩短STW;

G1收集器

	G1 (Garbage-First)是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足 GC 停顿时间要求的同时,还具备高吞吐量性能特征.

特点

G1将Java堆划分为多个大小相等的独立区域（Region），JVM最多可以有2048个Region。
一般Region大小等于堆大小除以2048，比如堆大小为4096M，则Region大小为2M，当然也可以用参数"-XX:G1HeapRegionSize"手动指定Region大小，但是推荐使用默认的计算方式。
G1保留了年轻代和老年代的概念，但不再是物理隔阂了，它们都是（可以不连续）Region的集合。
默认年轻代对堆内存的占比是5%，如果堆大小为4096M，那么年轻代占据200MB左右的内存，对应大概是100个Region，可以通过“-XX:G1NewSizePercent”设置新生代初始占比，在系统运行中，JVM会不停的给年轻代增加更多的Region，但是最多新生代的占比不会超过60%，可以通过“-XX:G1MaxNewSizePercent”调整。
Survivor对应的region也跟之前一样，默认8:1:1
所以说,一个Region可能之前是年轻代，如果Region进行了垃圾回收，之后可能又会变成老年代，也就是说Region的区域功能可能会动态变化

Humongous

在G1中，大对象的判定规则就是一个大对象超过了一个Region大小的50%，比如按照上面算的，每个Region是2M，只要一个大对象超过了1M，就会被放入Humongous中，而且一个大对象如果太大，可能会横跨多个Region来存放
Humongous区专门存放短期巨型对象，不用直接进老年代，可以节约老年代的空间，避免因为老年代空间不够的GC开销
Full GC的时候除了收集年轻代和老年代之外，也会将Humongous区一并回收。

运作过程步骤

初始标记（initial mark，STW）：暂停所有的其他线程，并记录下gc roots直接能引用的对象，速度很快；
并发标记（Concurrent Marking）：同CMS的并发标记
最终标记（Remark，STW）：同CMS的重新标记
筛选回收（Cleanup，STW）：筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间(可以用JVM参数 -XX:MaxGCPauseMillis指定)来制定回收计划
- 回收算法主要用的是复制算法，将一个region中的存活对象复制到另一个region中，这种不会像CMS那样回收完因为有很多内存碎片还需要整理一次，G1采用复制算法回收几乎不会有太多内存碎片
- 注意：CMS回收阶段是跟用户线程一起并发执行的，G1因为内部实现太复杂暂时没实现并发回收，不过到了Shenandoah就实现了并发收集，Shenandoah可以看成是G1的升级版本

收集效率保证

	G1收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的Region(这也就是它的名字Garbage-First的由来)，比如一个Region花200ms能回收10M垃圾，另外一个Region花50ms能回收20M垃圾，在回收时间有限情况下，G1当然会优先选择后面这个Region回收

G1收集器参数设置

-XX:+UseG1GC: 使用G1收集器
-XX:ParallelGCThreads: 指定GC工作的线程数量
-XX:G1HeapRegionSize: 指定分区大小(1MB~32MB，且必须是2的N次幂)，默认将整堆划分为2048个分区
-XX:MaxGCPauseMillis: 目标暂停时间(默认200ms)
-XX:G1NewSizePercent: 新生代内存初始空间(默认整堆5%)
-XX:G1MaxNewSizePercent: 新生代内存最大空间
-XX:TargetSurvivorRatio: Survivor区的填充容量(默认50%)，Survivor区域里的一批对象(年龄1+年龄2+年龄n的多个年龄对象)总和超过了Survivor区域的50%，此时就会把年龄n(含)以上的对象都放入老年代
-XX:MaxTenuringThreshold: 最大年龄阈值(默认15)
-XX:InitiatingHeapOccupancyPercent: 老年代占用空间达到整堆内存阈值(默认45%)，则执行新生代和老年代的混合收集(MixedGC)，比如我们之前说的堆默认有2048个region，如果有接近1000个region都是老年代的region，则可能就要触发MixedGC了
-XX:G1MixedGCLiveThresholdPercent: (默认85%)region中的存活对象低于这个值时才会回收该region，如果超过这个值，存活对象过多，回收的的意义不大。
-XX:G1MixedGCCountTarget: 在一次回收过程中指定做几次筛选回收(默认8次)，在最后一个筛选回收阶段可以回收一会，然后暂停回收，恢复系统运行，一会再开始回收，这样可以让系统不至于单次停顿时间过长。
-XX:G1HeapWastePercent(默认5%): gc过程中空出来的region是否充足阈值，在混合回收的时候，对Region回收都是基于复制算法进行的，都是把要回收的Region里的存活对象放入其他Region，然后这个Region中的垃圾对象全部清理掉，这样的话在回收过程就会不断空出来新的Region，一旦空闲出来的Region数量达到了堆内存的5%，此时就会立即停止混合回收，意味着本次混合回收就结束了。

优化建议

假设参数 -XX:MaxGCPauseMills 设置的值很大，导致系统运行很久，年轻代可能都占用了堆内存的60%了，此时才触发年轻代gc。
那么存活下来的对象可能就会很多，此时就会导致Survivor区域放不下那么多的对象，就会进入老年代中。
或者是你年轻代gc过后，存活下来的对象过多，导致进入Survivor区域后触发了动态年龄判定规则，达到了Survivor
区域的50%，也会快速导致一些对象进入老年代中。所以这里核心还是在于调节 -XX:MaxGCPauseMills 这个参数的值，在保证他的年轻代gc别太频繁的同时，还得考虑每次gc过后的存活对象有多少,避免存活对象太多快速进入老年代，频繁触发mixed gc.

适合场景

50%以上的堆被存活对象占用
对象分配和晋升的速度变化非常大
垃圾回收时间特别长，超过1秒
8GB以上的堆内存(建议值)
停顿时间是500ms以内

ZGC收集器

	ZGC是一款JDK 11中新加入的具有实验性质的低延迟垃圾收集器，ZGC可以说源自于是Azul System公司开发的C4（Concurrent Continuously Compacting Collector） 收集器

ZGC主要目标

支持TB量级的堆
最大GC停顿时间不超10ms
奠定未来GC特性的基础
最糟糕的情况下吞吐量会降低15%

ZGC当前无分代（如年轻代，老年代等）

内存布局

	主要分为三种容量
	- 小型Region 固定容量 2MB
	- 中型Region 固定容量32MB
	- 大型Region 容量不固定 动态变化，需满足2的整数倍，至少4MB

颜色指针

	Colored Pointers，即颜色指针，如下图所示，ZGC的核心设计之一。以前的垃圾回收器的GC信息都保存在对象头中，而ZGC的GC信息保存在指针中

每个对象有一个64位指针，这64位被分为
- 18位：预留给以后使用；
- 1位：Finalizable标识，此位与并发引用处理有关，它表示这个对象只能通过finalizer才能访问；
- 1位：Remapped标识，设置此位的值后，对象未指向relocation set中（relocation set表示需要GC的Region集合）；
- 1位：Marked1标识；
- 1位：Marked0标识，和上面的Marked1都是标记对象用于辅助GC；
- 42位：对象的地址（所以它可以支持2^42=4T内存）：
为什么有2个mark标记
- 每一个GC周期开始时，会交换使用的标记位，使上次GC周期中修正的已标记状态失效，所有引用都变成未标记。
- GC周期1：使用mark0, 则周期结束所有引用mark标记都会成为01。
- GC周期2：使用mark1, 则期待的mark标记10，所有引用都能被重新标记。
- 通过对配置ZGC后对象指针分析我们可知，对象指针必须是64位，那么ZGC就无法支持32位操作系统，同样的也就无法支持压缩指针了（CompressedOops，压缩指针也是32位）。

颜色指针的三大优势

一旦某个Region的存活对象被移走之后，这个Region立即就能够被释放和重用掉，而不必等待整个堆中所有指向该Region的引用都被修正后才能清理，这使得理论上只要还有一个空闲Region，ZGC就能完成收集。
颜色指针可以大幅减少在垃圾收集过程中内存屏障的使用数量，ZGC只使用了读屏障。
颜色指针具备强大的扩展性，它可以作为一种可扩展的存储结构用来记录更多与对象标记、重定位过程相关的数据，以便日后进一步提高性能。

读屏障

之前的GC都是采用Write Barrier，这次ZGC采用了完全不同的方案读屏障，这个是ZGC一个非常重要的特性。
在标记和移动对象的阶段，每次「从堆里对象的引用类型中读取一个指针」的时候，都需要加上一个Load Barriers。

ZGC运作过程

并发标记（Concurrent Mark）
并发预备重分配（Concurrent Prepare for Relocate）
并发重分配（Concurrent Relocate）
并发重映射（Concurrent Remap）

现有缺陷

浮动垃圾：ZGC的停顿时间是在10ms以下，但是ZGC的执行时间还是远远大于这个时间的。假如ZGC 全过程需要执行10分钟，在这个期间由于对象分配速率很高，将创建大量的新对象，这些对象很难进入当次GC，所以只能在下次GC的时候进行回收，这些只能等到下次GC才能回收的对象就是浮动垃圾。
解决方案：目前唯一的办法是增大堆的容量，使得程序得到更多的喘息时间，但是这个也是一个治标不治本的方案。如果需要从根本上解决这个问题，还是需要引入分代收集，让新生对象都在一个专门的区域中创建，然后专门针对这个区域进行更频繁、更快的收集。

触发时机

定时触发: 默认为不使用，可通过ZCollectionInterval参数配置。
预热触发: 最多三次，在堆内存达到10%、20%、30%时触发，主要时统计GC时间，为其他GC机制使用。
分配速率: 基于正态分布统计，计算内存99.9%可能的最大分配速率，以及此速率下内存将要耗尽的时间点，在耗尽之前触发GC（耗尽时间 - 一次GC最大持续时间 - 一次GC检测周期时间）。
主动触发: （默认开启，可通过ZProactive参数配置）距上次GC堆内存增长10%，或超过5分钟时，对比距上次GC的间隔时间跟（49 * 一次GC的最大持续时间），超过则触发

如何选择垃圾收集器

优先调整堆的大小让服务器自己来选择
如果内存小于100M，使用串行收集器
如果是单核，并且没有停顿时间的要求，串行或JVM自己选择
如果允许停顿时间超过1秒，选择并行或者JVM自己选
如果响应时间最重要，并且不能超过1秒，使用并发收集器
4G以下可以用parallel，4-8G可以用ParNew+CMS，8G以上可以用G1，几百G以上用ZGC

JDK 1.8默认使用 Parallel(年轻代和老年代都是)

JDK 1.9默认使用 G1

垃圾收集算法

标记-复制算法

概念: 它可以将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。
选择: 在新生代中，每次收集都会有大量对象(近99%)死去，可以选择复制算法

标记-整理算法

	算法分为“标记”和“清除”阶段：标记存活的对象， 统一回收所有未被标记的对象(一般选择这种)；也可以反过来，标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象

存在的问题

效率问题 (如果需要标记的对象太多，效率不高)
空间问题（标记清除后会产生大量不连续的碎片）

标记-清除算法

	根据老年代的特点特出的一种标记算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。

底层算法实现 - 三色标记

黑色
- 表示对象已经被垃圾收集器访问过，且这个对象的所有引用都已经扫描过。黑色的对象代表已经扫描过，它是安全存活的，如果有其他对象引用指向了黑色对象，无须重新扫描一遍。黑色对象不可能直接（不经过灰色对象）指向某个白色对象。
灰色
- 表示对象已经被垃圾收集器访问过，但这个对象上至少存在一个引用还没有被扫描过。
白色
- 表示对象尚未被垃圾收集器访问过。初始颜色。显然在可达性分析刚刚开始的阶段，所有的对象都是白色的，若在分析结束的阶段，仍然是白色的对象，即代表不可达。

并发标记存在的问题

多标 - 浮动垃圾
- 例如:在并发过程中,已经标记过的对象,却因为功能执行完,导致对象为垃圾对象,但因为已经标记过,所以不会被清理,只有下次gc才会被清理,这部分称为浮动垃圾
- 针对并发标记(还有并发清理)开始后产生的新对象，通常的做法是直接全部当成黑色，本轮不会进行清除。这部分对象期间可能也会变为垃圾，这也算是浮动垃圾的一部分
漏标
- 增量更新（ Incremental Update）
  - 黑色对象一旦新插入了指向白色对象的引用之后，它就变回灰色对象了,从而会被重新扫描一次,进而更新颜色
- 写屏障
  - 其实就是指在赋值操作前后，加入一些处理（可以参考AOP的概念）
  - 其中用到了一些队列,异步的方式,避免影响正常功能执行

CMS：写屏障 + 增量更新

G1，Shenandoah：写屏障 + SATB

G1为什么没用继续用增量更新而是使用SATB?

    SATB相对增量更新效率会高些,因为在处理并发问题时,SATB只是将对象赋值的那些对象进行了标记黑色,并不会重新遍历扫描一次, 保证当次GC这些对象存活即可,即使是浮动垃圾数据也只会在下次GC处理.

ZGC：读屏障

雨夜星空丶月

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
JVM 垃圾收集器与收集算法初探

不是Full GC，老年代的堆占有率达到参数(-XX:InitiatingHeapOccupancyPercent)设定的值则触发，回收所有的Young和部分Old(根据期望的GC停顿时间确定old区垃圾收集的优先顺序)以及大对象区，正常情况G1的垃圾收集是先做MixedGC，主要使用复制算法，需要把各个region中存活的对象拷贝到别的region里去，拷贝过程中如果发现没有足够的空region能够承载拷贝对象就会触发一次Full GC。每个对象有一个64位指针，这64位被分为。
复制链接

扫一扫