JVM中G1收集器的动态代际划分：Eden、Survivor与Humongous（大对象）Region

在JVM性能调优这件事上，G1收集器的大对象处理机制，一直是让人头疼的细节——很多人都在它身上踩过坑。我们先从它的核心设计说起。

G1采用逻辑分代、物理混布的Region机制，每个Region动态标记为Eden、Survivor、Old或Humongous；大对象≥50% Region大小时直接分配至连续Humongous Region，不参与常规GC流程，易导致碎片与停顿风险。

G1最让人印象深刻的设计，就是不搞固定的代际边界。它将整个堆划分成若干个大小相等的Region，每个Region在运行时根据需要动态标记为Eden、Survivor、Old或Humongous。这种“逻辑分代、物理混布”的思路，确实提升了内存利用率，但也让大对象分配这件事变得异常敏感——表面看没什么，背后全是坑。

Region的“身份”是如何实时切换的

每个Region一开始都是空闲状态。新对象来了，先被分配到标记为Eden的Region；等到Eden填满，触发Young GC时，存活对象会被复制到Survivor Region，也可能直接晋升到Old Region。晋升阈值由-XX:MaxTenuringThreshold控制，但实际是否晋升，还得看当前Region的空间压力和复制开销。这里有个关键点：Region没有永久归属。一次GC之后，原来Eden区的Region可能就变成了Survivor，甚至下一轮就直接转为Old区了。

• 年轻代由若干离散（不一定连续）的Eden+Survivor Region组成，总量在堆的5%～60%之间弹性伸缩
• Old Region不预占固定区域，而是由长期存活对象自然填充形成
• 所有Region都可被重用，类型随分配与回收行为实时切换

Humongous Region：专为大对象准备的“VIP通道”

当一个对象的大小超过单个Region容量的50%，G1就会把它识别为Humongous Object，并直接分配到Humongous Region。这里没有常规的“先Eden再晋升”路径。而且，这类Region必须是物理连续的——如果一个大对象超过了单个Region的容量，它就会占用多个连续的Humongous Region，每个Region最多只放一个Humongous Object。

• 比如Region大小为2MB，那么≥1MB的对象就算大对象
• Humongous Region不属于新生代，也不属于老年代，它是独立的第四类区域
• 分配失败的原因往往不是因为总内存不够，而是找不到足够连续的空闲Region

Eden与Survivor的协作机制

虽然Region物理上是分散的，但逻辑上Eden和Survivor的比例关系仍然被维持（默认8:1:1）。每次Young GC时，Eden和一个Survivor（from区）中的存活对象，会根据年龄判断去向：没达到晋升年龄的，复制到另一个Survivor（to区）；已经达到阈值、或者Survivor区装不下的，直接进入Old Region。

• Survivor区不固定为S0或S1，而是通过角色互换实现循环使用
• 对象年龄每经历一次Young GC加1，但G1更关注Region的空间成本，年龄只是参考因素之一
• 频繁分配大对象会导致Humongous Region碎片化，间接加剧Young GC压力

那些容易被忽略的分配隐患

大对象绕过Eden直接进Humongous，看起来是节省了复制开销，但如果它的生命周期很短，问题就来了——Humongous Region短期占用后又快速释放，外部碎片随之产生。更麻烦的是，G1没办法对Humongous Region做压缩整理，只能等着Full GC或混合GC来统一回收，这无疑会放大停顿风险。

• 监控建议：多留意G1HumongousAllocation日志，以及HumongousRegions数量的波动
• 调优方向：适当增大Region大小（-XX:G1HeapRegionSize），减少跨Region的大对象；或者限制大对象的创建频率
• 避免误判：别一看到老年代使用率高，就以为是老年代压力大——很可能是Humongous区域堆积造成的