多核服务器上GC吞吐量性价比需在固定硬件与业务压力下，以单位资源消耗换取的有效应用吞吐量为衡量标准，综合GC开销占比、稳定性与可扩展性。
在多核服务器上评估不同垃圾收集器（GC）的吞吐量性价比，核心是**在固定硬件与业务压力下，对比单位资源消耗（如CPU时间、内存带宽、线程数）所换取的有效应用吞吐量提升**。不能只看“最大吞吐量”，也不能只看“暂停时间”，而要综合 GC 开销占比、稳定性和可扩展性。
明确吞吐量与性价比的量化定义
吞吐量通常指单位时间内完成的有效工作量（如请求处理数、事务数、计算任务数），而非 GC 自身速度。性价比则需归一化： - 吞吐量性价比 ≈ （应用有效吞吐量） / （GC 引起的 CPU 占用率 + 额外内存开销 + 线程调度成本） - 关键指标包括：GC 时间占比（%GCTime）、平均停顿（Avg Pause）、P99 停顿、并发标记线程数占用、晋升失败/Full GC 频次、堆外内存增长速率。 - 注意：多核下，“CPU 占用率”需区分用户态（应用代码）、内核态（GC 线程调度、TLAB 同步）、以及是否挤占应用线程（如 G1 的 Mixed GC 并发阶段仍会抢占 CPU）。
设计贴近真实负载的压测基准
避免使用 JMH 或简单循环创建对象——它们无法反映多核竞争下的内存分配模式和 GC 压力分布： - 使用生产级流量回放工具（如 gatling 或 tcpcopy），保持请求并发数 ≥ 逻辑核数 × 1.5； - 模拟混合对象生命周期：短期对象（HTTP 请求体）、中期对象（缓存中间结果）、长期对象（连接池、元数据缓存）； - 主动触发多线程争用场景：多个线程高频申请大对象（>2MB）、频繁 TLAB 耗尽、跨代引用写屏障密集写入； - 控制堆大小为物理内存的 60%~75%，避免 swap 干扰，同时保留足够空间观察 GC 扩缩行为。
横向对比时统一关键变量
不同 GC（如 ZGC、Shenandoah、G1、Parallel）机制差异大，直接比“-XX:+UseZGC”和“-XX:+UseParallelGC”不公平： - 固定堆总大小（如 16G），但允许各 GC 自主设置初始堆（-Xms）与元空间策略； - 统一启用 -XX:+PrintGCDetails -Xlog:gc*:file=gc.log:time,uptime,pid,tags（JDK 11+），并用 gcplot.com 或 GCViewer 提取结构化指标； - 对 ZGC/Shenandoah，额外监控 zgc-pause 和 shenandoah-pause 子事件，分离“STW 阶段”与“并发阶段 CPU 开销”； - 运行每轮测试 ≥ 30 分钟，跳过前 5 分钟预热期，取后 20 分钟稳态数据做统计（均值 + P95）。
识别多核特有瓶颈并归因
多核环境下，GC 性能拐点常来自非直观因素：
- 写屏障开销放大：G1/ZGC 的写屏障在高并发写入时引发大量缓存行失效（false sharing），可通过 perf record -e cache-misses 观察；
- 并发标记线程争抢全局锁：Shenandoah 的 marking_context 锁或 G1 的 HeapRegionManager 读锁，在 >32 核时可能成为瓶颈；
- NUMA 不感知分配：未启用 -XX:+UseNUMA 时，Parallel GC 可能跨节点分配 TLAB，导致远程内存访问延迟升高；
- GC 线程绑定不当：用 taskset 将 GC 线程绑定到特定核集（避开应用主线程），再对比绑核 vs 不绑核下的吞吐衰减比，可量化调度开销。
