-Xms与-Xmx设为相同值可避免堆动态扩容触发的Full GC及对象复制开销，推荐生产环境设为相等且不低于物理内存1/4（≤32GB）；G1需显式配置-XX:MaxGCPauseMillis=100~200ms才能发挥低延迟优势，jstat的GCT包含混合GC而YGC/FGC不统计，JDK17+部分参数行为变更或失效，调参须以GC日志为准。
为什么-Xms和-Xmx设成一样能减少GC压力
堆内存动态伸缩看似灵活，实则代价很高：每次扩容要触发Full GC，还要复制存活对象。把-Xms和-Xmx设为相同值（比如都设为4g），JVM启动时就直接分配完整堆空间，避免运行期反复调整。
常见错误是写成-Xms512m -Xmx4g——这会让JVM在负载上升时频繁扩容，尤其在高并发短生命周期对象场景下，容易引发STW时间突增。
- 生产环境建议比例：初始堆 = 最大堆，且不低于物理内存的1/4（但不超过32GB，避免指针压缩失效）
- 如果应用内存增长有明显峰谷，可配合
-XX:MaxRAMPercentage在容器中更安全地限制上限 - 注意：该设置对G1收集器效果显著，但对ZGC/Shenandoah影响较小，因后者不依赖堆连续分配
如何用-XX:+UseG1GC真正发挥G1优势
G1不是“开箱即用就快”，默认参数常导致吞吐下降或延迟毛刺。关键在于控制停顿目标和区域划分逻辑。
典型误配是只加-XX:+UseG1GC却不设-XX:MaxGCPauseMillis，结果G1退化为吞吐优先模式，单次GC耗时飙升到300ms以上。
立即学习“Java免费学习笔记（深入）”；
- 必须显式设置
-XX:MaxGCPauseMillis=200（推荐100~200ms区间），G1才按停顿目标反推年轻代大小和混合回收频率 - 避免
-XX:G1HeapRegionSize手动调大——除非你确认对象普遍>4MB，否则默认1~2MB区域粒度最平衡 - 观察
G1 Evacuation Pause日志中的“other”耗时，若占比超30%，说明字符串去重或类卸载等辅助操作拖慢了回收，需关掉-XX:-G1EnableStringDeduplication再验证
为什么jstat输出里GCT比YGC+FGC加起来还大
jstat -gc里的GCT（总GC时间）≠ YGC（年轻代次数）×单次平均耗时 + FGC（Full GC次数）×单次耗时。因为G1/ZGC等现代收集器的“混合回收”（Mixed GC）既不算YGC也不算FGC，但计入GCT。
例如G1日志中出现G1 Mixed GC，jstat会把它归入GCT，但YGC和FGC列完全不动——这就造成“GCT时间暴涨，但YGC/FGC数字很稳”的假象。
- 排查时优先用
java -Xlog:gc*:file=gc.log:time,tags（JDK11+）替代jstat，看真实事件类型 - 若混合回收频繁，检查
-XX:G1MixedGCCountTarget是否过小（默认8），导致过早触发；或-XX:G1OldCSetRegionThresholdPercent是否过高（默认10），让老年代回收太激进 - 容器环境下注意：
jstat读取的是JVM内部计数器，而cgroup memory limit可能触发内核OOM Killer，此时GCT不会增加，但进程直接被杀——得查dmesg
哪些JVM参数在JDK17+里已失效或行为突变
升级JDK后性能倒退，大概率踩中了废弃参数的兼容层陷阱。比如-XX:+UseParallelGC在JDK17仍可用，但-XX:ParallelGCThreads的默认值从“CPU核心数”变成“CPU核心数×5/8”，多核机器上反而线程数变少。
更隐蔽的是-XX:+UseStringDeduplication：JDK8需要G1才能用，JDK11+默认开启但仅作用于G1；到了JDK17，该选项被标记为deprecated，实际由-XX:+UseG1GC隐式控制，单独启用会报warning并忽略。
- JDK17起，
-XX:MaxMetaspaceSize不再限制Compressed Class Space，后者独立增长，可能导致元空间OOM被误判 -
-XX:+UseAdaptiveSizePolicy在G1下已无意义，G1完全自主调控年轻代，该参数仅对Parallel/Serial有效 - 所有
-XX:+UnlockExperimentalVMOptions相关参数（如-XX:+UseZGC）在JDK15+转正，去掉unlock选项，否则启动失败
-XX:MaxGCPauseMillis=50，一边又用-XX:G1NewSizePercent=10硬压年轻代下限，结果G1反复失败重试，GC线程吃满CPU。调参前先看日志里到底发生了什么，而不是套模板。 
