jvm堆内存配置需先锁死总容量（-xms=-xmx≤物理内存70%），再依gc算法与并发特征协同设定分代比例：g1自动调优、zgc/shenandoah不分代、parallel/cms依赖newratio硬约束。

年轻代与老年代比例不是独立调节的“滑块”，而是必须锚定在物理内存边界内协同设计的约束系统。关键不在于“设多大”，而在于“在可用物理内存中，如何让分代结构既满足高并发对象潮汐特征，又不触发OS级内存压力”。

先锁死堆总容量，再谈比例

高并发系统对物理内存的占用非常敏感，若堆大小（-Xms/-Xmx）未与服务器可用内存对齐，极易引发Swap或OOM Killer干预。建议：

• 堆总大小 ≤ 服务器物理内存的 70%（预留至少2GB给OS、元空间、直接内存、线程栈等）
• 例如：32GB物理内存服务器，最大堆建议设为 -Xms22g -Xmx22g（而非24g）
• 务必关闭堆动态伸缩（-Xms 与 -Xmx 相等），避免GC期间因扩容失败导致Full GC或进程被杀

按并发流量特征反推新生代占比

高并发场景下，每秒创建数万短生命周期对象（如HTTP请求DTO、临时集合）是常态。此时新生代过小会引发Young GC风暴；过大则挤占老年代，导致晋升失败或Full GC。推荐策略：

• 观察单位时间对象分配速率（通过jstat -gc 或 GC日志中的 “EC” 和 “YGC” 频次）
• 若Eden区每1~2秒即满，且Young GC后存活对象少（-XX:NewRatio（如从3调至1.5或2）
• 若Survivor区频繁溢出、对象“过早晋升”（Promotion Failed），说明Survivor太小 → 同时调小 -XX:SurvivorRatio（如从8→6）并确认 -XX:MaxTenuringThreshold 合理（默认15通常够用）

老年代不是“备用仓库”，而是稳定性压舱石

高并发系统中，老年代承担着缓存、连接池、长周期聚合对象等关键数据。它不能靠“省出来”，而要主动预留：

• 老年代最小安全边界 ≈ 常驻对象总大小 × 1.5（含碎片与浮动垃圾）
• 可通过GC日志中Full GC前的老年代使用量（OGCMN/OGCMX）或JFR采样估算常驻对象规模
• 若老年代使用率长期 >75%，即使未Full GC，也已逼近临界——此时不应盲目增大NewRatio，而应检查是否存在内存泄漏或缓存未驱逐

结合收集器与物理内存做硬性校验

不同GC算法对分代边界的容忍度差异极大：

• G1（JDK9+默认）：弱化分代概念，-XX:NewRatio仅作为初始建议值，实际年轻代大小由G1自动弹性调整。重点应设 -XX:MaxGCPauseMillis=200 并监控“Mixed GC”占比
• ZGC/Shenandoah（低延迟首选）：完全不分代，无需配置NewRatio；但要求堆大小 ≥ 8GB，且物理内存需支持大页（HugePages）以规避TLB抖动
• Parallel / CMS（遗留系统）：严格依赖NewRatio。若NewRatio=2（新生代占1/3），则22GB堆对应新生代≈7.3GB —— 此时需确认单个Young GC停顿是否