gc调优无通用解，必须在吞吐量、停顿时间、内存占用三者间权衡取舍：吞吐优先选parallel gc并增大堆，但停顿和内存上升；延迟优先用g1或zgc，但吞吐下降、内存开销增加；内存受限时需减小堆并调高新生代比例，但gc频率和full gc风险上升。
GC算法没有“绝对快”或“绝对稳”的通用解，性能表现始终落在吞吐量与停顿时间的张力线上——你压低一边，另一边大概率会抬升。
吞吐量高 ≠ 系统响应快
吞吐量指业务线程运行时间占总时间的比例。99% 吞吐量意味着每 100 秒里，GC 只占 1 秒。这适合离线任务、批量处理等对延迟不敏感的场景。但实现高吞吐往往靠“少而重”的回收策略：增大堆、减少 GC 频次，结果是单次停顿拉长（可能达 200–500ms），且老年代压力积累后 Full GC 更难收场。
- Parallel GC 是吞吐优先的典型选择，配合
-XX:GCTimeRatio=99可硬性约束 GC 时间占比 - 堆设得过大（如从 4G 到 16G），虽降低 GC 次数，却放大扫描范围和 STW 时长
- 并行线程数过多（
-XX:ParallelGCThreads）可能争抢 CPU，反拖慢应用线程
停顿时间短 ≠ GC 总开销小
停顿时间关注的是单次 STW 的长度，尤其对支付、游戏、API 网关这类交互系统，P99 停顿超过 100ms 就可能引发超时或卡顿。要压低它，就得“多而轻”：更频繁触发 GC、分片回收、并发执行。但这会增加 GC 总耗时、占用更多 CPU 和内存元数据空间。
- G1 用
-XX:MaxGCPauseMillis=100设目标，实际是让 JVM 动态调整回收 Region 数量和并发线程数 - ZGC 在 JDK 11+ 支持亚毫秒级停顿，但要求堆大小 2MB 对齐，且需手动设
-XX:SoftMaxHeapSize避免预留浪费 - Region 太小（如
-XX:G1HeapRegionSize=1M）易碎片化；太大（如 4M）又削弱停顿可控性
真正起作用的是你的应用行为
再好的 GC 算法也扛不住异常的对象分配模式。调参不是调数字，而是引导 JVM 适配真实负载：
- 突发大对象（如 >512KB 的 byte[]）直接进老年代，可能瞬间触发 Mixed GC 或 Full GC
- 新生代过小导致 YGC 过于频繁，平均停顿反而升高
- 元空间未设上限（
-XX:MetaspaceSize/-XX:MaxMetaspaceSize），动态类加载悄悄吃掉数百 MB - 对象晋升过早（Survivor 区太小或
-XX:MaxTenuringThreshold设太低），加速老年代填满
验证必须看运行态指标，不是配置清单
所有调优结论都要落到真实日志和监控上：
- 加参数启动：
-Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps - 用
jstat -gcutil <pid> 1000</pid>观察 YGC/FGC 频次、耗时、各代使用率变化趋势 - 上传 gc.log 到 gceasy.io 或 GCViewer，看停顿分布直方图和内存增长斜率
- 特别注意“最大停顿时间”，它比平均值更能反映用户体验断点
