JVM垃圾回收机制

Wu先生
166 阅读12分钟

JVM垃圾回收机制

垃圾收集算法

1. 标记-清除算法

算法分为”标记“和”清除“两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。

它是最基础的收集算法，但是存在以下不足：

  • 效率问题

    标记和清除两个过程的效率不高。

  • 空间问题

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

GC1.jpg

2. 复制算法

复制算法将可用内存容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，则将存活的对象复制到另一块上面，然后再把已用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配也不存在内存碎片等复杂问题。

GC2.jpg

现在的商业虚拟机都是使用该算法来回收新生代，但不是按照1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活的对象一次性地复制到另外的Survivor空间，最后清理掉Eden和使用过的Survivor空间。

GC3.jpg

PS：我们没办法保证每次回收都只有不多于10%的对象存活，当To Survivor没有足够空间存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老年代。

复制算法适用于对象存活率不高的新生代，对于对象存活率较高的老年代，则存在以下不足：

  • 需要进行较多的复制操作，效率较低。
  • 需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况。

3. 标记-整理算法

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

GC4.jpg

4. 分代收集算法

当前虚拟机的垃圾收集都采用”分代收集“算法，这种算法并没有什么新的思想，只是根据对象存活周期的不同，将内存划分为几块。一般是将Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。

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

垃圾收集器

如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。

GC11.jpg

1. Serial收集器（新生代）

该收集器是单线程新生代收集器，采用复制算法，”单线程“并不仅仅说明它只会使用1个CPU或1条收集线程去完成垃圾收集工作，最重要的是它在进行垃圾收集时，必须暂停其他所有的工作线程，直到收集结束(StopTheWorld)。

GC5.jpg

优于其他收集器的地方：简单而高效（与其他收集器的单线程比），对于限定单个CPU环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得更高的单线程收集效率，适用于Client模式下的虚拟机。

2. ParNew收集器（新生代）

ParNew收集器是Serial收集器的多线程版本，采用复制算法，除了使用多线程进行垃圾收集外，其余行为(控制参数、收集算法、StopTheWorld、对象分配规则、回收策略)和Serial收集器完全一样。

GC6.jpg

该收集器是运行在Server模式下的虚拟机中首选的新生代收集器，除了Serial收集器，目前只有它能与CMS收集器配合工作。

3. Parallel Scavenge收集器（新生代）

Parallel Scavenge收集器是新生代收集器，采用复制算法，采用并行的多线程收集垃圾，类似于ParNew收集器。 所谓并行是指，多条垃圾收集线程并行工作，但此时用户线程仍然是处于等待状态。

GC6.jpg

与其他收集器不同，该收集器关注的是吞吐量，所谓吞吐量是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)。

Parallel Scavenge收集器提供了相应的参数供用户找到合适的停顿时间和吞吐量：

  • -XX:MaxGCPauseMillis

    控制停顿时间，大于0的毫秒数，收集器将尽可能保证内存回收花费时间不超过设定值。

    GC停顿时间缩短是牺牲吞吐量和新生代空间来换取的，值太小可能会导致新生代空间变小，也可能会导致收集更加频繁，从而吞吐量降低。

  • -XX:GCTimeRatio

    设置吞吐量大小，大于0且小于100的整数，垃圾收集时间占总时间的比率。

  • -XX:+UseAdaptiveSizePolicy

    开关参数，该参数打开后，不需要手工指定新生代的大小(-Xmn)、Eden与Survivor区的比例(-XX:SurvivorRatio)、晋升老年代对象大小(-XX:PretenureSizeThreshold)等细节参数, 虚拟机会根据当前系统的运行情况收集性能监控信息，动态调节参数以提供最合适的停顿时间或者最大的吞吐量，即GC自适应的调节策略。

4. Serial Old收集器（老年代）

Serial Old是Serial收集器的老年代版本，是单线程收集器，采用”标记-整理“算法。它主要有两大作用：一种用途是在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用，另一种用途就是作为CMS收集器的后备预案，在并发收集Concurrent Mode Failure时使用。

GC7.jpg

5. Parallel Old收集器（老年代）

Parallel Old是Parallel Scavenge收集器的老年代版本。使用多线程和”标记-整理“算法。

GC8.jpg

在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge + Parallel Old收集器。

6. CMS收集器（老年代）

CMS收集器是一种以获取最短回收停顿时间为目标的收集器，符合重视服务响应时间、系统停顿时间短的应用需求，同时它也是HotSpot虚拟机第一款真正意义上的并发收集器，第一次实现了让垃圾收集线程与用户线程(基本上)同时工作。

CMS收集器基于”标记-清除“算法，整个过程分为以下4个步骤：

  • 初始化标记

    暂停所有的其他线程，标记GCRoot能直接关联到的对象，速度很快。

  • 并发标记

    同时开启GC和用户线程，用一个闭包结构去记录可达对象。因为用户线程可能会不断的更新引用域，所以GC线程无法保证可达性分析的实时性，所以这个算法里会跟踪记录这些发生引用更新的地方。

  • 重新标记

    修正并发标记期间因为用户程序继续运行而导致标记发生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始化标记阶段稍长一些，但远比并发标记的时间短。

  • 并发清除

    开启用户线程，同时GC线程开始对标记的区域做清扫。

GC9.jpg

由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以总体上说，CMS收集的内存回收过程是与用户线程一起并发执行的。

CMS收集器主要优点是并发收集、低停顿，但仍有以下三个明显的缺点：

  • 对CPU资源敏感。

  • 无法处理浮动垃圾，可能出现Concurrent Mode Failure失败而导致另1次Full GC的产生。

    由于CMS并发清理阶段用户线程还在运行，伴随程序运行自然就还会有新的垃圾不断产，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理，只好留到下一次GC。

  • “标记-清除”算法会导致收集结束时会有大量的空间碎片产生。

7. G1收集器（新生代、老年代）

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

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

  • 初始标记

    标记一下GCRoots能直接关联到的对象，并且修改TAMS(Next Top at Mark Start)的值，让下一阶段用户程序并发运行时，能在正确的Region中创建新对象，这阶段需要停顿线程，但耗时很短。

  • 并发标记

    从GCRoots开始对堆中对象进行可达性分析，找出存活的对象，这段时间耗时较长，但可与用户程序并发执行。

  • 最终标记

    修正正在并发标记期间因用户程序继续运行而导致标记产生变动的那一部分标记记录。

  • 筛选回收

    首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划。

GC10.jpg

与其他GC收集器相比，具有以下特点：

  • 并行与并发

    G1收集器能充分利用CPU、多核环境下的硬件优势，使用多个CPU或者CPU核心来缩短StopTheWorld停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍可以通过并发的方式让Java程序继续执行。

  • 分代收集

    虽然G1收集器可以不需要其他收集器配合就能独立管理整个GC堆，但能够采用了不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。

  • 空间整合

    G1收集器从整体上看是基于“标记-整理”算法实现，从局部上看是基于“复制”算法实现。

  • 可预测的停顿

    G1收集器除了追求停顿外，还建立可预测的停顿时间模型，能让使用者明确再一个长度为M毫秒的时间片段内。

G1收集器与其他垃圾收集器堆内存布局的差异?

使用G1收集器时，Java堆的内存布局与其他收集器不同，它将整个Java堆划分为多个大小相同的独立区域(Region)，虽然还保留有新生代和老年代的概念，但是新生代和老年代不再是物理隔离的了，都是一部分Region（不需要连续）的集合。

G1收集器停顿时间模型的依据?

G1收集器能够建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小(回收所获得的空间大小以及回收所需时间的经验值)，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。

当对象引用跨新生代以及老年代或者跨Region(G1收集器)，如何避免全堆扫面？

在G1收集器中，Region之间的对象引用以及其他收集器中的新生代与老年代之间的对象引用，虚拟机都是使用Remembered Set来避免全堆扫面的。G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region之中(在分代的例子就是检查是否老年代中的对象引用了新生代的对象)，如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的Rememberd Set之中。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。

思考

1. JVM默认的垃圾收集器是哪个？

命令行: java -XX:+PrintCommandLineFlags -version

-XX:G1ConcRefinementThreads=8 
-XX:GCDrainStackTargetSize=64 
-XX:InitialHeapSize=332733248 
-XX:MaxHeapSize=5323731968 
-XX:+PrintCommandLineFlags 
-XX:ReservedCodeCacheSize=251658240 
-XX:+SegmentedCodeCache 
-XX:+UseCompressedClassPointers 
-XX:+UseCompressedOops 
-XX:+UseG1GC // 使用G1垃圾收集器
-XX:-UseLargePagesIndividualAllocation
java version "11.0.10" 2021-01-19 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.10+8-LTS-162)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.10+8-LTS-162, mixed mode)
avatar
文章
阅读
粉丝