多核cpu下jvm垃圾回收优化核心是匹配硬件并行能力，需选用parnew、parallel、g1或zgc等支持并行/并发的回收器，合理配置线程数、内存布局及region大小，并通过gc日志和cpu监控验证多核利用率。
多核 CPU 环境下，JVM 垃圾回收算法的优化核心不是替换算法本身，而是让回收行为与硬件并行能力匹配——重点在于选择支持并行/并发执行的回收器，并合理配置其线程数与内存布局，避免单线程瓶颈和过度竞争。
选对回收器：从 Serial 到 ParNew、Parallel、G1 的演进逻辑
Serial 是单线程回收器，哪怕 CPU 有 32 核，它也只用 1 个线程做 Young GC，其余核心闲置。ParNew 和 Parallel GC 都是多线程新生代回收器，区别在于 ParNew 通常配合 CMS 使用（已废弃），而 Parallel GC（吞吐量优先）默认启用多线程，线程数默认为 CPU 核心数或略少。G1 则更进一步：它本身支持并行标记、并发清理，并能按 Region 分片处理，天然适配多核。
- 4–8 核服务器：ParNew + CMS（仅限旧版本 JDK 8u40 前）或 Parallel GC 已足够；
- 16 核以上、堆内存 ≥16GB：G1 是更稳妥的选择，它能动态调整并发线程数，避免 STW 时间失控；
- JDK 17+ 生产环境：ZGC 或 Shenandoah 可考虑，它们几乎全程并发，STW 控制在毫秒级，但需权衡稳定性与 JDK 版本兼容性。
调优关键参数：让线程数真正“跑满”CPU
光开启多线程不够，线程数配置不当反而引发上下文切换开销。Parallel GC 默认使用 -XX:ParallelGCThreads=N，N 通常等于 CPU 核心数；但若系统同时运行其他高负载进程，可适当下调（如设为 N−2）。G1 的并发线程由 -XX:ConcGCThreads 控制，默认值约为 ParallelGCThreads 的 1/4，一般无需手动调高——过高会导致应用线程抢资源。
- 确认实际生效线程数：启动时加 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps，观察 GC 日志中 “Using X threads” 字样；
- 避免线程数 > 物理核心数：超线程（Hyper-Threading）带来的逻辑核不建议全用，尤其在高吞吐场景下易引发缓存争用；
- Young GC 频繁时，可微调 -XX:MaxGCPauseMillis（G1）或 -XX:GCTimeRatio（Parallel），让 JVM 主动平衡吞吐与停顿。
内存结构适配：分代与 Region 划分要贴合多核调度
新生代采用复制算法，天生适合并行：多个线程可各自扫描 From 区不同地址段，把存活对象复制到 To 区不同目标区域，互不干扰。老年代若用标记-整理，移动对象需同步，容易成为瓶颈——所以 G1 放弃全局整理，改为只对部分 Region 整理，其余 Region 并发回收，大幅降低锁竞争。
- 新生代大小不宜过小：太小导致 Young GC 过于频繁，线程启动/销毁开销占比上升；
- G1 的 Region 大小（-XX:G1HeapRegionSize）建议设为 1–4MB，过大则单 Region 扫描耗时长，过小则管理开销大，影响并行粒度；
- 避免堆内存跨 NUMA 节点分配：若服务器为多路 CPU（如双路 Intel Xeon），启用 -XX:+UseNUMA 让对象分配尽量靠近对应 CPU，减少远程内存访问延迟。
监控验证：用数据判断是否真“利用了多核”
不能只看 GC 次数或时间下降，要确认 CPU 利用率是否被有效转化为回收效率。通过 jstat -gc
- 如果 GC 线程总占用率长期低于 50%，说明回收器未饱和，可能线程数不足或堆设置不合理；
- 如果 GC 线程 CPU 占用高但 GC 时间没缩短，可能是内存碎片严重或对象晋升过快，需检查 Eden/Survivor 比例（-XX:SurvivorRatio）或老年代占用率；
- 生产环境建议开启 -Xlog:gc*,gc+heap=debug,jvm+perf=debug:file=gc.log:tags,uptime,time,level（JDK 10+），日志中会明确记录各阶段线程数与耗时。
