JVM垃圾回收机制-通俗易懂版

原创

于 2025-04-29 15:00:22 发布 · 933 阅读

14 ·

CC 4.0 BY-SA版权

文章标签：

#jvm

前言

虽然网上有很多关于JVM垃圾回收机制的教程，但我自己还是决定写一篇能看懂的文章～如果有看不懂我就自己百度，大家有什么疑问也可以评论区交流～欢迎指点我的Error～

垃圾回收机制理解

首先我们要搞清楚，它是个啥玩意，以及GC两单词是如何缩写的。
我们的Java的垃圾回收机制（Garbage Collection, GC）是其内存管理的核心功能之一。通过GC，Java自动管理对象的生命周期，回收不再使用的对象所占的内存空间

内存分配与回收

我们来看看JVM垃圾回收机制前，先弄明白JVM内存的分配和回收的流程。JVM回收时的内存分布如下图所示：
新生代默认按Eden:S0:S1 = 8:1:1比例分配内存（可通过-XX:SurvivorRatio调整）。我们创建的新对象优先在Eden中去分配内存，然后S0/S1区是作为"缓冲区"存放Minor GC后存活的对象。随着新对象直接在Eden区不断的分配内存，当Eden区满时，会触发Minor GC（轻GC）。
接下来，JVM回去扫描Eden区域，标记所有被引用的对象，将其中存活的对象复制到S0区，此时S1区为空，对象年龄计数器设为1（通过-XX:MaxTenuringThreshold控制最大年龄，默认15）。
最后，JVM会释放Eden区所有已标记为死亡的对象空间。

当再次发生Minor GC时，JVM会扫描Eden区+S0区，然后标记所有存活对象，此时S1区还是空。JVM将Eden区+S0区中的存活对象复制到S1区，此时存活年龄对象+1，JVM清空Eden区+S0区，并且S0区和S1区功能互换（S0变成空区，S1变成存活区），形成类似斗地主那般“轮流坐庄”。

晕了晕了，来人，快来个流程拯救朕～

Eden区满 → 触发Minor GC
↓
扫描Eden+当前Survivor区 → 标记存活对象
↓
复制存活对象到空Survivor区 → 年龄+1
↓
清空原Eden+原Survivor区 → 交换S0/S1角色
↓
存活对象年龄达标或空间不足 → 晋升老年代

Questions1：刚提出，默认按Eden:S0:S1 = 8:1:1比例分配内存。S1区域这么小，怎么塞得满呀？
如果严格按照Survivor区1:1的比例设计，当发生Minor GC时，确实可能存在S1区空间不足以容纳Eden+S0区所有存活对象的情况。，但别急，JVM是很优秀的，记住一个东西叫空间分配担保机制。

空间分配担保机制

当JVM尝试将存活对象复制到另一个Survivor区（S1）时，若发现S1区剩余空间不足，则启动分配担保机制：JVM会预先检查老年代可用空间，若老年代有足够空间（默认需大于历次晋升对象的平均大小，该历史值通过-XX:TargetSurvivorRatio参数控制，默认50%），则直接将大对象或Survivor区放不下的对象晋升到老年代。

担保成功
如果老年代有足够空间，JVM会安全执行Minor GC，将Eden+S0区的存活对象复制到S1区，超出S1区容量的对象会直接晋升到老年代，且存活对象年龄+1

担保失败
如果老年代空间不足，JVM会尝试通过Full GC清理老年代空间
如果Full GC后仍然空间不足，则会抛出OutOfMemoryError

Minor GC完成后，新对象的分配仍会优先尝试在Eden区进行。只有当Eden区再次填满时，才会重复上述流程。

设计优势
这种机制通过"空间预担保"策略，在大多数情况下避免了因新生代对象晋升导致的老年代Full GC。只有当老年代确实没有足够空间时，才会触发更耗时的Full GC，从而实现了内存分配与回收的高效平衡。

大对象直接进入老年代

在Java虚拟机（JVM）的内存管理机制中，大对象（如超长字符串、大型数组等需要连续内存空间的数据结构）的分配策略具有特殊性：这类对象会直接进入老年代内存区域，而非常规的新生代空间。这种设计主要是为了避免以下两个核心问题：

1. 内存碎片化风险
新生代通常采用复制算法进行垃圾回收，频繁的内存整理操作可能导致内存碎片化。若将大对象放入新生代，其需要的连续内存空间可能因碎片化而难以满足，最终触发更耗时的Full GC。

2. 回收效率损耗
大对象在新生代的存活时间通常较短（如临时缓冲区），但每次Minor GC都需要扫描和复制这些庞然大物，会显著增加垃圾回收的停顿时间。

不同垃圾回收器对大对象的判定与分配策略存在差异化实现：

▎G1回收器的精准控制
通过双重阈值机制实现精细化管理：
区域大小基准：根据-XX:G1HeapRegionSize参数（默认2MB）划分堆内存为固定大小的区域（Region）
存活阈值判定：结合-XX:G1MixedGCLiveThresholdPercent参数（默认85%）设置的存活对象比例阈值
当对象大小超过半个Region（约1MB）且占用空间超过阈值时，即被判定为大对象直接进入老年代。这种设计使G1能够精确控制内存分配，避免跨Region分配带来的复杂性。

▎Parallel Scavenge回收器的动态适配
采用更灵活的智能决策机制：
无固定阈值：摒弃传统的大小阈值参数，转而通过-XX:ThresholdTolerance参数实现动态调整
自适应决策：JVM会持续监控堆内存使用情况（如Eden区剩余空间）和对象存活模式，结合历史分配数据（类似机器学习中的自适应算法），智能判断是否需要在老年代直接分配内存
这种设计使Parallel Scavenge在追求高吞吐量的场景中表现更优，能够根据应用负载特征自动优化内存分配策略。