解读

国内一线互联网公司在容器化落地时，普遍把 内存回收 作为线上稳定性与成本优化的核心指标。面试官问“差异”，并不是想听概念罗列，而是想看候选人能否把 内核行为→Docker 配置→业务表现 串成闭环，并给出可落地的调优方案。回答时要抓住 回收触发门槛、回收粒度、感知方式、配置接口 四条主线，用线上真实场景举例，体现“能救火、能省钱”。

知识点

1. 回收门槛：v1 的 memory.limit_in_bytes 是 硬上限，内核直接走 OOM-kill；v2 的 memory.max 是 分层上限，先回收、再杀进程。
2. 回收粒度：v1 按 memory子系统 单独回收，可能 CPU 子系统还在狂奔；v2 统一在 cgroup v2 层级 做内存+IO 联动，回收更精准。
3. 感知方式：v1 只能通过 memory.usage_in_bytes 轮询；v2 提供 memory.events 文件，“max” 一行 即可判断是回收还是 OOM，适合 Prometheus exporter 零开销采集。
4. 配置接口：v1 需要写 memory.limit_in_bytes + memory.soft_limit_in_bytes 两个文件，且 soft_limit 在内核侧优先级低；v2 用 memory.high 做 异步回收阈值，memory.max 做 最终兜底，一条 echo 命令即可，Docker 20.10+ 已默认暴露。
5. 国内云厂商现状：阿里云 ACK 裸金属集群已 强制 cgroups v2，腾讯云 TKE 也在灰度，面试时主动提及可加分。

答案

“线上我们曾遇到 Java 容器在 v1 下频繁 OOM 重启的问题。根因是 v1 的 memory.limit_in_bytes 属于硬限制，一旦 page cache + RSS 触顶立即触发 OOM-kill，而 JVM 的 GC 还没来得及时释放堆外内存。切到 v2 后，把 memory.high 设为 80% memory.max，内核先异步回收 page cache 和匿名页，给 GC 争取 3~5 秒时间，OOM 次数从每天 20 次降到 0；同时通过 memory.events 的 “max” 指标做告警，比 v1 轮询 usage_in_bytes CPU 占用降低 70%。落地时只需在 Docker daemon.json 加 "features": {"cgroups": true} 并重启，无需改业务镜像，符合国内快速止血要求。”

拓展思考

1. 如果业务是 短时高频批处理，可以把 memory.high 调得接近 memory.max，减少回收带来的延迟毛刺；
2. 在 混合部署 场景，v2 的 memory.low 可给高优容器 锁定最小驻留集，低优容器触发回收时先被剃头，实现 离线不扰在线；
3. 国内信创 ARM 服务器内核版本普遍 ≥5.10，cgroups v2 已全量开启，面试时可主动提出“已在鲲鹏 920 环境验证”，体现对国产化平台的适配经验。