jvm内存优化需从区域边界、堆内比例、晋升逻辑三方面系统调整：线程私有区关注-xss，共享区重点调堆与元空间；年轻代宜设为总堆1/3左右，eden:survivor=8:1:1；年龄阈值建议5～8，避免对象过早进入老年代。
JVM内存区域划分不合理，核心表现是对象过早进入老年代、频繁Young GC或Full GC、GC停顿时间长、堆外内存异常增长等。优化不是调几个参数就完事，而是要结合业务对象生命周期特征，从区域边界、比例关系、晋升逻辑三方面系统调整。
看懂区域边界：私有 vs 共享决定调优方向
线程私有区域（程序计数器、虚拟机栈、本地方法栈）不参与GC，但栈大小（-Xss）设得过大，会导致线程数受限；设得太小，易触发StackOverflowError。若应用大量使用递归或深度框架调用（如复杂规则引擎），可将-Xss从默认1M适当调至1.5M～2M，但需同步评估最大线程数上限。
线程共享区域（堆、方法区/元空间、运行时常量池）才是OOM和GC问题主战场：
- 堆（Heap）——对象分配主阵地，必须重点调优
- 元空间（Metaspace）——类加载元数据存放处，类动态生成多（如Spring Boot+大量代理、Groovy脚本）时容易OOM: Metaspace，建议显式设置-XX:MaxMetaspaceSize=256m～512m
- 运行时常量池属于方法区一部分，字符串常量过多（如未用intern的重复JSON key）会撑爆元空间，需配合StringTable清理策略
调准堆内比例：避免对象“误入”老年代
新生代太小 → Eden区很快填满 → Young GC频繁 → Survivor区压力大 → 大量对象因“Survivor空间不足”或“动态年龄判定”提前晋升老年代 → 触发Full GC。
老年代过大但新生代过小，本质是把本该在年轻代快速回收的短命对象，硬塞进回收成本极高的区域。合理比例参考：
- 年轻代 : 老年代 = 1:2 或 1:3（如总堆4G，年轻代设为1.2G～1.5G）
- Eden : From : To = 8:1:1（不建议手动改Survivor比例，除非有明确压测证据）
- 用 -Xmn1200m 直接指定年轻代大小，比只调 -XX:NewRatio 更可控
特别注意：-XX:PretenureSizeThreshold 设置过大（如设成1M），会让中等对象绕过Eden直接进老年代，反而加剧碎片和Full GC；建议保持默认0，让JVM自动判断，仅对确认的超大对象（如缓存的百MB级报表）才单独配置。
管住对象晋升：减少非必要老年代驻留
对象不该进老年代却进了，90%源于三个可调点：
- 年龄阈值过高：默认-XX:MaxTenuringThreshold=15，但多数业务对象活不过3次GC。可先试设为5～8，配合jstat -gc观察晋升数量变化
- Survivor区太小：若-XX:SurvivorRatio=8（即Eden占8份，两个Survivor共占2份），但实际存活对象体积接近Survivor容量，就会触发“担保失败”，直接进老年代。此时可微调-XX:SurvivorRatio=6，或更推荐用-Xmn固定年轻代后让比例自动适配
- 动态年龄判定太激进：默认“某年龄及以上对象总和＞Survivor空间50%”即晋升。若发现大量年龄2的对象集体晋升，说明该阈值偏低，可用-XX:TargetSurvivorRatio=90适当提高门槛（JDK8u60+支持）
验证与持续观察：别信“一次调优定终身”
所有调整必须基于真实流量下的GC日志分析：
- 加参数：-Xlog:gc*:file=gc.log:time,tags,uptime,level -Xlog:safepoint
- 关键看：Young GC频率是否下降、每次耗时是否稳定在10ms～50ms、老年代使用率是否缓慢上升而非阶梯式暴涨、Full GC是否归零
- 工具辅助：用jstat -gc -h10
1000 实时盯频率；用GCEasy或GCViewer解析日志趋势；内存突增时用jmap -histo排查大对象来源
不复杂但容易忽略：一次调优后，上线观察至少2个业务高峰周期，再结合监控（如Prometheus+JVM Exporter）确认GC Pause P99＜100ms、堆内存使用率长期稳定在60%～75%之间，才算真正落地。
