2. JVM 内存模型与 Young GC 原理：堆内存结构、Eden/Survivor 区、Minor GC 触发条件
在迁移过程中，Young GC 频繁往往是系统性能劣化的第一个信号。要精准诊断其与慢查询的关联，必须首先理解 JVM 堆内存的物理划分与新生代垃圾回收的核心机制。本节将拆解堆内存结构、Eden/Survivor 区的协作模型，以及 Minor GC 的触发条件。
2.1 堆内存整体结构
JVM 堆是 Java 对象分配与回收的主战场，在 HotSpot 虚拟机中采用分代收集策略，将堆划分为三个逻辑区域：
| 区域 | 默认占比（JDK 8+） | 主要用途 | GC 类型 |
|---|---|---|---|
| 新生代（Young Generation） | 堆的 1/3 | 存放新创建的对象，生命周期短 | Minor GC / Young GC |
| 老年代（Old Generation） | 堆的 2/3 | 存放长期存活的对象，生命周期长 | Major GC / Full GC |
| 元空间（Metaspace） | 非堆，受本地内存限制 | 存放类元数据、方法内联信息 | 类卸载触发 |
迁移诊断要点： 迁移后若堆总大小不变，但新生代占比被误调（如 -XX:NewRatio 设置不当），会导致对象过早晋升老年代，引发 Full GC 与系统吞吐量骤降。
2.2 新生代内部结构：Eden 与 Survivor 区
新生代是 Young GC 的主战场，内部进一步划分为三个子区域：
- Eden 区（伊甸园）：绝大多数对象首次分配的地方。Eden 区通常占新生代总容量的 80% 左右。
- Survivor 0 区（S0 / From）：存放 Minor GC 后存活下来的对象。
- Survivor 1 区（S1 / To）：作为下一次 GC 的复制目标区，始终保证有一个 Survivor 区为空。
Eden 与 Survivor 的默认比例由 -XX:SurvivorRatio 控制，默认值为 8，即 Eden : S0 : S1 = 8 : 1 : 1。
2.3 Minor GC 触发条件
Minor GC（又称 Young GC）的触发条件非常明确，但在迁移环境中容易被忽视：
- Eden 区空间不足：当新对象尝试在 Eden 区分配时，若 Eden 剩余空间不足以容纳该对象，立即触发一次 Minor GC。
- TLAB 分配失败回退：线程本地分配缓冲区（TLAB）空间不足时，会尝试在 Eden 区直接分配，若仍失败则触发 Minor GC。
- 大对象直接进入老年代：超过
-XX:PretenureSizeThreshold的大对象不会触发 Minor GC，但会直接分配在老年代，间接影响老年代空间，后续可能引发 Full GC。
迁移陷阱： 迁移后若数据库连接池或线程池配置过大，导致短时间内创建大量临时对象（如 ResultSet 包装对象、网络缓冲区），Eden 区会迅速填满，Minor GC 频率从原来的每 10 秒一次骤升至每秒数次。此时必须结合慢查询日志，判断是否因 GC 停顿导致数据库连接超时或查询变慢。
2.4 Minor GC 执行过程（复制算法）
HotSpot 新生代采用 标记-复制算法，具体步骤如下：
| 步骤 | 操作 | 涉及区域 |
|---|---|---|
| 1. 标记 | 从 GC Roots 出发，标记 Eden 和 From 区所有存活对象 | Eden + S0（From） |
| 2. 复制 | 将存活对象按年龄顺序复制到 To 区（S1），年龄 +1 | Eden + S0 → S1 |
| 3. 清空 | 清空 Eden 和 From 区，回收所有不可达对象内存 | Eden + S0 |
| 4. 角色互换 | 原 To 区变为新的 From 区，原 From 区变为新的 To 区 | S0 ↔ S1 |
| 5. 晋升判断 | 若对象年龄超过 -XX:MaxTenuringThreshold（默认 15），或 To 区空间不足，则直接晋升到老年代 |
S1 → Old |
2.5 与慢查询关联的关键指标
在迁移过程中，以下 JVM 指标与数据库慢查询存在直接因果关系：
- Young GC 频率：正常值 < 1 次/秒；若超过 5 次/秒，说明 Eden 区过小或对象分配速率过高。
- Young GC 平均停顿时间：正常值 < 50ms；若超过 100ms，可能导致应用线程频繁阻塞，数据库连接池借出连接超时。
- Survivor 区溢出次数：若 From 区对象直接晋升老年代的比例升高，说明 Survivor 区配置不合理。
- 对象分配速率（Allocation Rate）：单位 MB/s，可通过
-XX:+PrintGCDetails或 GC 日志计算。
实战建议： 在迁移压测阶段，同时开启 GC 日志（
-Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps）和数据库慢查询日志（long_query_time=1s），将 GC 停顿时间戳与慢查询时间戳对齐，即可快速定位“GC 停顿 → 连接池借出超时 → SQL 执行变慢”的因果链。