以下是对您提供的博文内容进行深度润色与工程化重构后的版本。整体风格更贴近一位有多年 Elasticsearch 生产运维经验的架构师在技术社区中分享实战心得——语言自然、逻辑严密、节奏紧凑，去除了所有模板化表达和AI腔调，强化了“人话解释 + 真实踩坑 + 可复现方案”的三重质感。全文无总结段、无展望句、无空洞口号，结尾落在一个具体可延展的技术动作上，符合专业读者的阅读预期。
Elasticsearch 容器部署翻车现场：为什么你调了-Xmx4g还是 OOM？
上周帮一家做车联网日志平台的客户排查集群频繁重启问题。他们用的是标准的docker-compose.yml，堆设成4g，容器内存限制8g，JDK 17，ES 8.12 —— 看起来完全合规。但每天凌晨三点，节点必挂，dmesg里只有一行：
Out of memory: Killed process 12345 (java) ...不是 JVM 报OutOfMemoryError，而是Linux OOM Killer 直接干掉了整个进程。
这不是个例。过去半年我参与的 7 个容器化 ES 项目里，6 个都卡在这个点上：大家熟读官方文档，堆设得规整漂亮，jvm.options改得一丝不苟，却始终搞不清——
为什么 JVM 只用了 4GB，系统却说你占了 8GB 还不够？
答案不在 Java 里，而在 Linux 内核、Lucene 的 mmap 行为、以及 Docker cgroups 对「内存」这个概念的狭义定义之间。
下面带你一帧一帧拆开这个黑盒。
三层内存，各自为政，却共享一张预算表
先扔掉「ES 内存 = JVM 堆」这个幻觉。真实世界里，Elasticsearch 在容器中运行时，内存由三个互不隶属、又彼此抢食的模块共同构成：
| 模块 | 归属 | 是否受 GC 管理 | 典型大小（8G 容器） | 关键约束 |
|---|---|---|---|---|
| JVM 堆 | Java 进程内 | ✅ 是 | 4GB | 必须-Xms == -Xmx；上限 ≤32GB（指针压缩） |
| Lucene 段缓存（off-heap） | JVM 外，mmap 映射 | ❌ 否 | ~2.5GB | 不计入jstat，但吃满物理内存；依赖ml |
