标记-整理算法在500G超大堆下性能崩塌的核心瓶颈是内存带宽饱和与NUMA跨节点访问延迟：300G→500G时GC停顿跳升30%+、real远大于user+sys、mem-loads激增但cache-misses反降、numastat显示remote access＞12%，均指向硬件级访存瓶颈而非算法缺陷。
在面试中用性能曲线证明标记-整理算法在500G超大堆下的硬件瓶颈，核心不是堆多大，而是抓住“内存带宽饱和”和“NUMA跨节点访问延迟”这两个真实制约点——它们会直接在GC停顿时间、吞吐量拐点、CPU利用率曲线上留下清晰指纹。
盯住三类关键曲线的异常拐点
不用画复杂模型，只用三组对比实验（堆设为100G / 300G / 500G，其他参数全固定：-XX:+UseParallelOldGC -XX:ParallelGCThreads=64，关闭压缩，禁用G1/ZGC），每组跑10轮Full GC，抓取以下三项指标作简易折线图：
- GC总停顿时间（秒）：横轴是堆大小，纵轴是平均Full GC耗时。当堆从300G→500G，停顿时间跳升30%以上（非线性增长），说明已越过内存带宽临界点；
- 用户态CPU利用率（%）：在GC过程中，top或pidstat显示CPU利用率卡在70–80%，但内存控制器（memctrl）中断频次飙升，说明CPU在等内存响应，不是计算瓶颈；
- TPS下降幅度（vs 100G基准）：业务压测下，500G堆的稳定TPS比100G低15–20%，且RT长尾（99%分位）明显拉长，指向NUMA远程内存访问导致的延迟毛刺。
用日志+监控交叉验证硬件信号
光看曲线不够，要从GC日志和系统层打出“硬件证据链”：
- 在-XX:+PrintGCDetails日志里找“[PSYoungGen: …] [ParOldGen: …]”后紧接“[Times: user=xx, sys=yy, real=zz]”中的real远大于user+sys（如real=8.2s，user+sys=5.1s），多出的3秒就是内存等待时间；
- 用perf stat -e mem-loads,mem-stores,cache-misses -p
采样GC期间数据：500G堆下mem-loads激增但cache-misses占比反降，说明瓶颈不在缓存，而在主存带宽； - 查numastat -p
：若local node hit率＜85%，remote node access占比＞12%，就坐实NUMA不均衡——整理阶段对象迁移跨节点，物理地址跳变引发延迟。
解释拐点时紧扣硬件机制，不甩术语
当面试官问“为什么300G还稳、500G就崩”，回答要直指物理限制：
- 标记-整理需遍历整个老年代做对象扫描+移动，500G堆意味着至少要顺序读写500GB内存；
- 单路DDR5-4800理论带宽≈38GB/s，但实际持续读写受制于内存控制器队列深度和通道争用，实测常压上限≈22GB/s；
- 300G堆Full GC约需13秒（300÷22≈13.6），500G则需23秒以上——曲线在此处陡升，不是算法不行，是硬件跑满了。
收尾点出务实对策，显工程判断力
不提“换ECC内存”这种空话，聚焦可落地的权衡：
- 拆大堆：用4×128G JVM实例替代1×500G，规避单节点带宽瓶颈，代价是跨JVM引用需序列化；
- 调整理粒度：-XX:OldPLABSize=4m（加大旧PLAB），减少整理阶段小对象频繁跨NUMA节点分配；
- 绑定CPU与内存节点：-XX:+UseNUMA -XX:NUMAInterleaving=off，强制JVM优先使用local node内存，降低remote access比例。
