JVM: GC过程总结(minor GC 和 Full GC)

JVM: GC过程总结(minor GC 和 Full GC)

引用

CSDN

1.

https://blog.csdn.net/weixin_42615068/article/details/102813947

JVM中的垃圾回收机制是Java开发者必须掌握的重要内容之一。本文详细介绍了minor GC和Full GC的区别、过程以及触发条件，帮助读者深入理解JVM的内存管理和垃圾回收策略。

一、minor GC 和 Full GC 区别

• 新生代 GC（Minor GC）：指发生新生代的垃圾收集动作，Minor GC 非常频繁，回收速度一般也比较快。
• 老年代 GC（Major GC/Full GC）：指发生在老年代的 GC，出现了 Major GC 经常会伴随至少一次的 Minor GC（并非绝对），Major GC 的速度一般会比 Minor GC 的慢 10 倍以上。

二、minor GC 过程详解

1. 在初始阶段，新创建的对象被分配到 Eden 区，Survivor 的两块空间都为空。
2. 当 Eden 区满了的时候，minor garbage 被触发。
   
3. 经过扫描与标记，存活的对象被复制到 S0，不存活的对象被回收，并且存活的对象年龄都增大一岁。
4. 在下一次的 Minor GC 中，Eden 区的情况和上面一致，没有引用的对象被回收，存活的对象被复制到 Survivor 区。当 Eden 和 S0 区空间满了，S0 的所有的数据都被复制到 S1，需要注意的是，在上次 minor GC 过程中移动到 S0 中的两个对象在复制到 S1 后其年龄要加 1。此时 Eden 区 S0 区被清空，所有存活的数据都复制到了 S1 区，并且 S1 区存在着年龄不一样的对象，过程如下图所示：
5. 再下一次 Minor GC 则重复这个过程，这一次 Survivor 的两个区对换，存活的对象被复制到 S0，存活的对象年龄加 1，Eden 区和另一个 Survivor 区被清空。
   
6. 再经过几次 Minor GC 之后，当存活对象的年龄达到一个阈值之后（-XX：MaxTenuringThreshold 默认是 15），就会被从年轻代 Promotion 到老年代。
7. 随着 Minor GC 一次又一次的进行，不断会有新的对象被 promote 到老年代。
8. 上面基本上覆盖了整个年轻代所有的回收过程。最终，Major GC 将会在老年代发生，老年代的空间将会被清除和压缩（标记-清除或者标记整理）。

从上面的过程可以看出，Eden 区是连续的空间，且 Survivor 总有一个为空。经过一次 GC 和复制，一个 Survivor 中保存着当前还活着的对象，而 Eden 区和另一个 Survivor 区的内容都不再需要了，可以直接清空，到下一次 GC 时，两个 Survivor 的角色再互换。因此，这种方式分配内存和清理内存的效率都极高，这种垃圾回收的方式就是著名的“停止-复制（Stop-and-copy）”清理法（将 Eden 区和一个 Survivor 区仍然存活的对象拷贝到另一个 Survivor 中），这不代表着停止复制清理法很高效，其实，它也只在这种情况下（基于大部分对象存活周期很短的事实）高效，如果在老年代采用停止复制，则是非常不合适的。

老年代存储的对象比年轻代多得多，而且不乏大对象，对老年代进行内存清理时，如果使用停止-复制算法，则相当低效。一般，老年代用的算法是标记-压缩算法，即：标记出仍然存活的对象（存在引用的），将所有存活的对象向一端移动，以保证内存的连续。在发生 Minor GC 时，虚拟机会检查每次晋升进入老年代的大小是否大于老年代的剩余空间大小，如果大于，则直接触发一次 Full GC，否则，就查看是否设置了 -XX:+HandlePromotionFailure（允许担保失败），如果允许，则只会进行 Minor GC，此时可以容忍内存分配失败；如果不允许，则仍然进行 Full GC（这代表着如果设置 -XX:+Handle PromotionFailure，则触发 Minor GC 就会同时触发 Full GC，哪怕老年代还有很多内存，所以，最好不要这样做）。

整体描述

大部分情况，对象都会首先在 Eden 区域分配，在一次新生代垃圾回收后，如果对象还存活，则会进入 s1(“To”)，并且对象的年龄还会加 1(Eden 区->Survivor 区后对象的初始年龄变为 1)，当它的年龄增加到一定程度（默认为 15 岁），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。经过这次 GC 后，Eden 区和 "From" 区已经被清空。这个时候，“From" 和 "To" 会交换他们的角色，也就是新的 "To" 就是上次 GC 前的 “From”，新的 "From" 就是上次 GC 前的 "To"。不管怎样，都会保证名为 To 的 Survivor 区域是空的。Minor GC 会一直重复这样的过程，直到 “To” 区被填满，"To" 区被填满之后，会将所有对象移动到年老代中。

三、GC 触发条件

• Minor GC 触发条件：Eden 区满时
• Full GC 触发条件：
  1. 调用 System.gc 时，系统建议执行 Full GC，但是不必然执行
  2. 老年代空间不足
  3. 方法区空间不足
  4. 通过 Minor GC 后进入老年代的平均大小大于老年代的可用内存
  5. 由 Eden 区、From Space 区向 To Space 区复制时，对象大小大于 To Space 可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小。

四、对象进入老年代的四种情况

1. 假如进行 Minor GC 时发现，存活的对象在 ToSpace 区中存不下，那么把存活的对象存入老年代
2. 大对象直接进入老年代
   假设新创建的对象很大，比如为 5M(这个值可以通过 PretenureSizeThreshold 这个参数进行设置，默认 3M)，那么即使 Eden 区有足够的空间来存放，也不会存放在 Eden 区，而是直接存入老年代
3. 长期存活的对象将进入老年代
   此外，如果对象在 Eden 出生并且经过 1 次 Minor GC 后仍然存活，并且能被 To 区容纳，那么将被移动到 To 区，并且把对象的年龄设置为 1，对象没"熬过"一次 Minor GC(没有被回收，也没有因为 To 区没有空间而被移动到老年代中)，年龄就增加一岁，当它的年龄增加到一定程度(默认 15 岁，配置参数 -XX:MaxTenuringThreshold)，就会被晋升到老年代中
4. 动态对象年龄判定
   还有一种情况，如果在 From 空间中，相同年龄所有对象的大小总和大于 Survivor 空间的一半，那么年龄大于等于该年龄的对象就会被移动到老年代，而不用等到 15 岁(默认)：

五、空间分配担保

在发生 Minor GC 之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么 Minor GC 可以确保是安全的。如果不成立，则虚拟机会查看 HandlerPromotionFailure 这个参数设置的值(true 或 flase)是否允许担保失败(如果这个值为 true，代表着 JVM 说，我允许在这种条件下尝试执行 Minor GC，出了事我负责)。如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试进行一次 Minor GC，尽管这次 Minor GC 是有风险的；如果小于，或者 HandlerPromotionFailure 为 false，那么这次 Minor GC 将升级为 Full GC

如果老年代最大可用的连续空间大于历次晋升到老年代对象的平均大小，那么在 HandlerPromotionFailure 为 true 的情况下，可以尝试进行一次 Minor GC，但这是有风险的，如果本次将要晋升到老年代的对象很多，那么 Minor GC 还是无法执行，此时还得改为 Full GC。

注意：
JDK 6 Update 24 之后，只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行 minor GC，否则进行 Full GC.

参考资料

• https://www.jianshu.com/p/314272e6d35b
• https://blog.csdn.net/suifeng3051/article/details/48292193