twolf技术站

Appearance

垃圾回收 ​

一、介绍 ​

Java语言中一个显著的特点就是引入了垃圾回收机制，使c++程序员最头疼的内存管理的问题迎刃而解。由于有个垃圾回收机制，Java中的对象不再有“作用域”的概念，只有对象的引用才有“作用域”。垃圾回收可以有效的防止内存泄露，有效的使用空闲的内存

垃圾回收：回收不存活的对象

二、对象是否存活判断 ​

2.1 引用计数法 ​

堆中每个对象实例都有一个引用计数。当一个对象被创建时，且将该对象实例分配给一个变量，该变量计数设置为1。当任何其它变量被赋值为这个对象的引用时，计数加1（a = b,则b引用的对象实例的计数器+1），但当一个对象实例的某个引用超过了生命周期或者被设置为一个新值时，对象实例的引用计数器减1。任何引用计数器为0的对象实例可以被当作垃圾收集。当一个对象实例被垃圾收集时，它引用的任何对象实例的引用计数器减1。

如果对象循环引用，当判断对象是否存活时，这个对象就会一直判断为存活，与线程死锁的产生类似

2.2 可达性分析算法 ​

可达性算法(又叫根搜索法)：根搜索算法是从离散数学中的图论引入的，程序把所有的引用关系看作一张图，从一个节点GC ROOT开始，寻找对应的引用节点，找到这个节点以后，继续寻找这个节点的引用节点，当所有的引用节点寻找完毕之后，剩余的节点则被认为是没有被引用到的节点，即无用的节点

java中可作为GC Root的对象有

  • 虚拟机栈中引用的对象（本地变量表）
  • 本地方法栈中引用的对象
  • 方法区中静态属性引用的对象
  • 方法区中常量引用的对象
  • 所有被同步锁（synchronized关键字）持有的对象
  • Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象（比如NullPointExcepiton、OutOfMemoryError）等，还有系统类加载器

2.2.1 并发可达性分析 ​

并发的可达性分析可能造成的后果：

一种是把原本消亡的对象错误标记为存活，这不是好事，但其实是可以容忍的，只不过产生了一点逃过本次收集的浮动垃圾而已，下次收集清理 掉就好。另一种是把原本存活的对象错误标记为已消亡，这就是非常致命的后果了，程序肯定会因此发生错误

对象标记阶段：

三色标记（Tri-color Marking）作为工具来辅助推导，把遍历对象图过程中遇到的对象，按照“是否访问过”这个条件标记成以下三种颜色：

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

image-20220608200606384

解决并发可达性分析的方案：

  1. 增量更新（Incremental Update）
  2. 原始快照（Snapshot At The Beginning，SATB）

以上无论是对引用关系记录的插入还是删除，虚拟机的记录操作都是通过写屏障实现的。在HotSpot虚拟机中，增量更新和原始快照这两种解决方案都有实际应用

  • CMS是基于增量更新来做并发标记的
  • G1、Shenandoah则是用原始快照来实现。

三、对象回收 ​

3.1 GC ​

分代收集理论的GC种类：

  • 部分收集（Partial GC）：指目标不是完整收集整个Java堆的垃圾收集，其中又分为：
    • 新生代收集（Minor GC/Young GC）：指目标只是新生代的垃圾收集。
    • 老年代收集（Major GC/Old GC）：指目标只是老年代的垃圾收集。目前只有CMS收集器会有单独收集老年代的行为。另外请注意“Major GC”这个说法现在有点混淆，在不同资料上常有不同所指，
  • 混合收集（Mixed GC）：指目标是收集整个新生代以及部分老年代的垃圾收集。目前只有G1收集器会有这种行为。
  • 整堆收集（Full GC）：收集整个Java堆和方法区的垃圾收

通常能单独发生收集行为的只是新生代，所以这里“反过来”的情况只是理论上允许，实际上除了CMS收集器，其他都不存在只针对老年代的收集

3.2 垃圾收集算法 ​

3.2.1 标记清除算法 ​

“标记-清除”（Mark-Sweep）算法，如同它的名字一样，算法分为“标记”和“清除”两个阶段：

首先标记出所有不需要回收的对象，在标记完成后统一回收所有未被标记的对象。

它的主要不足有两个：

  • 一个是效率问题，标记和清除两个过程的效率都不高；
  • 另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作

3.2.2 标记复制算法 ​

为了解决效率问题，一种称为“复制”（Copying）的收集算法出现了，它将可用内存按量划分为大小相等的两块，每次只使用其中的一块，当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。

现在的商业虚拟机都采用这种收集算法来回收新生代，研究表明，新生代中的对象 98%是“朝生夕死”的，所以并不需要按照 1:1 的比例来划分内存空间，而是将内存分为一块较大的 Eden 空间和两块较小的 Survivor 空间，每次使用 Eden 和其中一块 Survivor（分为Survivor from 和Survivor to ），内存比例 8：1：1，当回收时，将 Eden 和 Survivor 中还存活着的对象一次性地复制到另外一块 Survivor 空间上，最后清理掉 Eden 和刚才用过的 Survivor 空间。

HotSpot 虚拟机默认 Eden 和 Survivor 的大小比例是 8:1, 也就是每次新生代中可用内存空间为整个新生代容量的 90% (80%+10%），只有 10% 的内存会被“浪费”。当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于 10%的对象存活，当 Survivor 空间不够用时，需要依赖其他内存（大多数是指老年代）进行分配担保（Handle Promotion）。

3.2.3 标记整理算法 ​

“标记-整理（Mark- Compact）算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。这种算法适用于存活率比较高的内存区域，如java堆里的老年代。

与复制算法对比，这里不需要额外开辟新的内存空间去存储存活的对象

3.2.4 分代收集算法 ​

一般把 Java 堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法

  • 新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。
  • 老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或者“标记一整理”算法来进行回收

四、jvm收集器 ​

垃圾回收器组合设置：

新生代老年代JVM options
SerialSerial-XX:+UseSerialGC
Parallel ScavengeSerial-XX:+UseParallelGC -XX:-UseParallelOldGC
Parallel ScavengeParallel Scavenge-XX:+UseParallelGC -XX:+UseParallelOldGC
Parallel NewCMS-XX:+UseParNewGC -XX:+UseConcMarkSweepGC
G1-XX:+UseG1GC

垃圾回收器从线程运行情况分类有三种

  1. 串行回收，Serial回收器，单线程回收，全程stw；
  2. 并行回收，名称以Parallel开头的回收器，多线程回收，全程stw；
  3. 并发回收，cms与G1，多线程分阶段回收，只有某阶段会stw；

4.1 serial收集器 ​

Serial是一个单线程的垃圾收集器，当达到一个点触发GC回收的时候,工作线程停止,gc线程进行工作，gc线程工作完以后恢复工作线程。

serial垃圾收集器的特点

  • “Stop The World”，它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。在用户不可见的情况下把用户正常工作的线程全部停掉
  • 使用场景：多用于桌面应用，Client端的垃圾回收器，桌面应用内存小，进行垃圾回收的时间比较短，只要不频繁发生停顿就可以接受
分代类型垃圾收集算法
新生代标记-复制算法
老年代标记-整理算法

4.2 ParNew收集器 ​

ParNew 收集器其实就是 Serial 收集器的多线程版本(并行收集器)，即多个gc线程进行回收，除了使用多条线程进行垃圾收集之外，其余行为包括 Serial 收集器可用的所有控制参数（例如：-XX: SurvivorRatio、-XX: PretenureSize' Threshold、-XX: HandlePromotionFailure 等）、收集算法、Stop The World、对象分配规则、回收策略等都与 Serial 收集器完全一样，在实现上，这两种收集器也共用了相当多的代码

parnew垃圾收集器的特点

  • ParNew 收集器除了多线程收集之外，其他与 Serial 收集器相比并没有太多创新之处，但它却是许多运行在 Server 模式下的虚拟机中首选的新生代收集器，其中有一个与性能无关但很重要的原因是，除了 Serial 收集器外，目前只有它能与 CMS 收集器配合工作。
  • 使用-XX: ParallelGCThreads 参数来限制垃圾收集的线程数
  • 多线程操作存在上下文切换的问题，所以建议将-XX: ParallelGCThreads设置成和CPU核数相同，如果设置太多的话就会产生上下文切换消耗

4.3 Parallel Scavenge收集器 ​

Parallel Scavenge 收集器(并行收集器)是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器，由于与吞吐量关系密切，Parallel Scavenge 收集器也经常称为“吞吐量优先”收集器

吞吐量：CPU用于运行用户代码的时间与CPU总时间的比值，99%时间执行用户线程，1%时间回收垃圾 ，这时候吞吐量就是99%

特点：

  • Parallel Scavenge 收集器的特点是它的关注点与其他收集器不同，CMS 等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而 Parallel Scavenge 收集器的目标则是达到个可控制的吞吐（Throughput）。所谓吞吐量就是 CPU 用于运行用户代码的时间与 CPU 总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了 100 分钟，其中垃圾收集花掉 1 分钟，那吞吐量就是 99% 停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量则可以高效率地利用 CPU 时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

  • 虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为 GC自适应调节策略

  • -XX:MaxGCPauseMillis参数GC停顿时间，500MB ——>300MB,这个参数配置太小的话会发生频繁GC

  • -XX:GCTimeRatio参数，99%

  • Serial old收集器，它是一个单线程收集器，使用"标记--整理"算法

  • Parallel old收集器Parallel Scavenge收集器的老年代版本，使用多线程+"标记-整理"算法

4.4 CMS收集器 ​

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

目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上,这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS 收集器是基于“标记-清除”算法实现的。在并发标记和重新标记阶段，工作线程是会被停止

步骤流程：

  • 初始标记（CMS initial mark) ：标记一下 GC Roots 能直接关联到的对象，速度很快，这里工作线程会停止。
  • 并发标记（CMS concurrent mark）：并发标记阶段就是进行 GC RootsTracing 的过程，这里用户线程不会被停止
  • 重新标记（CMS remark) ：为了修正并发标记期间因用户程序导致标记产生变动的标记记录，这里工作线程会停止。
  • 并发清除（CMS concurrent sweep)：清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的

image-20220608200918500

CMS垃圾收集器缺点

  • 对CPU资源非常敏感，需要多核的环境

  • 无法处理浮动垃圾，程序在进行并发清除阶段用户线程所产生的新垃圾

  • 标记-清除暂时空间碎片

  • 到了JDK 6时，CMS收集器的启动阈值就已经默认提升至92%。但这又会更容易面临另一种风险：要是CMS运行期间预留的内存无法满足程序分配新对象的需要，就会出现一次“并发失败”（Concurrent Mode Failure），这时候虚拟机将不得不启动后备预案：冻结用户线程的执行，临时启用Serial Old收集器来重新进行老年代的垃圾收集，但这样停顿时间就很长了。

    jvm通过cms收集一定的次数或者运行一定的时长进行内存碎片的回收。CMS收集器提供了-XX:UseCMSCompactAtFullCollection开关参数，默认是开启的，用于在CMS收集器不得不进行Full GC时开启内存碎片的合并整理过程。 有参数可以配置有多少次Full GC会堆内存碎片进行整理(-XX:CMSFullGCsBeforeCompaction）。这两个参数从JDK 9开始废弃

4.5 G1收集器 ​

特点：G1 中每个 Region 都有一个与之对应的 Remembered Set，当进行内存回收时，在 GC 根节点的枚举范围中加入 Remembered Set 即可保证不对全堆扫描也不会有遗漏，检查Reference引用的对象是否处于不同的Region

G1 收集器的运作大致可划分为以下几个步骤

  • 初始标记（Initial Marking）：标记一下 GC Roots 能直接关联到的对象
  • 并发标记（Concurrent Marking）：从GC Root 开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行
  • 最终标记（Final Marking) ：为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录。虚拟机将这段时间对象变化记录在线程 Remembered Set Logs 里面，最终标记阶段需要把 Remembered Set Logs的数据合并到 Remembered Set 中
  • 筛选回收（Live Data Counting and Evacuation)

G1的优势有哪些

  • 空间整合：基于“标记一整理”算法实现为主和Region之间采用复制算法实现的垃圾收集
  • 可预测的停顿：这是 G1 相对于 CMS 的另一大优势，降低停顿时间是 G1 和 CMS 共同的关注点，但 G1 除了追求低停顿外，还能建立可预测的停顿时间模型
  • 在 G1 之前的其他收集器进行收集的范围都是整个新生代或者老年代，而 G1 不再是这样。使用 G1 收集器时，Java 堆的内存布局就与其他收集器有很大差别，它将整个 Java 雄划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔髙的了，它们都是一部分 Region（不需要连续）的集合。
  • G1 收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个 Java 堆中进行全区域的垃圾收集。G1 跟踪各个 Regions 里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的 Region（这也就是 Garbage- Firsti 名称的来由）。这种使用 Region 划分内存空间以及有优先级的区域回收方式，保证了 G1 收集器在有限的时间内可以获取尽可能高

开启参数：-XX:+UseG1GC

G1收集器.drawio

粤ICP备2024174490号-1 Copyright © 2024-present twolf