jvm调参需匹配gc算法特性与业务目标：吞吐优先选parallel，低延迟选cms或g1，大堆可控停顿选g1或zgc；参数须结合堆结构、对象生命周期及gc日志联动优化。
调整JVM参数来适配不同GC算法，核心是匹配算法特性与业务目标：吞吐量优先选Parallel，低延迟选CMS或G1，大堆+可控停顿选G1或ZGC。参数不是孤立设置的，必须结合堆结构、对象生命周期和GC日志反馈联动优化。
明确目标再选回收器
不同GC算法有天然倾向性，强行用错参数会放大缺陷：
- Parallel GC适合后台批处理类应用——关注总吞吐量，可接受秒级STW；启用参数：
-XX:+UseParallelGC -XX:+UseParallelOldGC - CMS（JDK 9+已废弃）曾用于Web服务——追求短停顿，但易因并发失败触发Full GC；启用参数：
-XX:+UseConcMarkSweepGC（仅限JDK 8及更早） - G1是当前主流选择——兼顾可预测停顿与高吞吐，适合堆≥4GB的中大型服务；启用参数：
-XX:+UseG1GC（JDK 9+默认） - ZGC/Shenandoah面向超低延迟场景（亚毫秒级STW），需JDK 11+/17+，启用如：
-XX:+UseZGC
堆结构参数要配合算法逻辑
GC算法行为直接受堆分区影响，关键比例参数不能凭感觉设：
- 年轻代大小（
-Xmn或-XX:NewRatio）：G1不用显式设，但Parallel/CMS需谨慎。例如-XX:NewRatio=2表示年轻代:老年代=1:2，适合对象存活率低的场景 - 幸存区比例（
-XX:SurvivorRatio）：默认8（即Eden:S0:S1 = 8:1:1）。若对象熬过多次Minor GC才晋升，可调小该值（如4）增大Survivor空间，减少过早进入老年代 - 对象年龄阈值（
-XX:MaxTenuringThreshold）：默认15，表示经历15次Minor GC仍存活就进老年代。若监控发现大量对象在第5次就被晋升，可调低至5，避免Survivor区无效复制
针对性调优关键开关
每个回收器都有几个“杠杆型”参数，改一处可能显著改变行为：
- Parallel GC：
-XX:MaxGCPauseMillis=N（尽力把单次GC停顿压到N毫秒内），但会牺牲吞吐；-XX:GCTimeRatio=R（设定GC时间占总运行时间比，如9表示GC耗时≤10%） - G1 GC：
-XX:MaxGCPauseMillis=200（G1的核心目标参数，建议设200~500ms）；-XX:G1HeapRegionSize（Region大小，通常让堆均分为2048个Region，自动计算，不建议手动设） - CMS（历史参考）：
-XX:CMSInitiatingOccupancyFraction=N（老年代使用率达N%时启动并发收集，避免并发模式失败；常设70~80） - 通用底线：
-Xms和-Xmx务必相等，防止堆动态扩容引发额外GC；开启GC日志：-Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
验证必须靠数据，不是猜
调参后不看日志等于没调：
- 用
jdk/bin/jstat -gc <pid></pid>实时观察GC频率、耗时、各代容量变化 - 用GCViewer或GCEasy解析gc.log，重点关注Full GC次数是否下降、平均Minor GC间隔是否延长、老年代内存趋势是否平缓
- 若出现
GC overhead limit exceeded，说明GC花太多时间却回收太少——大概率是内存泄漏或新生代过小导致对象频繁晋升 - 若G1频繁出现
to-space exhausted，说明年轻代对象存活率高，需调大-XX:G1NewSizePercent或检查对象创建逻辑
