Docker 容器运行一段时间后，内存持续上涨、响应逐渐变慢，甚至被 OOM Killer 终止，通常会被怀疑为内存泄漏。但内存曲线上升并不等于泄漏，堆内存、页缓存、临时文件、连接池和运行时分配策略都可能造成类似现象。要准确定位问题，需要从容器指标、cgroup 数据、宿主机状态和应用内部对象四个层面逐步排查。🔍
一、先判断是否真的发生内存泄漏
真正的内存泄漏通常具有三个特征：内存长期单向增长、业务流量下降后仍不回落、垃圾回收或缓存清理后依旧维持高位。如果内存随请求量周期性波动，并能在低峰期释放，更可能是正常的堆扩容或缓存行为。
排查时应同时观察容器内存使用量、内存上限、进程 RSS、缓存占用、交换空间、重启次数和 OOM 事件。不要只看某个瞬时值，而要查看数小时甚至数天的趋势。Docker 官方说明，容器指标由 Linux cgroup 负责统计，不同 cgroup 版本的文件布局存在差异，可参考 Docker 运行时指标文档。citeturn1search1
二、使用 Docker 原生命令快速监控
最直接的入口是 docker stats。它可以持续展示 CPU、内存使用量、内存限制、网络流量和块设备 I/O。重点关注“MEM USAGE / LIMIT”和“MEM %”：如果使用量持续接近限制且没有明显回落，说明需要进一步定位。
- docker stats 容器名：实时查看资源趋势。
- docker inspect 容器名：检查内存限制、交换空间和重启策略。
- docker top 容器名：确认容器内哪些进程占用资源。
- docker events：观察容器退出、重启及 OOM 相关事件。
生产环境不应只依赖人工查看。可以通过 cAdvisor 采集容器指标，再由 Prometheus 保存时序数据，使用 Grafana 绘制趋势并设置告警。建议针对内存占用率持续过高、增长速度异常、容器频繁重启和 OOMKilled 分别设置规则，而不是只设置一个固定阈值。📈
三、深入检查 cgroup 与 OOM 信息
Docker 的资源统计和限制最终由 cgroup 实现。可先检查 /sys/fs/cgroup/cgroup.controllers 是否存在，存在通常表示宿主机使用 cgroup v2。此时可重点查看容器所属目录中的 memory.current、memory.max、memory.stat 和 memory.events。
memory.current 表示当前计入 cgroup 的内存，memory.max 表示限制；memory.stat 能帮助区分匿名内存、文件缓存等类型；memory.events 可用于确认是否触发过内存上限或 OOM。若使用 cgroup v1，则对应文件名和目录结构不同，因此排查前必须确认版本。
同时检查宿主机日志，例如内核日志或 systemd 日志中的“Out of memory”“Killed process”等信息。若容器退出码为 137，也应结合 OOMKilled 状态和内核日志判断，不能仅凭退出码直接认定泄漏。Docker 默认不会限制容器可用资源，设置内存上限前应经过压力测试并保留合理余量，详见 Docker 资源约束说明。citeturn1search6
四、定位到具体进程和应用对象
如果 cgroup 数据显示匿名内存持续增长，应进入应用层分析。先通过 ps、top 或 smem 确认增长最快的进程，再选择与语言匹配的分析工具。
- Java：使用 jcmd、jmap、JFR 或堆转储，比较不同时间点的对象数量和引用链。
- Go：启用 pprof，观察 heap、allocs 和 goroutine，检查对象是否被长期引用。
- Node.js：生成 Heap Snapshot，对比对象数量、闭包和监听器变化。
- Python：使用 tracemalloc、objgraph 等工具检查分配位置与对象增长。
若文件缓存增长明显，则检查应用是否频繁读写大文件、日志是否写入容器可写层，以及 tmpfs 或共享内存是否持续扩大。若进程 RSS 不高，但容器总内存很高，还应排查页缓存、内存映射文件、子进程和共享内存。🧩
五、建立可复现的定位流程
- 记录异常发生时间、请求量、发布版本及容器重启情况。
- 保存 docker stats、inspect、进程列表和 cgroup 指标。
- 在相同版本与近似流量下进行压力测试，确认增长是否可复现。
- 选择两个或多个时间点采集堆快照，比较持续增长的对象。
- 修复后重复测试，确认内存能够稳定或在低峰期回落。
不要通过定时重启容器来替代修复。重启可以缓解故障，但会掩盖泄漏速度、触发条件和对象来源，适合作为临时止损措施，而不是最终方案。
六、预防与治理建议
生产容器应设置合理的内存限制和重启策略，但限制不能过紧，否则正常流量峰值也可能触发 OOM。应用应限制缓存容量、连接池数量、队列长度和并发任务数，并对堆内存、进程 RSS、页缓存及 OOM 次数分别监控。发布新版本后，应重点观察内存增长斜率，而不仅是当前占用率。
总结
Docker 容器内存泄漏的定位，本质上是从“趋势异常”逐步缩小到“内存类型、具体进程和具体对象”。先用 docker stats 与监控平台发现趋势，再借助 cgroup 和 OOM 日志确认边界，最后使用语言级工具分析堆对象与引用关系。只有形成采集、复现、对比、修复和验证的完整闭环，才能避免把正常缓存误判为泄漏，也能减少仅靠重启处理问题带来的风险。✅
