进程通信

概述 凌晨 1 点 47 分，告警群弹出一条消息：192.168.10.23 shared memory usage > 1.5GB。登录机器一看，ipcs -m 输出里躺着 14 个共享内存段，其中 9 个 nattch=0（没有进程关联），却占着将近 2GB 物理内存。更恶心的是，ipcrm -m 删了 3 个，剩下的报 Operation not permitted——进程已经退出一个月了，这些"僵尸段"还赖在内核里不走。 这不是个例。在做 K8s 迁移那段时间，某个 Go 服务每次异常退出都会留下一块共享内存段。一个月下来积累了 30 多个段，直接把节点内存吃掉 3GB，导致 Pod 调度失败。当时排查了好几个小时才搞清楚根因：进程用了 shmget 创建共享内存做进程间数据交换，但异常退出时没走到 shmctl(IPC_RMID) 的清理逻辑，共享内存的生命周期跟着内核走，进程死了内存还在。 Linux 进程间通信（IPC，Inter-Process Communication）是个老话题，但大多数资料要么只讲 API 用法，要么纯讲内核原理，很少有人从"生产环境踩坑"的角度把它讲透。这篇文章从那次凌晨排障出发，把 7 种 IPC 机制的原理、性能差异、选型决策和排障方法一次讲清。不管你是做运维排查还是做服务架构选型，看完应该能独立处理 IPC 相关的线上问题。 相关文章：Linux 内存管理机制与调优实战 IPC 到底解决什么问题 一句话：进程之间天然是隔离的，每个进程有独立的虚拟地址空间，A 进程的指针 0x7fff1234 和 B 进程的同名指针指向完全不同的物理内存。要交换数据、同步状态、传递事件通知，就得通过内核提供的"通信通道"绕过隔离墙。 这不是废话——理解了"为什么需要 IPC"，才能理解每种机制的设计取舍。管道要拷贝两次数据（用户态→内核缓冲区→用户态），因为内核要做中转站；共享内存零拷贝，因为内核只负责映射物理页，之后进程自己读写；Unix 域套接字比 TCP 快 30-50%，因为省掉了协议栈的包头封装和校验。每种快慢差异背后都有明确的物理原因。 Linux 提供了 7 种主要 IPC 机制，我先用一张表做全景对比，后面逐个拆解：...