docker容器共享内存的核心是通过--shm-size设置/dev/shm大小（最常用），或用tmpfs挂载自定义路径，而非直接bind mount宿主机/dev/shm；默认64mb常致oserror，需按需调大以支持opencv、pytorch等ipc应用。
Docker 容器与宿主机共享内存，核心是通过 --shm-size 控制容器内 /dev/shm 的大小，或用 --mount 挂载宿主机的 shm（不推荐直接挂载），也可通过 tmpfs 挂载自定义共享内存区域。关键不是“共享宿主机的 shm”，而是让容器拥有足够大、可互通的共享内存空间，尤其对 OpenCV、PyTorch、TensorFlow 等依赖 IPC 的应用至关重要。
设置容器内 /dev/shm 大小（最常用）
默认情况下，Docker 给容器分配的 /dev/shm 只有 64MB，很多多进程/多线程程序（如使用 multiprocessing.shared_memory 或 torch.multiprocessing）会因空间不足报错：OSError: Unable to mmap 123456789 bytes。
- 启动容器时用
--shm-size指定大小，例如：
docker run --shm-size=2g nginx
- 支持单位：
b、k、m、g（大小写均可） - 也可以写成
--shm-size=2048m或--shm-size=2147483648 - 在 docker-compose.yml 中对应写为：
services:<br> app:<br> image: myapp<br> shm_size: 2gb
挂载宿主机 /dev/shm（需谨慎）
虽然可用 --mount type=bind,source=/dev/shm,target=/dev/shm 直接绑定宿主机 shm，但存在风险：
- 宿主机 shm 通常权限宽松（
drwxrwxrwt），容器内进程可能意外清理其他进程的段 - 不同容器共用同一 shm，易引发冲突或数据污染
- 部分系统（如 CentOS 7 默认）/dev/shm 是 tmpfs 且 size 有限（如 64M），挂载后仍不够用
除非明确需要跨容器或与宿主机进程通信，否则不建议直接 bind mount。
用 tmpfs 挂载自定义共享内存路径（灵活可控）
若需隔离或更大空间，可挂载独立 tmpfs 到容器内任意路径（比如 /shared），并设好权限和大小：
- 命令行示例：
docker run \<br> --tmpfs /shared:rw,size=4g,mode=1777 \<br> -it ubuntu
-
mode=1777保证所有用户可读写（类似 /dev/shm） - 该路径下创建的文件本质是内存页，重启容器即清空，适合临时共享数据
- 应用需主动改用该路径（如 Python 中
shared_memory.SharedMemory(create=True, size=10**7, name="mydata")需配合/dev/shm；若用自定义路径，则需用mmap手动管理）
验证与调试技巧
进容器后快速确认 shm 状态：
-
df -h /dev/shm— 查看当前大小和已用空间 -
ls -ld /dev/shm— 检查权限是否为drwxrwxrwt -
ipcs -m— 列出当前共享内存段（需安装util-linux） - 若程序仍报错，检查是否硬编码了 shm 路径或未正确 cleanup，导致残留段占满空间
不复杂但容易忽略。
