堆大小设置需匹配应用对象生命周期与硬件资源，-Xms与-Xmx应设为相等值以避免动态扩缩容开销；推荐设为物理内存的50%–75%，超大堆需警惕指针压缩失效与GC停顿陡增；年轻代大小影响Minor GC频率与停顿，G1下通常无需显式设置-Xmn，Parallel/CMS下建议占堆1/3–1/2；GC行为受堆参数、算法、晋升阈值及Survivor比例共同影响；必须通过GC日志与真实负载验证调优效果。
直接调大堆内存不等于性能变好，关键在于让堆大小匹配应用实际内存行为——避免频繁 GC，又不浪费系统资源。
初始堆（-Xms）和最大堆（-Xmx）设为相等
这是最常见也最有效的起点。JVM 启动后若堆需动态扩容，会触发额外开销和潜在的 Full GC；而固定大小能消除伸缩抖动，提升稳定性。
- 例如：一个稳定运行的 Web 服务，预估常驻对象约 1.2GB，可设
-Xms2g -Xmx2g，留出缓冲空间，避免刚过阈值就 GC - 不建议
-Xms512m -Xmx4g这类跨度大的配置，尤其在高负载时段容易因扩容卡顿
新生代（-Xmn）按比例合理划分
大部分对象朝生暮死，新生代太小会导致 Minor GC 频繁；太大则延长单次 GC 时间，还可能挤占老年代空间引发 Full GC。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 通用经验：新生代占堆总大小的 1/3～1/4。如堆设为 3GB，可配
-Xmn1g - 配合
-XX:SurvivorRatio=8（Eden:Survivor=8:1:1），确保 Survivor 区能容纳多数幸存对象，减少提前晋升到老年代
观察 GC 行为再调整，不是盲目加内存
堆调优必须基于真实运行数据，否则容易“越调越慢”。重点看三类指标：
立即学习“Java免费学习笔记（深入）”；
-
GC 频率与停顿：用
-Xlog:gc*:file=gc.log（JDK 9+）或-XX:+PrintGCDetails（旧版）收集日志，关注 Minor GC 间隔是否低于 10 秒、单次停顿是否超 100ms -
内存使用趋势：通过
jstat -gc <pid>查看 Eden 使用率是否长期 >90%、老年代是否缓慢上涨（暗示内存泄漏或晋升过早） - 外部表现：压测时对比吞吐量（TPS）和 P99 响应时间，若堆加大后响应时间反而上升，说明 GC 算法或代际比例已成瓶颈
配套调整元空间和线程栈
堆只是 JVM 内存的一部分，忽视其他区域可能导致新问题：
- 类加载多的应用（如 Spring Boot、热部署场景），需设
-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m，防元空间耗尽触发 Full GC - 高并发线程数多时，
-Xss256k比默认 1MB 更稳妥，避免线程创建失败或栈溢出；但不能过小，否则递归深时抛StackOverflowError
