JVM虚拟机参数怎么设置？核心思路落在三件事上：把堆内存的上下限定准、把垃圾回收器的选型做对、把GC日志的观测打开。多数业务系统在堆大小和回收器上做合理配置，就能拿回大部分性能收益，剩下的参数调整属于定位到具体瓶颈后的精修动作，不必一上来就堆满网上流传的“XX调优秘籍”。
动手设置前先理解JVM内存分区的职责
JVM参数看着多，实际高频调整的集中在运行时数据区的几个区域，新手最容易犯的错是把所有-X参数凑在一起,却不知道每项对应哪块区域。
| 区域 | 核心参数 | 默认表现 | 调错后的典型症状 |
|---|---|---|---|
| 堆内存 | -Xms、-Xmx | JDK8默认是物理内存的1/4 | 频繁Full GC，CPU飙升 |
| 新生代 | -Xmn、-XX:SurvivorRatio | 堆的1/3，默认比例8:1:1 | 对象过早晋升到老年代 |
| 元空间 | -XX:MaxMetaspaceSize | 默认无上限 | 元空间膨胀，内存被吃满 |
| 虚拟机栈 | -Xss | 平台默认1MB | 栈溢出，线程创建失败 |
堆内存是最容易理解也最影响稳定性的部分。-Xms是启动时申请的堆，-Xmx是堆能撑到的上限，两者不一致时，JVM会在运行期自动扩容和收缩，这个动作本身会触发STW，所以生产规范里普遍提倡把两者设为相同值,消除运行期抖动。
元空间是JDK8之后取代永久代的概念，存的是类元数据，很多团队只盯着堆，忽略元空间，结果类加载多的场景（如热部署、动态代理）把机器内存悄悄耗尽，给它设个上限,比等它失控后再救要省事得多。
JVM内存设置多少合适？按容器和业务类型估算
堆大小的设定没有统一公式，不同业务形态对内存的需求差异很大,下面给的是一套实践中反复验证的估算路径。
从物理机视角估算堆内存
行业共识认为，堆内存设置为物理内存的50%到70%是多数Web应用的合理区间，剩下的留给元空间、线程栈、JIT编译器以及操作系统页缓存，如果你总内存是16GB，堆给8GB到11GB之间比较常见，但要给堆外内存留有余地，特别是用了NIO、Netty这类堆外分配较多的框架时。
容器环境下改用比例参数
在Docker或K8s里跑Java服务，直接写死的-Xmx容易出问题，容器内存上限改动后，-Xmx常常忘记同步，JDK8u191版本之后，引入了-XX:MaxRAMPercentage和-XX:InitialRAMPercentage,按容器可用内存的百分比来限定堆大小。
java -XX:MaxRAMPercentage=75.0 -XX:InitialRAMPercentage=25.0 -jar app.jar这样容器内存从2GB升到4GB时，堆上限自动跟着变，不用重新改参数，如果还在用8u191以前的版本，建议尽快升级，旧版读取的是宿主机内存,容器限制了也白限制。
新生代比例设置的取舍
新生代设得越大，Minor GC频率越低，但老年代空间会被压缩，Major GC压力增加，多数情况下，新生代占堆的三分之一属于安全起点。-XX:SurvivorRatio=8表示Eden区与单个Survivor区的比例是8:1，这是较常见的配置，适用于大多数业务，如果系统里短命对象特别多,适当调大新生代能减少晋升到老年代的流量。
JVM垃圾回收器怎么选：延迟和吞吐量的权衡
垃圾回收器选型直接决定GC停顿的观感，JDK8默认的Parallel Scavenge看重吞吐量，JDK9之后G1成为默认，面向服务端多核大堆场景，选型上不用追新,按你的延迟敏感度来定。
| 回收器 | 适用场景 | 关键参数 | 特点 |
|---|---|---|---|
| Parallel | 批处理、离线任务 | -XX:+UseParallelGC | 吞吐量优先，停顿偏长 |
| G1 | Web服务、中大型堆 | -XX:+UseG1GC | 停顿可控，区域化回收 |
| ZGC | 超低延迟场景 | -XX:+UseZGC | 停顿通常在毫秒级 |
| Shenandoah | 低延迟替代方案 | -XX:+UseShenandoahGC | 与ZGC定位类似 |
G1的核心参数怎么给
G1最常调的参数是-XX:MaxGCPauseMillis，默认200毫秒，这个值不是硬性保证，而是G1的调优目标，设置不合理时会导致GC频繁但单次时间短，整体吞吐反而下降，经验做法是先保持200毫秒跑几天，看实际GC日志里的平均停顿和吞吐量,再决定往下压还是放松。
业内专家指出，G1对大堆的适配度优于Parallel，但堆小于4GB时两者的差距并不明显，去掉“G1一定更好”的执念,按场景选型更容易得到直观收益。
避免过度配置回收器参数
很多人喜欢把-XX:ParallelGCThreads、-XX:ConcGCThreads也一并改动，这两个参数控制GC线程数，默认情况下JVM根据CPU核数自适应，效果通常不差，手动调小会拖慢回收速度，调大又容易抢占业务线程，除非你用压测数据证明当前线程数确实不合理,否则保持默认是更稳妥的选择。
线上JVM卡顿怎么排查？用GC日志链路定位瓶颈
参数设好了，不代表一直风平浪静，线上出现卡顿、超时，不要急着拍脑袋加大堆内存,先用日志和数据说话。
把GC日志打开是第一步
JDK8及以后版本,推荐统一走统一日志风格：
-Xlog:gc:gc.log:time,level,tagsJDK8用：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/logs/gc.log日志里重点看三类信息：Minor GC频率、Full GC次数、单次停顿耗时，Full GC是卡顿的主要制造者，如果它出现得频繁，接下来才需要查是堆不够、对象泄漏,还是元空间触发了回收。
用工具验证参数的实际效果
日志拿到后,配合JDK自带工具做交叉验证：
- jstat -gcutil
1000 ：看各代内存使用率和GC耗时趋势。 - jmap -heap ：打印堆配置和当前使用情况,确认启动参数是否生效。
- jcmd
GC.heap_info ：获取更详细的堆区域分布信息。
定位到具体是年轻代频繁回收还是老年代增长过快后，再回过头调整对应的-Xmn、-XX:MaxGCPauseMillis或堆上限，每次只动一个变量，改完压测对比，不要同时改多个参数,否则根本分不清是哪一项起的作用。
参数调整后观察多久才算数
单次测试看不出问题，GC停顿本身存在偶发性，建议压测至少持续半小时，观察至少三轮GC周期，同时盯住接口TP99这种业务指标，参数改动的生效验证，以线上平稳运行两三天的数据为准,而不是看一次重启后没有报错就认定调优成功。
生产环境JVM参数怎么配置比较稳妥？
给一个经过较多场景验证的起步配置，适用于绝大多数Java 8的Web服务，2核4G容器环境可运行,8G堆以上的机器同样适用：
-Xms4g -Xmx4g
-Xmn1g
-XX:SurvivorRatio=8
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:MaxMetaspaceSize=512m
-Xlog:gc:/data/logs/gc.log:time,level,tags这个组合的核心逻辑：堆固定防抖动、新生代占堆四分之一、G1控停顿、元空间设上限防膨胀、GC日志常开，如果你的服务对延迟极度敏感，比如交易支付类，可以把MaxGCPauseMillis下调到100,然后观察吞吐折损是否在可接受范围内。
常见问题速答
JVM调优之后性能反而下降是为什么？
多数情况是参数之间产生了相互制约，典型例子是MaxGCPauseMillis设太短，G1被迫增加回收频率，总耗时反而上升；或者MaxRAMPercentage设太高，堆挤占了堆外内存，JIT编译和线程栈空间不足，整体吞吐被拖低，用两个版本的GC日志做对比，看停顿次数和吞吐量变化,比猜原因更高效。
修改JVM参数必须重启服务吗？
JVM大部分内存参数在启动时固化，运行时不能动态更改，想要不重启就调整堆或回收器配置，目前没有通用做法，能做的是先把参数改到启动脚本里，在下次发布或滚动重启时自动生效，有些参数如-XX:MaxHeapFreeRatio可以被jinfo动态修改，但改完也可能引发Full GC,实际收益很有限。
GC日志文件一直增长，需要处理吗？
需要，GC日志默认不会自动清理，常驻服务跑几个月后可能吃掉几GB磁盘，线上建议配合logrotate按天切割，保留最近7到15天即可，配置路径写入启动脚本,比事后手动删文件更省心。