Java应用的稳定运行高度依赖JVM的合理配置，很多线上故障表面看是代码问题，深挖下去却是虚拟机层面的资源分配失衡。JVM性能调优并不是神秘的黑魔法，它的核心在于理解内存分区、垃圾回收机制以及线程资源之间的制约关系。本文从实际可调的参数出发，帮助初学者建立系统的调优思路，而不是凭感觉修改启动脚本。
堆内存分区与基础参数解析
JVM堆是Java对象分配的主要区域，也是调优最先触及的地方。堆内部划分为新生代和老年代，新生代又细分为Eden区和两个Survivor区。大多数对象在Eden区诞生，经过几次垃圾回收仍存活就会被晋升到老年代。如果新生代过小，对象会过早晋升，老年代迅速填满从而频繁触发Full GC；反之若新生代过大，单次Minor GC的停顿时间会变长。理解这种平衡是调优的第一步。
最基础的参数是-Xms和-Xmx，它们分别设置堆的初始大小和最大大小。生产环境务必将两者设为一致，避免运行时堆伸缩带来的额外开销和停顿。另一个关键参数是-XX:NewRatio，它控制老年代与新生代的比例，例如设置为2表示老年代占堆的二分之一，新生代占三分之一。此外-XX:SurvivorRatio决定Eden与单个Survivor区的比例。下面是一段典型的启动参数示例：
java -Xms4g -Xmx4g -XX:NewRatio=2 -XX:SurvivorRatio=8
-XX:+UseG1GC -jar order-service.jar
上述配置将堆固定为4GB，老年代与新生代一比二，Eden和Survivor为一比八，并启用G1回收器。初学者常犯的错误是只设-Xmx不设-Xms，导致服务启动后堆逐步扩张，在流量高峰时触发扩容停顿。还有人盲目把堆调到十几GB，结果一次Full GC要停顿数秒，反而比合理小堆更糟糕。
垃圾回收器的选择与停顿优化
垃圾回收器决定了应用停顿时间和吞吐量的走向。JDK8及以前常用的有Parallel GC和CMS，JDK9之后G1成为默认，现代版本还引入了ZGC和Shenandoah。Parallel GC追求高吞吐量，适合后台计算型任务，但在大堆下停顿可能达到秒级。CMS以降低停顿为目标，却容易产生内存碎片并引发并发失败。G1则将堆切分为多个Region，可预测停顿模型让用户指定最大暂停时间目标。
对于大多数互联网接口服务，G1是稳妥的起步选择。通过-XX:MaxGCPauseMillis可以设定期望的最大停顿，比如200毫秒，G1会动态调整Region回收优先级来尽量满足。但这个值不是越低越好，过于激进的目标会让回收线程占用过多CPU，反而拖慢业务。下面的代码展示了如何在日志中观察GC行为：
java -Xms4g -Xmx4g -XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-Xlog:gc*:file=gc.log:time,level,tags
-jar user-center.jar
开启统一日志后，可以从gc.log中看到每次暂停的准确耗时和回收区域。如果发现Eden区回收频繁但老年代增长缓慢，说明短期对象多，可适当调大新生代；若老年代稳步上涨且Mixed GC变多，则要检查是否有大对象或缓存泄漏。不同回收器的调优侧重点不同，选错类型比不调更伤，因此先明确业务是吞吐优先还是延迟优先再动手。
线程栈与元空间等辅助调优项
除了堆和回收器，线程栈和元空间也常成为隐患。每个Java线程私有栈由-Xss控制，默认几百KB到1MB不等。高并发服务若创建上千线程，仅栈内存就可能吃掉数GB。通过适当调小-Xss到256KB往往能释放大量内存，但过小会引发StackOverflowError。元空间存放类元数据，由-XX:MaxMetaspaceSize限制，若动态生成类（如反射、代理）过多且未限上限，可能耗尽本地内存。
以下示例展示了对线程和元空间的基础约束，适合多数Web应用：
java -Xss256k -XX:MaxMetaspaceSize=256m
-XX:MetaspaceSize=128m
-Xms4g -Xmx4g -XX:+UseG1GC
-jar gateway.jar
调优时还应配合操作系统层面观察，例如用top或jstat确认线程数与内存走向。很多团队只盯堆使用率，却忽略元空间或直接内存，导致容器被OOM Killer终止。辅助参数虽不如堆显眼，却是整体稳定性的拼图。把分区、回收器、栈与元空间放在一起考量，才能算出贴合业务的真实资源需求，而不是孤立地改某一个数字。
综上，JVM调优入门并不要求背诵所有参数，而是先弄懂分区职责和回收原理，再用日志验证假设。从固定堆大小、选对回收器、约束栈与元空间这三步做起，大部分初级性能问题都能被化解。后续可逐步深入到对象逃逸分析、JIT编译日志等高级主题，但扎实的基础配置永远是第一步。