docker desktop停止容器后内存不释放是正常行为，因其底层虚拟机（macos用hyperkit、windows用wsl2）默认保留已分配内存，需完全退出docker desktop或手动重启wsl2才能真正释放。
Docker Desktop 停止容器后内存没降，不是 bug，是正常行为 —— 它压根没打算把内存还给宿主机。 你看到的内存占用（比如 docker stats 或 Activity Monitor 里显示的）反映的是虚拟机内核当前持有的物理页数，而 Docker Desktop 在 macOS/Windows 上运行于一个 Linux 虚拟机中，这个 VM 的内存分配策略默认偏向“保留”，不会因容器退出就主动归还。
为什么 docker stop 后内存不释放
根本原因在于 Docker Desktop 底层的虚拟机（macOS 是 hyperkit，Windows 是 WSL2）和其内嵌 Linux 内核的内存管理机制：
- Linux 内核对 cgroups 分配的内存采用“延迟回收”：容器进程退出后，其堆、缓存、slab 等内存块只是被标记为“可回收”，但不一定立即归还给宿主机物理内存池
- VM 层（
hyperkit或 WSL2）本身不支持动态收缩已分配的内存页；它向宿主机申请的内存块一旦拿到，就一直持有，直到整个 VM 关闭 -
docker stop只终止进程，不触发 VM 内存压缩或释放流程，docker system prune也只清理元数据，不影响 VM 已锁定的内存
怎么确认是不是真卡在内存不回收
别只看 Activity Monitor 或 Windows 任务管理器的总内存占用。要分层验证：
- 在 Docker Desktop 终端或
docker exec -it <container> sh</container>进入容器，运行free -h—— 看容器内 Linux 视角的可用内存 - 在宿主机终端运行：
docker system df，重点看RECLAIMABLE列是否非零；再跑docker stats --no-stream确认所有容器确实Status是exited - macOS 上用
htop或vm_stat查看Pages occupied by compressor和Pages wired down，若后者持续高位，说明 VM 内存被内核锁死
真正有效的内存释放操作
停止容器 ≠ 释放内存。必须让虚拟机主动交出内存，目前只有两种可靠路径：
-
完全退出 Docker Desktop：右键菜单选
Quit Docker Desktop，等图标消失（通常需 10–30 秒），此时hyperkit或 WSL2 进程终止，内存立刻返还给 macOS/Windows -
手动重启 WSL2（仅 Windows）：PowerShell 中执行
wsl --shutdown，再等几秒，Docker Desktop 会自动拉起新实例，旧 VM 内存清空 - macOS 用户可配合
killall -9 com.docker.hyperkit强制结束（慎用，可能丢未保存状态），比单纯点 Quit 更彻底
长期避免内存堆积的配置建议
光靠“每次 quit”太被动。关键要限制虚拟机本身的内存上限，并让容器更早释放资源：
- 在 Docker Desktop 设置 → Resources → Memory，把默认
2GB改成你实际需要的值（如1.5GB），避免 VM 预占过多 - 启动容器时加
--memory=512m --memory-swap=512m，强制 cgroups 级别限制，防止单个容器吃满 VM 内存 - Java 容器务必加
-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0，否则 JVM 无视 cgroups 限制，会把 VM 内存撑爆 - 避免长期运行
docker run -d的调试容器，它们即使 idle 也会持续 hold 内存
最常被忽略的一点：Docker Desktop 的“内存使用率”数字是虚的 —— 它显示的是虚拟机内核统计的“已分配”，不是宿主机视角的“真实占用”。你关掉所有容器后还剩 1.8GB，那很可能就是 VM 自己留着没动，而不是泄漏。只要 Quit Docker Desktop 后内存能回来，就不用过度干预底层 cgroups 或内核参数。
