jvm gc算法选型必须匹配硬件条件：单核/小内存用serial，4–8核/4–16gb用g1，≥16核/≥32gb且linux 4.14+用zgc，容器需启用usecontainersupport并对齐内存限制。
JVM 性能优化中，GC 算法不是“越新越好”，而是要和硬件条件匹配。选错算法，哪怕参数调得再细，也会卡在停顿、吞吐或内存碎片上。
硬件资源决定 GC 行为边界
CPU 核心数、内存容量、是否启用 NUMA、磁盘 I/O 延迟（影响 GC 日志写入）、甚至是否运行在容器中（受 cgroup 内存限制），都会直接影响 GC 的实际表现。比如：
- 单核或双核 CPU 服务器上强行启用 G1 或 ZGC，反而因并发线程争抢 CPU 导致 STW 时间波动更大；
- 小内存（≤4GB）机器用 CMS，容易因老年代碎片化频繁触发 Full GC；
- 大内存（≥32GB）、多核（≥16 核）且延迟敏感的服务，ZGC 或 Shenandoah 才真正发挥优势；
- 容器环境未配
--memory限制时，JVM 可能按宿主机内存估算堆大小，导致 GC 频繁或 OOM Killer 杀进程。
不同 GC 算法对硬件的隐性依赖
- Serial / Parallel（吞吐优先）：适合单机批处理、后台任务。Parallel GC 默认开启多线程，但线程数 = CPU 核心数，若物理核心少（如 2~4 核），并行效果有限，反而增加上下文切换开销。
- CMS（低延迟旧选）：已从 JDK 14 起移除，不建议新项目使用。它依赖大量并发标记线程，对 CPU 持续占用高，在 CPU 资源紧张或虚拟化环境中易引发“并发模式失败”进而退化为 Serial Full GC。
- G1（平衡型主力）：要求堆内存 ≥6GB 才能体现分区优势；小堆下 Region 数量不足，反而退化为类似 CMS 的行为；需至少 4 核以上才能支撑其并发标记与混合回收线程。
-
ZGC / Shenandoah（超低延迟）：ZGC 要求 64 位 Linux 或 Windows，且必须启用大页（
-XX:+UseLargePages）才能稳定 sub-10ms 停顿；Shenandoah 在 JDK 12+ 默认可用，但对内存带宽敏感——若服务器内存通道少（如单通道 DDR4），并发转移阶段可能因带宽瓶颈拉长暂停。
匹配建议：按硬件档位选收集器
- ≤2 核 + ≤2GB 内存 → 用
-XX:+UseSerialGC（轻量、无额外线程开销） - 4~8 核 + 4~16GB 内存 →
-XX:+UseG1GC（默认开启自适应调优，配合-XX:MaxGCPauseMillis=200控制目标） - ≥16 核 + ≥32GB 内存 + Linux 4.14+ →
-XX:+UseZGC（需-XX:+UnlockExperimentalVMOptionsJDK 11~15，JDK 17+ 直接可用） - 容器部署（尤其 Kubernetes）→ 必须加
-XX:+UseContainerSupport（JDK 10+ 默认开启），并设-Xms/-Xmx与resources.limits.memory对齐，避免 JVM 误判可用内存。
别忽略底层硬件反馈
光看 GC 日志不够，要结合 vmstat 1 观察 cs（上下文切换）、si/so（swap）、r（运行队列）；用 perf top 看 GC 线程是否在 memmove 或 pthread_mutex_lock 上热点过高；容器内注意 cat /sys/fs/cgroup/memory/memory.stat 中 pgmajfault 是否突增——这往往意味着 GC 触发了大量缺页中断，说明堆太大或内存分配不连续。
硬件不是配置的背景板，是 GC 算法落地的物理约束。匹配度不到位，调参只是修修补补；匹配到位，很多“疑难 GC 问题”会自然消失。
