堆内存布局直接影响java程序稳定性，需结合eden、survivor、老年代协作机制判断溢出原因；分代流动异常、参数配置失配或gc日志异常均可能导致oom。
堆内存布局直接影响Java程序能否稳定运行，不是单纯“加-Xmx就能解决”的问题。理解Eden、Survivor、老年代的协作机制，才能判断溢出是配置不足、对象生命周期失控，还是GC策略失配。
堆内存分代结构决定对象去留路径
JVM默认按分代模型管理堆：新对象优先分配在Eden区；Minor GC后存活对象进入Survivor区（From/To）；多次GC仍存活的对象晋升至老年代。这个流动过程一旦被打破，就容易触发溢出。
- 如果Survivor空间太小，大量对象频繁“躲过”Minor GC却无法晋升，会在Survivor区反复复制，浪费空间并抬高GC压力
- 若对象“年龄”阈值（-XX:MaxTenuringThreshold）设得过高，本该进老年代的对象滞留在年轻代，挤占Eden空间，导致频繁GC甚至直接OOM
- 大对象（如超过-XX:PretenureSizeThreshold设定值的数组）会直接分配到老年代，跳过年轻代。若老年代碎片多、剩余连续空间不足，即使总空间够也会因无法分配而溢出
参数配置必须匹配实际对象行为
堆大小（-Xms/-Xmx）只是基础，真正影响溢出风险的是各子区域的相对比例和回收行为。
- -Xmn设置年轻代大小，它不是独立于-Xmx之外的额外内存，而是从最大堆中划出的一部分。比如-Xmx2g -Xmn512m，意味着老年代最多只有1.5G可用
- SurvivorRatio（如-XX:SurvivorRatio=8）决定Eden与一个Survivor区的比例。比值过大会让Survivor过小，加剧对象提前进入老年代；过小则Eden空间被压缩，Minor GC更频繁
- 使用G1或ZGC时，堆不再严格分代，但仍有“区域（Region）”概念。大对象可能独占多个Region，若连续空闲Region不足，同样抛出“Java heap space”
溢出日志里藏着布局失衡的关键线索
光看OutOfMemoryError不够，要结合GC日志判断是哪一环出了问题。
- 日志中频繁出现“Allocation Failure”，且每次Minor GC后Eden几乎清空但Survivor区持续高占用 → Survivor空间设计不合理或对象存活率异常高
- Full GC后老年代使用率仍接近100%，且之后很快再次Full GC → 老年代存在内存泄漏，或初始老年代空间预留不足
- 使用G1时出现“To-space exhausted”或“Evacuation Failure” → Region复制失败，常见于大对象分配或并发标记未及时完成
验证布局是否合理，不能只靠猜测
上线前用真实数据压测，观察GC行为和堆各区域水位变化。
- 开启详细GC日志：-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log
- 用jstat实时查看：jstat -gc
1s 查看S0C/S1C（Survivor容量）、EC（Eden容量）、OC（老年代容量）及对应使用量 - 配合堆转储分析：OOM时自动导出dump（-XX:+HeapDumpOnOutOfMemoryError），用MAT查看“dominator tree”，确认哪些对象占据Eden或老年代主体
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
