堆内存调优核心在于匹配对象生命周期与GC行为：新生代过小致频繁Minor GC，过大拖慢老年代回收；-Xms与-Xmx需相等避免动态扩缩容卡顿；-Xmn、-XX:SurvivorRatio、-XX:MaxTenuringThreshold须联动配置；大对象直入老年代，监控应聚焦GC日志中的清空率、晋升失败及碎片化问题。
堆内存是JVM性能优化的主战场，调优效果最直接、影响最显著。关键不在堆大小本身，而在于对象生命周期分布与GC行为的匹配程度——新生代太小会频繁Minor GC，太大则拖慢老年代回收；比例不合理会导致对象过早晋升或长期滞留，加剧Full GC压力。
堆结构与分代逻辑必须吃透
HotSpot堆默认按1:2划分为新生代和老年代，新生代内部Eden:Survivor=8:1:1。这种设计基于“弱分代假说”：绝大多数对象朝生夕死。Eden区负责快速分配，Survivor区承担对象年龄筛选，老年代只收留真正长期存活的实例。若应用中短生命周期对象占比低于70%，或存在大量缓存型长生命周期对象，原生比例就会失衡。
核心参数要联动配置，不能孤立调整
- -Xms 与 -Xmx 必须相等：避免运行时堆动态扩容缩容带来的卡顿，尤其在高负载场景下，每次调整都触发Stop-The-World。
- -Xmn 决定新生代大小，但需同步校验 -XX:SurvivorRatio：比如设-Xmn2g后，若仍用默认ratio=8，则每个Survivor仅约111MB；若对象平均存活2轮就晋升，Survivor实际有效容量不足，易触发提前晋升。
- -XX:MaxTenuringThreshold 不宜硬设为15：默认值适用于通用场景，但若监控发现90%对象在3轮内死亡，设为3可大幅减少Survivor复制开销；反之，若大量对象稳定活过10轮，设为12比15更合理，避免无效等待。
对象分配行为直接影响GC效率
对象不是一律从Eden开始。JVM会根据对象大小做路径分流：
- 普通小对象 → Eden区分配
- 超过-XX:PretenureSizeThreshold阈值的大对象 → 直接进入老年代（绕过新生代，避免复制浪费）
- 连续Minor GC后仍存活的对象 → 按年龄阈值晋升至老年代
实践中，若日志频繁出现“Promotion Failed”，说明老年代空间不足以接纳本次晋升对象，此时要么调大老年代（减小-Xmn），要么降低晋升率（调高-XX:MaxTenuringThreshold或增大Survivor），而非盲目扩堆。
监控必须覆盖真实负载下的内存轨迹
压测或生产流量高峰时采集GC日志（-Xlog:gc*:file=gc.log:time,uptime,pid,tags），重点看三项：
- Minor GC间隔是否稳定，频率是否随QPS线性上升
- 每次Minor GC后Eden清空率是否＞95%，Survivor占用率是否持续＞70%
- Full GC是否由老年代碎片或元空间耗尽引发，而非单纯堆满
单靠堆使用率数字容易误判——比如堆使用率60%却频繁Full GC，大概率是老年代碎片化严重，此时压缩算法（如G1的Mixed GC）或调整-XX:G1HeapRegionSize才治本。
