jvm内存调优需结合业务特征、gc行为与内存模式精准干预，从异常full gc或oom出发，区分内存泄漏、对象生命周期错配、堆外内存失控及gc策略失配等真实瓶颈，而非盲目调参。
JVM内存调优不是调几个参数就完事，关键是结合业务特征、GC行为和内存使用模式做针对性干预。真正有效的调优，往往从一次异常Full GC或OOM开始，而不是凭经验拍脑袋设-Xmx。
识别真实瓶颈：别把症状当病因
很多团队一看到“GC频繁”就立刻调大堆内存，结果只是延缓问题爆发。实际要先分清是哪类问题：
- 内存泄漏（对象持续增长，GC后无法释放）→ 查MAT支配树，找未清理的缓存、静态集合、监听器引用
- 对象生命周期错配（短命对象进老年代、长命对象卡在年轻代）→ 看GC日志中晋升大小、Survivor区占用率、年龄分布
- 堆外内存失控（Netty Direct Buffer、JNI、元空间膨胀）→ jstat -gcmetacapacity、NativeMemoryTracking（-XX:NativeMemoryTracking=detail）
- GC策略失配（比如用Parallel GC跑低延迟接口）→ 检查停顿时间P99是否超标，对比ZGC/G1的亚毫秒能力是否被忽略
年轻代配置：别只盯着-Xmn
年轻代大小不是越大越好。Eden过大会导致Minor GC单次耗时上升；过小又会触发频繁GC并加速对象晋升。关键看三个指标：
- Minor GC频率：理想区间是2–10秒一次，太密说明Eden不足或对象存活率高
- Survivor区使用率：长期高于70%说明S0/S1不够，对象被迫提前晋升；低于20%说明空间浪费，可适当压缩
- 晋升到老年代的平均大小：如果每次Minor GC都带几百MB进老年代，说明对象存活期远超预期，需检查缓存策略或对象复用逻辑
老年代与GC选型：按延迟目标倒推
选G1还是ZGC，不取决于堆大小，而取决于你能否接受单次停顿超过10ms：
- 要求P99
- 堆8–32GB、允许偶尔50–200ms停顿 → G1更成熟，重点调-XX:MaxGCPauseMillis（目标值）和-XX:G1HeapRegionSize（大对象对齐）
- 吞吐优先、单机CPU核数少 → Parallel GC仍适用，但必须配-XX:ParallelGCThreads=N，避免默认线程数过多抢资源
元空间与直接内存：容易被忽视的爆点
线上OOM不止发生在堆里。两类非堆溢出最常被漏查：
- Metaspace：动态生成类（Spring AOP代理、Groovy脚本、热更新框架）会持续申请元空间。固定上限-XX:MaxMetaspaceSize=512m + -XX:MetaspaceSize=256m防初始抖动
- Direct Buffer：Netty、Kafka客户端大量使用堆外内存。限制总用量加-XX:MaxDirectMemorySize=512m，并监控BufferPoolMetrics（通过JMX）
