Java GC选择需结合应用特征、JVM参数、堆布局与运行时行为综合判断，核心是理解吞吐量、延迟、内存占用三要素的权衡及各收集器适用边界，并通过GC日志和假设验证精准调优。
Java垃圾收集器（GC）不是“选一个就行”的简单配置，而是需要结合应用特征、JVM参数、堆内存布局与运行时行为综合判断的技术决策。掌握它，关键不在背诵算法名称，而在理解每种收集器的适用边界、调优逻辑和真实场景下的取舍。
明确收集器的核心差异：吞吐量、延迟、内存占用三要素
不同GC在设计目标上存在根本权衡：
- 吞吐量优先（如Parallel GC）：适合批处理、后台任务，允许较长的STW停顿，但单位时间内完成更多有效工作；
- 低延迟优先（如G1、ZGC、Shenandoah）：面向响应敏感型服务（如API网关、实时交易），控制单次停顿在毫秒级，代价是CPU开销略高、内存占用稍大；
- 内存效率优先（如Serial GC）：仅适用于单核小内存环境（嵌入式或测试机），不考虑并发，但极轻量。
没有“最好”的GC，只有“更适合当前负载”的GC。比如一个日均QPS 500、平均响应20ms的Spring Boot电商接口，G1通常是起点；而一个每小时跑一次、耗时8分钟的数据清洗Job，Parallel GC反而更稳。
看懂JVM启动参数背后的含义
参数不是堆砌，每个都对应具体行为：
立即学习“Java免费学习笔记（深入）”；
- -XX:+UseG1GC 启用G1，但不等于“已调优”——还需配合 -XX:MaxGCPauseMillis=200（目标停顿）和 -XX:G1HeapRegionSize（影响大对象分配）；
- -XX:+UseZGC 需JDK 11+，且要求开启 -XX:+UnlockExperimentalVMOptions（JDK 11–14）；ZGC真正优势在超大堆（≥64GB）下仍保持10ms内停顿，小堆反而可能不如G1；
- -Xmx 和 -Xms 设为相等可避免堆动态扩容带来的额外GC压力，尤其对G1/ZGC这类依赖固定区域划分的收集器更友好。
通过GC日志定位真实瓶颈
光看“是否发生GC”没意义，要读出模式：
- 频繁Young GC + 极少Old GC → 可能年轻代太小，或对象存活时间偏长（如缓存未及时清理）；
- Old GC频发且每次回收很少 → 存在内存泄漏，或大对象直接进入老年代（检查 -XX:PretenureSizeThreshold 和对象分配方式）；
- G1出现大量“Humongous Allocation”警告 → 大对象（如超大byte[]）触发特殊区域分配，易导致碎片和停顿飙升，应优化对象大小或启用 -XX:G1HeapRegionSize=4M 调整区域粒度。
开启日志推荐组合：-Xlog:gc*,gc+heap=debug,gc+ergo*=trace:file=gc.log:time,tags,uptime（JDK 10+），比旧版 -XX:+PrintGCDetails 更结构化、易解析。
调优不是调参数，而是验证假设
一次有效调优 = 观察现象 → 提出假设 → 修改最小变量 → 对比验证：
- 发现Full GC频繁 → 假设元空间不足 → 加 -XX:MaxMetaspaceSize=256m 并观察MetaSpace增长趋势；
- G1停顿偶尔超目标 → 假设并发标记线程不够 → 加 -XX:ConcGCThreads=4（默认为并行线程数的1/4）；
- ZGC出现长时间“Pause Mark Start” → 检查是否因系统内存压力大导致页回收慢，而非ZGC本身问题。
切忌同时改多个参数。JVM GC行为受操作系统、容器限制（如cgroup memory limit）、其他JVM子系统（JIT编译、监控代理）共同影响，需隔离变量。
