Docker镜像层级共享通过内核page cache复用只读层内存页，显著降低宿主机内存压力；多个容器共享同一基础镜像时，/lib/ld-musl-x86_64.so.1等文件仅加载一次物理页，避免重复占用内存。
Docker镜像层级共享本身不直接减少运行时内存开销，但它通过优化镜像存储与启动行为，间接降低宿主机整体资源压力，尤其在大规模应用集群中效果显著。关键在于：多个容器复用相同只读层后，内核可对这些层的文件页进行内存共享（如 overlay2 驱动配合 page cache 复用），避免重复加载相同二进制、库文件或静态资源到内存。
只读层在内存中可被多个容器共享
Docker 使用联合文件系统（如 overlay2）挂载镜像层时，底层只读层的文件内容由内核 page cache 统一管理。当 100 个基于同一 alpine:latest 镜像启动的容器同时读取 /lib/ld-musl-x86_64.so.1，内核不会为每个容器单独加载一份副本，而是共享同一物理内存页。
- 依赖内核的 page cache 机制，无需额外配置
- 对频繁读取的共享库、语言运行时（如 Python 的 .pyc 缓存、Java 的 JRE 类）、静态资产（CSS/JS）效果最明显
- 可通过 cat /proc/meminfo | grep SReclaimable 观察可回收的共享缓存大小
避免容器层写放大导致内存浪费
每个容器拥有独立可写层（container layer），若应用频繁写入日志、临时文件或未清理的构建产物，会触发写时复制（Copy-on-Write），将原本共享的只读页复制到私有层，占用额外内存和磁盘。
- 禁止在容器内向镜像层路径（如 /usr/bin、/lib）写入内容
- 将日志重定向到 stdout/stderr 或挂载 tmpfs 卷（--tmpfs /app/logs:rw,size=64m）
- 使用 docker run --read-only 强制只读运行，配合明确挂载的读写路径
统一基础镜像版本，提升共享粒度
不同团队若各自使用 ubuntu:22.04、ubuntu:22.04.1、ubuntu:22.04@sha256:...，即使内容几乎一致，Docker 也会视为不同层（哈希值不同），无法共享。
- 强制使用带完整 digest 的基础镜像（如 FROM ubuntu:22.04@sha256:abc123...）
- 在 CI 中统一拉取并 tag 私有 registry 中的标准基础镜像
- 定期扫描集群中镜像层哈希，识别“近似但未共享”的基础层（可用 docker image inspect --format='{{.RootFS.Layers}}' xxx 提取）
精简镜像层结构，减少内存映射开销
过深或冗余的层（如多次 RUN 删除文件、分步安装再清理）虽不影响磁盘共享，但会增加 mount 操作复杂度和内核 VFS 层遍历开销，长期运行下轻微抬高内存驻留量。
- 合并 RUN 指令（如把 apt update + install + clean 放在同一行）
- 用多阶段构建（multi-stage build）剔除构建期工具链，使最终镜像仅含运行必需层
- 避免 COPY 整个构建目录后再删除部分文件；改用 .dockerignore 过滤，或在构建阶段精准复制
