ipc命名空间是docker实现进程间通信资源硬隔离的底层基石，它不提供通信能力，而是划定“谁和谁能通信”的边界；它为每个容器提供独立的system v和posix ipc资源池，包括共享内存段、消息队列和信号量集，同一id在不同命名空间指向不同物理资源，互不可见、互不干扰。
IPC 命名空间是 Docker 实现进程间通信资源硬隔离的底层基石，它不提供通信能力，而是划定“谁和谁能通信”的边界。
IPC 命名空间隔离的是通信资源本身
它让每个容器拥有独立的 System V 和 POSIX IPC 资源池，包括：
- 共享内存段（shmget 创建的 shmid）
- 消息队列（msgget 或 mq_open 创建的 msgid / mqd_t）
- 信号量集（semget 创建的 semid）
这些资源在内核中按命名空间组织，同一资源 ID（比如 shmid=1）在不同 IPC 命名空间里指向完全不同的内存区域或队列，互不可见、互不干扰。
它是默认启用、无需显式配置的隔离层
Docker 在创建容器时，只要未指定 --ipc=host，就会自动为容器分配独立的 IPC 命名空间。这意味着：
- 容器内进程调用 ipcs -m 只能看到自己命名空间里的共享内存
- 宿主机或其他容器执行 ipcs -q 查不到该容器创建的消息队列
- 即使两个容器都用 shmget(IPC_PRIVATE, ...) 创建共享内存，它们的 shmid 可能相同，但底层对象物理隔离
它与 PID、Mount 等命名空间协同构成完整隔离视图
IPC 隔离不是孤立存在的：
- 一个进程必须先处于某个 PID 命名空间中，才能被纳入该 IPC 命名空间的访问控制范围
- 共享内存的生命周期由 IPC 命名空间绑定：当容器最后一个进程退出，整个 IPC 命名空间销毁，其中所有 shm/msg/sem 自动清理，无需手动 ipcrm
- 若容器挂载了宿主机的 /dev/shm，则可能绕过 IPC 隔离——因为 POSIX 共享内存文件实际落在 tmpfs 上，属于 Mount Namespace 控制范畴
它解决的是全局资源冲突与越权访问的根本问题
没有 IPC 命名空间时，所有进程共享一套 IPC 标识符空间，容易引发：
- 标识符碰撞：应用 A 创建 shmid=123 后退出，应用 B 恰好也申请到 shmid=123，误读 A 的残留数据
- 跨容器窥探：恶意容器通过遍历 shmid 枚举并 attach 到其他容器的共享内存段
- 资源泄漏：进程异常退出未释放信号量，导致整个系统 IPC 资源耗尽
IPC 命名空间从内核层面切断这种全局可见性，使每个容器的 IPC 行为真正“仅限本容器内生效”。
