java内存分配策略需均衡eden、survivor、老年代及非堆区域：eden过小致频繁minor gc，过大则加速对象晋升；大对象应直入老年代避免新生代震荡；survivor空间不足引发担保失败；元空间等非堆内存须显式限制并启用容器支持。
Java 内存分配策略直接影响对象创建速度、GC 频率、内存碎片程度和系统吞吐量。策略不合理时，哪怕堆总大小充足，也会因区域失配引发频繁 Minor GC、对象过早晋升、老年代快速填满，最终拖慢响应、抬高延迟。
Eden 区大小决定 Minor GC 频率
新对象默认分配在 Eden 区。如果 Eden 过小，少量对象就触发 Minor GC；如果过大，存活对象在 Survivor 区反复拷贝，加速年龄增长，提前晋升到老年代。
- 观察指标：用 jstat -gc
查看 YGC 次数和 YGCT（新生代 GC 耗时） - 调优建议：对短生命周期对象多的应用（如 Web 请求处理），适当增大 Eden（如 -XX:NewRatio=1 或 -XX:SurvivorRatio=6），减少 GC 次数
- 典型现象：YGC 频繁但每次回收量小，说明 Eden 不够用或 Survivor 太小留不住存活对象
大对象直入老年代可避免新生代震荡
超过 -XX:PretenureSizeThreshold 的对象（如大数组、缓存块）若被塞进 Eden，会立刻占满空间，迫使 Minor GC；更糟的是，它无法进入 Survivor，直接“卡”在 Eden 或复制失败后被迫晋升，加剧老年代压力。
- 适用场景：批量导入、日志缓冲、图像/视频处理等涉及 >1MB 对象的业务
- 配置示例：-XX:PretenureSizeThreshold=1048576（1MB），配合 G1 可改用 -XX:G1HeapRegionSize 控制大对象判定粒度
- 注意：该参数仅对 Serial/Parallel GC 生效；G1 中由区域大小隐式控制，ZGC/Shenandoah 不需要显式设置
新生代对象晋升策略影响老年代稳定性
对象在 Survivor 区每经历一次 Minor GC，年龄 +1；达到 -XX:MaxTenuringThreshold（默认 15）即晋升。但若 Survivor 空间不足，即使年龄未达标，也会被提前送入老年代——这叫“担保失败”，是 Full GC 的常见诱因。
- 风险点：SurvivorRatio 设置不当（如设为 12，导致 Survivor 过小）、或应用存在中生命周期对象（存活 3–5 次 GC），极易触发提前晋升
- 诊断方法：查看 GC 日志中的 age 分布（-Xlog:gc+age=debug），确认是否大量对象在 age=1 或 2 就晋升
- 缓解方式：调大 Survivor 空间（-XX:SurvivorRatio=6），或降低晋升阈值让对象“稳住”再走（如 -XX:MaxTenuringThreshold=6）
非堆内存分配失衡会绕过堆监控直接 OOM
元空间（Metaspace）、线程栈（-Xss）、直接内存（ByteBuffer.allocateDirect）、代码缓存等不归堆管理，但都计入进程 RSS 内存。容器环境下尤其危险：JVM 默认无视 cgroups 限额，可能因元空间无限增长或线程数飙升导致被 OS OOMKiller 杀死。
- 关键参数：-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m、-Xss256k、-XX:MaxDirectMemorySize=1g
- 容器适配：JDK8u191+ 或 JDK10+ 必须启用 -XX:+UseContainerSupport，并用 -XX:MaxRAMPercentage=75.0 替代固定 -Xmx
- 排查工具：jcmd
VM.native_memory summary 查看各区域实际占用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
