JVM内存分代设计基于对象“朝生夕死”的统计规律，将堆划分为新生代（Eden+两个Survivor区）和老年代，以实现分而治之的高效GC：新生代用复制算法高频轻量回收短期对象，老年代用标记整理算法低频处理长期对象，从而显著降低停顿时间、提升吞吐量。
JVM 内存区域划分直接决定 GC 的行为模式、停顿时间与吞吐量。分代设计不是为了“看起来整齐”，而是基于对象生命周期的统计规律，让回收更精准、更轻量。
新生代结构影响 Minor GC 频率和速度
新生代划分为 Eden + 两个 Survivor 区，对象优先在 Eden 分配。这种结构带来三个关键影响：
- Eden 区满即触发 Minor GC，因此 Eden 大小直接决定 Minor GC 触发间隔；过大（如几十GB）会导致单次回收耗时显著上升，尤其在大内存机器上可能卡顿数秒
- Survivor 区容量过小，会频繁触发“幸存对象放不下→直接晋升老年代”，加速老年代填满，间接引发 Major GC
- 对象在 Survivor 区之间来回复制（年龄+1），复制成本低但依赖连续空间；若 Survivor 区碎片化或大小不匹配，会提前晋升，破坏分代假设
老年代布局决定 Full GC 的风险等级
老年代不参与日常 Minor GC，只在空间不足或晋升担保失败时介入，其结构特性放大了 GC 的代价：
- 没有“快速清空”机制，回收必须扫描大量长期存活对象，CMS 或 G1 的并发标记阶段仍需 STW 初始标记和重标记
- 大对象（如大数组、缓存块）若未走直接入老年代路径，会在新生代引发内存分配失败，被迫提前晋升，加剧老年代压力
- 老年代碎片化（尤其 CMS）会触发额外的压缩操作或退化为 Serial Old，一次 Full GC 可能持续数百毫秒甚至数秒
TLAB 与线程局部分配降低竞争但影响碎片分布
每个线程在 Eden 区内拥有私有 TLAB，这是 JVM 对高并发分配的关键优化：
- 避免多线程争抢 Eden 公共指针，减少同步开销；但 TLAB 过大易造成 Eden 内部小碎片，过小则频繁 refill，触发额外同步
- TLAB 分配的对象仍归属新生代整体管理，其碎片不影响 Survivor 晋升逻辑，但会略微降低 Eden 实际可用率
- TLAB 不适用于大对象（默认 > 256KB 跳过），这类对象绕过 TLAB 直接在 Eden 公共区或老年代分配，需单独关注其分配路径
元空间独立于堆，但间接影响 GC 稳定性
元空间（Metaspace）替代永久代后，不再占用堆空间，但它的行为仍与 GC 协同：
- 类加载过多导致元空间扩容，可能触发 Full GC（尤其 JDK 8 早期版本）；JDK 9+ 改进后更稳定，但仍需监控 -XX:MaxMetaspaceSize
- Full GC 会清理无用类（配合类卸载），但前提是该类加载器已不可达；若存在静态引用或 ThreadLocal 持有 ClassLoader，元空间内存无法释放，最终 OOM
- 元空间使用本地内存，不受 -Xmx 限制，但过度增长可能挤占系统资源，间接拖慢 GC 线程调度
