JVM内存模型优化，本质是把堆、栈、方法区等区域的内存分配和回收节奏调成匹配你业务负载的形状，性能提升主要来自减少Full GC频率和避免内存溢出，而不是盲目加大堆内存。很多开发者一遇到性能瓶颈就加-Xmx，结果GC停顿反而更长，下面直接拆解，每个区域怎么影响性能，以及具体怎么调。
堆内存的分代结构，决定你性能调优的着力点
堆是JVM内存中最大的一块,几乎所有对象都在这分配，堆内部又分成新生代和老年代，新生代里还有Eden区和两个Survivor区，这个分代结构不是摆设，它直接决定了你调优时该动哪些参数。
新生代大小，影响对象晋升速度和GC频率
新生代是对象诞生的地方,朝生夕死的对象占绝大多数，如果新生代设置太小，Minor GC会频繁触发，每次回收后存活对象很快晋升到老年代，老年代压力增大，最终导致Full GC变多，如果新生代设置太大，又会挤占老年代空间，老年代提前触发回收，行业共识认为，新生代占堆总量的四分之一到三分之一是比较常见的起步值。
实操中可以通过-Xmn直接指定新生代大小，也可以用-XX:NewRatio设置老年代与新生代的比值，比如-XX:NewRatio=2表示老年代是新生代的2倍，新生代占堆的1/3，调整后观察GC日志里的Minor GC间隔和耗时，如果Minor GC还是很快且老年代增长缓慢，说明设置合理。
Survivor区比例，容易被忽略的晋升隐患
默认情况下Eden区和两个Survivor区的比例是8:1:1，这个比例来自IBM的统计，约90%的对象存活时间很短，但如果你的业务创建了较多中等存活时间的对象，8:1:1可能导致Survivor区不够用，对象被迫直接晋升到老年代，老年代垃圾越来越多，这时可以用-XX:SurvivorRatio调整，比如设成4，让Survivor区更大一些，观察GC日志中“desired survivor size”相关提示，如果持续出现晋升阈值被提高，说明Survivor容量不够。
JVM内存模型与性能调优：堆参数怎么配才算合理
很多人在网上搜“JVM内存模型与性能调优”，找到一堆参数列表但不知道怎么组合，其实核心逻辑很简单：先确定堆的总大小，再分配新生代和老年代的占比，最后针对GC收集器做细节调整。
堆总大小，别只看物理内存
堆最大容量-Xmx和初始容量-Xms建议设置为相同值，避免运行时动态扩容带来的性能损耗，堆大小参考公式：物理内存减去操作系统和元空间等占用，再考虑是否需要部署多个JVM实例，如果一台机器只跑一个Java服务，传统观点认为堆可以占到物理内存的60%到70%，但这几年云原生环境下容器内存受限，更稳妥的做法是先跑压测，观察内存曲线，找到平稳运行的临界值。
老年代空间，决定Full GC的破坏力
老年代主要存放大对象和长期存活的对象,如果老年代空间太小，Full GC频繁；太大则单次Full GC耗时很长，对于CMS收集器，老年代一般建议占堆的三分之二左右，对于G1收集器，老年代比例由-XX:G1NewSizePercent和-XX:G1MaxNewSizePercent动态调整，但整体堆大小仍然是核心，调优时盯着两个指标：Full GC的频率和平均停顿时间，如果Full GC一分钟超过一次，先看老年代的增长率，是不是有对象在过快堆积。
元空间和直接内存，别让非堆区域拖后腿
JDK8之后方法区变成了元空间,使用本地内存，默认没有上限，但实际部署时建议设置-XX:MaxMetaspaceSize，防止类加载过多导致系统内存被耗尽，直接内存由-XX:MaxDirectMemorySize控制，NIO和Netty用得多的服务必须显式设置，否则可能触发OutOfMemoryError，调优时注意，直接内存溢出时堆内存往往是正常的，排查方向容易跑偏。
实战场景：高并发下的内存优化策略
高并发是性能调优最常见的使用场景,并发一高，线程数量增加，每个线程的虚拟机栈和本地方法栈也会占用内存，默认栈大小是1MB（x86架构），如果你开了300个线程，光栈就占300MB，这个数字在微服务场景下相当可观。
减少线程栈大小，线程数翻倍的好办法
如果你的业务逻辑没有深递归,可以尝试-Xss256k或-Xss512k，Spring Boot应用里，线程数大多在线程池里受控，栈空间调小后线程数上去了，但不会导致StackOverflow，前提是你确认过递归深度，调优手段很简单：压测时降低-Xss
，观察是否出现栈溢出报错，没有就继续压。
大对象直接进老年代，避免反复复制
大对象在新生代会引起Eden区和Survivor区的频繁垃圾回收和复制操作,用-XX:PretenureSizeThreshold设置一个阈值，比如-XX:PretenureSizeThreshold=1m，超过1MB的对象直接分配到老年代，这样避免了新生代的复制开销，但也意味着老年代可能更快堆积，需要权衡，适合一次性大数组、大缓存对象的场景，不适合频繁创建短命大对象的业务。
从代码层面减少内存压力，比调参更划算
调参只是兜底,代码改掉才是根本，比如一次性加载全量数据到内存再过滤，改成流式处理；ThreadLocal用完不remove，导致线程池复用时的内存泄漏；循环内不断new大对象，改为复用容器，这些优化效果往往比调-Xmx更明显，调优的顺序应该是：先用工具定位问题代码，再确认是否需要调整JVM参数，而不是反过来。
JVM内存溢出怎么排查：一套可执行的操作路径
“jvm内存溢出怎么排查”这个场景几乎每个Java开发者都会遇到，内存溢出分为堆溢出、栈溢出、元空间溢出和直接内存溢出，表现不一样，排查思路也不同。
堆内存溢出，先抓heap dump
设置-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/logs，发生溢出时自动生成dump文件，然后用MAT或JProfiler打开，看Dominator Tree里占用最大的对象，从引用链找到是哪个业务代码创建的，多数情况下是集合类无限增长，比如缓存没设过期时间，或者数据库查询结果集过大，如果dump文件太大，可以先用jmap -histo:live <pid>快速查看堆中对象类型的计数和大小排序，优先排查占前几名的类型。
栈溢出，看异常堆栈的深度
栈溢出会抛出StackOverflowError，日志里打印的调用链就是问题代码所在，一般是无限递归、无限循环调用或者递归深度超过栈大小，如果确认代码没问题，再考虑调大-Xss，但更推荐优化算法，把递归改成迭代。
排查工具和命令，掌握一套就够
jstat -gc <pid> 1000：每秒输出一次GC信息，看Eden、Old区的占用和GC次数。jmap -heap <pid>
：查看堆内存配置和当前使用情况。
jcmd <pid> GC.heap_dump /path/dump.hprof：手动触发dump。jvisualvm：可视化监控，适合本地开发环境。
这套组合拳足够应对绝大多数内存问题,实际操作时先看jstat输出，如果Old区一直增长不清爽，说明有对象在堆里持续累积，再去抓dump具体分析。
JVM内存模型优化常见问题解答
为什么设置了大的-Xmx，Full GC反而更频繁？
大堆意味着老年代空间更大,但GC时扫描的引用链范围和复制成本也大，对象存活率没有变化时，堆越大，每次GC后老年代留下的空隙也越多，最终触发的Full GC虽然频率低了，但单次停顿时间可能翻倍，正确思路是先调低堆大小观察Full GC频率，再找业务层面的内存瓶颈，比如未关闭的连接、缓存膨胀。
G1收集器和CMS在内存调优上有什么区别？
CMS通过并发标记和并发清理减少停顿,但会产生内存碎片，最后需要一次Full GC做压缩，G1把堆划分成多个Region，可预测停顿，在JDK9之后成为默认，调优时CMS主要调新生代大小和老年代占用率触发阈值（-XX:CMSInitiatingOccupancyFraction），G1则重点调-XX:MaxGCPauseMillis目标停顿时间，以及Region大小（-XX:G1HeapRegionSize），G1适合大堆和多核环境，CMS更适合对CPU敏感、堆大小在4-6GB以内的老业务系统，行业专家指出，新项目直接使用G1即可。
怎么判断当前JVM内存参数已经调优到位？
看两个指标：Full GC频率低到业务可接受范围（比如几天一次），且每次Full GC停顿时间不超过设定的暂停时间目标；GC后老年代使用率回落到合理水位（比如低于20%），同时关注业务响应时间P99曲线，如果吞吐量和延迟都稳定，就不再需要继续调优，过度调优会增加维护成本，符合业务需要就是最优解。
JVM内存模型优化不需要追求极致的参数堆砌,而是通过观察GC行为和内存分布，找到匹配业务生命周期的平衡点，把堆、栈、元空间各区域的默认值视为起点，用jstat和jmap验证每一步调整的效果，最终让服务在稳定运行的基础上获得尽可能低的停顿。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/630236.html
