解读

面试官把“4C8G 容器”与“每天 ≤1 次 Full GC”同时抛出，是在考察候选人能否把“资源受限、云原生、SLA”三个维度串起来：

1. 容器不是物理机，CPU 被 throttle、内存被 cgroup limit 是常态，任何一次 Full GC 带来的 Stop-The-World 都可能被放大为“健康检查失败→重启→雪崩”。
2. 每天 1 次以内，意味着不能靠“半夜定时重启”这种运维 trick，必须靠代码、JVM、基础设施三层联合调优，且调优结果可量化、可灰度、可回归。
3. 性能测试工程师要给出“可落地的验证方案”：压测模型、监控指标、通过准则、回退阈值，而不只是“调几个参数”。

知识点

1. 容器内存分布：JVM Heap + Metaspace + Code Cache + Direct Memory + Native + Container overhead ≤ 8 GB；必须给 OS PageCache、cgroup kmem、安全网留 1 GB 以上 buffer。
2. 分代回收与 Full GC 触发条件：Old 区占满、Metaspace 占满、System.gc()、Promotion Failure、Concurrent Mode Failure 等。
3. 常用低延迟收集器在容器下的表现：
   • CMS：碎片化+Concurrent Mode Failure 容易 Full GC，已过时。
   • G1：MaxGCPauseMillis 默认 200 ms，Humongous 对象分配与 Old 区占比 45% 触发 Mixed GC，调优空间大。
   • ZGC/Shenandoah：JDK 11+，<10 ms 停顿，但需额外 10–20% 内存 headroom，8 GB 容器下风险高。
4. 性能测试视角的量化指标：
   • 业务指标：TPS、RT、错误率 ≤ 0.1%。
   • GC 指标：Full GC 次数/天、单次 STW ≤ 200 ms、GC CPU 占用 ≤ 5%。
   • 资源指标：容器内存利用率 ≤ 85%、CPU throttle 次数 = 0。
5. 压测建模：基于真实流量回放，峰值 QPS 取业务高峰 1.2 倍，持续 8 h 稳定性场景 + 30 min 突发脉冲，观察 Old 区增长曲线。
6. 监控闭环：Prometheus + Grafana 采集 jvm_gc_collection_seconds_sum、jvm_memory_used_bytes、container_memory_working_set_bytes，告警阈值 Full GC > 0 且持续 1 min 即失败。

答案

回答采用“测试驱动 + 分层调优”五步闭环，每一步都给出可量化的通过准则，方便在面试时展开。

第一步：容量预算与基线建立

1. 预留 1.2 GB 给非 Heap（Metaspace 256 MB、Direct 512 MB、Native 300 MB、OS 200 MB），Heap 上限 ≤ 6 GB。
2. 采用 G1，启动参数：
   -Xms6g -Xmx6g -XX:MaxGCPauseMillis=100 -XX:+UseStringDeduplication -XX:G1HeapRegionSize=16m -XX:G1NewSizePercent=15 -XX:G1MaxNewSizePercent=25 -XX:InitiatingHeapOccupancyPercent=30
   目标：让 Mixed GC 提前、小步快跑，避免 Old 区一次性占满。
3. 基线压测：8 h 稳定性，初始 Full GC 2–4 次/天，记录 Old 区增速、对象晋升速率、Humongous 分配次数。

第二步：代码层减负——把“内存垃圾”变成“业务垃圾”

1. 大对象治理：
   • 把 ≥ 50 k 的 JSON 解析改为流式 Jackson + Reusable ObjectPool；
   • 把 1 MB 以上 byte[] 缓存改为堆外 DirectBuffer 池，用完后显式 release，避免 Humongous 区。
2. 缓存瘦身：
   • 本地 LRU 缓存最大条目数按“每 1 k 条目 ≈ 1 MB”估算，上限 200 k；
   • 引入 Caffeine 的 weakValue + expireAfterWrite，防止缓存泄漏。
3. 异步批处理：
   • 将“每请求实时写日志”改为“4 MB 批量刷盘”，减少临时大数组。
     代码走查后，基线重跑，Old 区增速下降 35%，Full GC 降到 1 次/天边缘。

第三步：JVM 层精细调优——把“必须 Full GC”变成“可以不 Full GC”

1. 关闭 System.gc() 兜底：-XX:+DisableExplicitGC。
2. 调大 Metaspace：-XX:MaxMetaspaceSize=384m，避免动态类加载触发 Full GC。
3. 降低 IHOP 到 25%，让 G1 Mixed GC 更早、更频繁，但每次回收量 < 200 MB，STW < 80 ms。
4. 打开 -XX:+UnlockExperimentalVMOptions -XX:G1MixedGCCountTarget=8 -XX:G1MixedGCLiveThresholdPercent=75，提高碎片整理效率。
   调优后 8 h 压测，Full GC 0 次，Old 区占用稳定在 40–50%，STW 99 分位 90 ms。

第四步：基础设施层兜底——把“容器 kill”变成“GC 自适应”

1. 设置容器资源 limit = request = 8 Gi，防止 Burstable 类型在节点压力大时被 OOMKill。
2. 打开 -XX:+UseContainerSupport -XX:MaxRAMPercentage=75，让 JVM 感知 cgroup 上限。
3. 配置 graceful shutdown：Spring Boot 的 server.shutdown=graceful + 30 s 优雅下线，在滚动发布时避免“Old 区瞬间暴涨→Full GC→健康检查失败”。
4. 引入 Kubernetes 的 vertical-pod-autoscaler 仅推荐模式，观察一周，若内存峰值 < 6.5 GB，则把 Heap 降到 5.5 GB，留更多 headroom 给堆外，进一步降低 Full GC 概率。

第五步：回归与签署 SLA

1. 用生产镜像流量回放 3 天，累计 72 h，Full GC 0 次，Old 区最高 55%，CPU throttle 0 次。
2. 输出《GC 调优报告》：包含压测模型、JVM 参数、代码改动清单、监控截图、回退方案（只需把 IHOP 调回 45% 即可）。
3. 与 DevOps 签署 SLA：后续版本若 Full GC > 1 次/天，则阻塞发布，需重新走性能门禁。

通过以上五步，可在 4C8G 容器场景下把 Full GC 次数稳定压到每天 1 次以内，且具备可灰度、可回退、可量化的测试闭环。

拓展思考

1. 如果业务允许 20% 吞吐损失，可试用 ZGC（-XX:+UseZGC -Xmx5500m -XX:+UnlockExperimentalVMOptions），在 8 GB 容器内把停顿压到 5 ms 以内，但需额外 1 GB 内存 headroom，如何设计 A/B 实验验证其收益？
2. 当节点混部大数据离线任务时，CPU 被 throttle 的风险升高，是否考虑把 GC 线程绑定到 cgroup cpuset 的隔离核，减少抢核？如何量化 throttle 下降对 GC 停顿的收益？
3. 若未来容器规格升级到 4C16G，是否继续保持“Heap 占 75%”的经验值？如何借助性能测试重新计算最优 IHOP，避免“内存大了反而 Full GC 更频繁”的陷阱？