对象分配速率是决定新生代大小和新老代比例的核心依据，需通过jstat -gc实时采样eden变化计算（如200ms增800mb即4gb/s），结合ygc频率、survivor溢出、晋升年龄等日志特征动态调优，推荐优先使用g1 gc自动适配。
对象分配速率是决定新生代大小和新老代比例的核心依据，而不是凭经验拍脑袋设定。分配速率高但存活率低，说明需要更大的新生代来容纳短期对象；反之若大量对象快速晋升到老年代，则需检查是否新生代过小或存在内存泄漏。
用 JVM 参数和工具观测真实分配速率
启动时加上 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps，配合 jstat -gc
- 分配速率 = (Eden 当前使用量变化) ÷ 时间间隔，多次采样取稳定值
- 若 YGC 每 1–2 秒就触发一次，且每次回收后 Eden 几乎清空，大概率新生代偏小
- 若 YGC 后 Survivor 区频繁溢出（日志中出现 “to-space overflow”），说明对象晋升过快，可能需调大 Survivor 或降低晋升阈值
按分配速率反推新生代合理大小
目标是让一次 YGC 的间隔 ≥ 1 秒（避免 GC 太频繁影响吞吐），同时 Eden 区在 GC 前最多使用 70%~80%。假设实测分配速率为 300MB/s，那么 Eden 至少设为 300MB × 1.5s ≈ 450MB（留缓冲），再叠加两个 Survivor 区（通常各占 Eden 的 10%），新生代总大小约 540MB 起步。
- 新生代 = Eden + 2×Survivor，常用配置如 -Xmn512m 或 -XX:NewRatio=2（即新生代占堆 1/3）
- 不建议用 NewRatio 粗粒度划分，尤其在堆较大（>4GB）时，应显式指定 -Xmn
- SurvivorRatio 控制 Eden/Survivor 比例，默认 8 表示 Eden 占新生代 8/10，可调为 6 或 4 以增大 Survivor 容量，减少过早晋升
结合晋升行为校准新老代比例
观察 GC 日志中的 “tenuring threshold” 和 “age” 信息。如果大量对象在 age=1 或 2 就晋升，说明 Survivor 空间不足或对象生命周期比预期长；若老年代每分钟增长 50MB 且 Full GC 很少，说明当前比例尚可；若老年代每秒涨几 MB 并频繁触发 CMS 或 ZGC 回收，则需提高新生代占比或优化对象生命周期。
- 用 -XX:+PrintTenuringDistribution 查看各年龄对象分布，确认实际晋升年龄
- 若多数对象在第 2 次 YGC 后晋升，可设 -XX:MaxTenuringThreshold=2，避免无效驻留
- 老年代持续缓慢增长（如每小时+100MB）通常是正常缓存或长周期对象，无需调整；突增则要排查泄漏
动态验证与微调策略
调参不是一锤定音。上线后用 GCViewer 或 Prometheus + jvm_gc_collection_seconds_count 跟踪一周内 YGC 频率、平均暂停时间、晋升量变化。若 YGC 平均耗时 > 50ms 或单次晋升量 > 新生代 10%，说明新生代仍偏小或对象存活率异常。
- 每次只调一个参数：先调 -Xmn，稳定后再动 SurvivorRatio 或 MaxTenuringThreshold
- 生产环境建议开启 -XX:+UseG1GC，它能根据分配速率和暂停目标自动调节区域大小，比 Parallel GC 更适应动态负载
- 注意：JDK 17+ 中 ZGC 和 Shenandoah 对分配速率不敏感，但仍有“初始堆大小”和“并发 GC 触发阈值”需参考分配压力设置
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
