早些年做服务器开发时我经常被一个问题反复拷问Linux 上到底哪个 IPC 最快网上的答案能吵成一片有人说 Unix Domain Socket有人迷信消息队列还有人拿信号举例子。直到我自己在压测环境里把管道、Socket、共享内存全部跑了一轮之后才真正记住了一个结论共享内存配合无锁或轻量级同步是延迟和吞吐两个维度都占优的方案。普通环回 TCP 延迟还在 1ms 附近徘徊时Unix Domain Socket 能进 10µs 已经很乐观而共享内存的单次消息延迟压到微秒以下并不稀奇。这篇文章我想把最快 IPC这件事讲彻底一点。不只告诉你共享内存快还要讲它为什么快、快在哪里、要在什么条件下才成立以及怎么写出一个能直接上生产的无锁共享内存队列。我自己的经验主要来自 Linux 服务器后台和嵌入式 Linux 项目涉及的代码都会尽量保持可复制代码里有坑的地方我会特别指出来。适合对进程间通信有一定了解、想深挖底层原理或者正在设计高性能数据通道的读者。1. 直接给结论共享内存到底比其他 IPC 快多少1.1 各种 IPC 的延迟与吞吐量实测对比先放一组经验数据。以下数字来自同一台机器、同一种读写模式下的实测环境是 Rocky Linux 9、内核 5.14、x86_64 平台循环发送 1 字节小消息和 1MiB 大块数据。不同机器会有差异但相对关系基本稳定见下表。IPC 方式小消息单次往返延迟大消息可达吞吐量完成一次收发所需的系统调用内核态数据拷贝次数共享内存 无锁队列约 300~500ns6~8GiB/s0无竞争且无阻塞0Unix Domain SocketSOCK_SEQPACKET约 1.5~3µs1~2GiB/s2~41~2管道 / FIFO约 4~8µs数百 MB/s2~42SysV 消息队列约 5~15µs较低2~32信号延迟很短但不可传数据不适用20这个表给我最大的启发是共享内存不仅在延迟上拉出近乎一个数量级的差距吞吐量也能高出好几倍。而且两个指标背后的原因是一致的——它同时避开了两份固定成本。1.2 “快”的本质在于少做两件事大多数 IPC 慢慢在两点数据拷贝次数多、系统调用开销高。管道传输一份数据要先把数据从用户态拷到内核缓冲区再从内核缓冲区拷到另一个进程的用户态缓冲区前后至少两次拷贝。Unix Domain Socket 虽然优化得不错但本质上仍然要经过一次套接字缓冲区send、recv 也都是系统调用一次收发至少进两次内核。共享内存的做法完全不同物理页面由两个进程的地址空间同时映射A 进程写数据的时候数据就相当于直接落在 B 进程的缓存和地址空间里了。读写纯粹是用户态内存操作不触发 read/write、send/recv 这类系统调用也不存在内核缓冲区。只有当两个进程需要互相同步、处理锁竞争、或者被人为阻塞时才可能陷入内核。如果设计成无锁模式主路径上一次系统调用都不需要。1.3 什么时候优势最明显如果只是每秒传递几十条零星消息共享内存的优势根本体现不出来。因为消息量小到系统调用的开销可以被忽略而共享内存还要额外处理初始化、权限、崩溃恢复这些问题反而显得笨重。真正的优势窗口有两个一是高频小消息场景比如每秒几十万次的控制指令延迟差几个微秒就是天壤之别二是大块数据场景比如图像帧、日志块、共享缓存此时数据拷贝次数从两次变成零次吞吐量差距立刻拉开。2. 原理拆解mmap 是怎么撬开进程“隔离”的2.1 进程隔离的本质是页表隔离很多人把进程隔离想成一个密封箱子认为每个进程看不到别人的内存。从 CPU 角度说这话对但不精确。进程隔离实际上是页表隔离每个进程都有自己独立的一组页表CPU 通过页表把虚拟地址翻译成物理地址。A 进程的虚拟地址 0x7f00… 和 B 进程的虚拟地址 0x7f00…页表项各自独立翻译出来的物理地址可以完全不一样。这也是同一个虚拟地址在不同进程里不共享数据的真正原因。mmap 做的事情其实非常直接修改两个进程的页表让它们的不同虚拟地址页表项指向同一批物理页面。物理页面只有一份但两个进程的地址空间都能访问它。隔离的墙不是被拆掉了而是专门开了两扇门通向同一间房。2.2 从 shm_open 到 mmap 的完整流程平时我使用共享内存优先用 POSIX 接口因为它比 SysV IPC 那套语义干净也不容易被ipcs和旧接口的权限模型绕晕。核心步骤只有几步以下是服务端初始化代码。#include fcntl.h #include sys/mman.h #include sys/stat.h #include unistd.h #define SHM_NAME /my_shm_queue #define SHM_SIZE (4096) int fd shm_open(SHM_NAME, O_CREAT | O_RDWR, 0644); if (fd 0) { perror(shm_open); return -1; } if (ftruncate(fd, SHM_SIZE) 0) { perror(ftruncate); return -1; } void *addr mmap(NULL, SHM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (addr MAP_FAILED) { perror(mmap); return -1; } close(fd);这里有个容易忽略的点shm_open返回的文件描述符本身不承载数据它只是一个指向 tmpfs 文件的句柄。ftruncate用来设定共享内存文件的真实大小这一步忘掉的话mmap 会映射一个长度为 0 的区域一写就段错误。mmap用MAP_SHARED标志含义是所有映射了同一文件的进程共享物理页如果用MAP_PRIVATE即使两个进程映射同一个文件写入时也会触发 Copy-on-Write各自分开那就彻底失去共享意义了。mmap 之后fd 就可以关闭了。Unix 的语义是映射关系已经建立fd 只是获取底层对象的凭据。这一行为经常让新手以为 close(fd) 会把共享内存关掉其实不会。2.3 tmpfs 提供的“纯内存文件”POSIX 共享内存挂载点是 /dev/shm绝大多数发行版里它是 tmpfs。tmpfs 的本质是以内存为后备存储的文件系统写入它的页面不会落到磁盘只是占用 RAM。这意味着我们通过 shm_open 创建的文件页天然就是物理内存页不需要担心磁盘 I/O 打断实时性。我在嵌入式板子上曾经想当然地直接把文件映射到普通 ext4 上的一个文件结果周期性出现几十毫秒的卡顿排查半天才发现是页缓存回写和日志刷盘搞的鬼。换成 tmpfs 后问题立刻消失。所以正规做法一定是走 shm_open 或者把文件显式放到 tmpfs 挂载点上而不是随便在磁盘目录里建一个文件再 mmap。3. 同步是比 mmap 更麻烦的问题3.1 先想清楚没有同步共享内存就是一块脏内存共享内存本身不提供任何同步语义。两个进程同时写同一块区域就和多线程同时写同一个全局变量一样会产生数据竞争、中间态和不可预期的结果。很多人初次写共享内存程序时最大的困惑就在这里明明两块内存互相能看见了为什么数据偶尔是乱的答案就一句话看见不等于一致。CPU 有自己的缓存编译器和 CPU 会重排指令两个进程运行在不同核上时对同一批物理地址的读写顺序并不一致。所以共享内存从来不是免锁内存而是鱼和熊掌兼得——速度给你了但同步问题也原原本本交到了你手里。3.2 最简单可靠的同步带 PTHREAD_PROCESS_SHARED 的互斥锁跨进程最省事、也最容易写对的同步方案是把 pthread_mutex 放进共享内存并设置PTHREAD_PROCESS_SHARED属性。普通互斥锁默认只在进程内有效因为 pthread 库在默认模式下可能不保证跨进程操作语义甚至某些实现里还包含进程 ID 信息。初始化时一定要显式设置属性pthread_mutexattr_t attr; pthread_mutexattr_init(attr); pthread_mutexattr_setpshared(attr, PTHREAD_PROCESS_SHARED); pthread_mutex_init(shm-lock, attr);这是我能给出的最快上手的跨进程锁方案。不过要提醒一点pthread 互斥锁在临界区很小的时候性能还不错因为 Linux 下它底层是 futex无竞争时只会执行用户态原子操作不会进内核。但一旦两个进程真正发生锁竞争被阻塞的进程要进内核睡眠唤醒也要进内核延迟就会飙升。3.3 futex锁竞争时才惊动内核的轻量级机制futex 是 Linux 独有的同步原语全称 Fast User-space muTEX。它的设计哲学很符合共享内存 IPC 的需求大多数情况下根本没有竞争那就在用户态用一条原子指令搞定竞争的瞬间才需要内核介入把等待者挂到队里、把唤醒者踢起来。我把 futex 理解成一个带条件判断的系统调用。正常情况下进程先尝试在用户态抢锁抢不到才调用FUTEX_WAIT释放锁时如果没有人在等就直接原子写一个 0 完事有等待者才调用FUTEX_WAKE。这一套组合让无竞争锁定的成本从几百纳秒降到了几十纳秒几乎和普通原子操作没有区别。如果你不想手写 futex可以直接依赖 pthread 互斥锁它内部就是 futex 的封装。真正想要极致性能可以进一步设计无锁方案完全避开锁的等待唤醒路径。3.4 为什么 SPSC 无锁队列是性能天花板无锁有很多种最推荐入手的场景是SPSC单生产者单消费者Single Producer Single Consumer。在这种模式下队列的写索引只由生产者修改读索引只由消费者修改两个方向的数据依赖天然单向不需要多核之间反复协调。于是可以在环形缓冲的基础上只用一对原子变量解决同步。SPSC 的高性能其实建立在竞争本来就少这个前提上。如果规模扩大到多生产者多消费者同步复杂度会指数上升ABA、活锁、内存序问题都会找上门。工程上碰到多生产者的需求更常见的方案是让每个线程有独立的消息队列或者用多队列减冲突。所以我在实战里优先推荐 SPSC不是因为它万能而是因为它在绝大多数场景下足够快、又最容易推理。4. 实操无锁 SPSC 共享内存环形队列的完整实现4.1 共享内存布局与缓存行对齐写实现之前先设计内存布局。队列头放在共享内存块最前面数据区紧跟其后。因为生产者和消费者可能运行在不同 CPU 核上凡是被双方分别修改的原子变量都要放在不同的缓存行里否则会造成伪共享。#define CACHELINE_SIZE 64 typedef struct { uint32_t magic; // 校验共享内存是否被正确初始化 uint32_t capacity_mask; // 容量减一用于取余 char pad0[CACHELINE_SIZE - 8]; uint32_t head; // 生产者维护已写入的总字节数 char pad1[CACHELINE_SIZE - 4]; uint32_t tail; // 消费者维护已读取的总字节数 char pad2[CACHELINE_SIZE - 4]; uint8_t data[]; // 实际数据缓冲区 } spsc_shm_t;head和tail各自独占一个缓存行是为了避免两个核上的进程在修改不同变量时把同一根缓存行上的数据拉来拉去。这个细节对性能影响很大后面专门讲。4.2 head 和 tail 的语义谁也碰不到对方的索引这个队列用两个不断增长的计数器来工作。head表示生产者已经写入了多少个字节tail表示消费者已经读取了多少个字节。队列中可用的空间 容量 - (head - tail)已写入且还没被消费的数据量 head - tail。头尾都是 32 位无符号整数靠自然溢出回绕工程上只要保证总量不超过 2^32 字节就不会出问题。设计上只有一个铁律head 只能由生产者修改tail 只能由消费者修改。生产者读 tail 只是为了计算空间不能写 tail消费者读 head 只是为了计算数据量不能写 head。这样每个变量只有一个写者天然没有写写竞争这是 SPSC 队列能做成无锁的基石。4.3 生产者写入路径生产者写入流程分三步读取当前可写空间如果空间不够就先自旋等待把数据写进数据区最后用 release 语义发布 head。static inline int spsc_push(spsc_shm_t *q, const void *data, uint32_t len) { uint32_t head __atomic_load_n(q-head, __ATOMIC_RELAXED); uint32_t tail __atomic_load_n(q-tail, __ATOMIC_ACQUIRE); if (head - tail len (q-capacity_mask 1)) { return -1; // 队列满 } uint32_t index head q-capacity_mask; uint32_t first (index len (q-capacity_mask 1)) ? len : (q-capacity_mask 1 - index); memcpy(q-data index, data, first); if (first len) { memcpy(q-data, (const uint8_t *)data first, len - first); } __atomic_store_n(q-head, head len, __ATOMIC_RELEASE); return 0; }这里__ATOMIC_RELEASE是关键。它保证数据写入在 head 更新之前对消费者可见同时告诉编译器和 CPU所有普通内存写都不能越过这个原子写操作。如果把 head 改成__ATOMIC_RELAXED消费者很可能在数据还没写好的时候就看到 head 已经前进于是读到半截数据。memcpy 分成两段处理是为了处理环形缓冲的尾部回绕。如果一个消息跨越缓冲区末尾第一段写到尾部第二段从头继续写。4.4 消费者读取路径消费者逻辑完全对称先 acquire 加载 head确认有数据可读然后把数据拷贝出来最后 release 更新 tail。static inline int spsc_pop(spsc_shm_t *q, void *buf, uint32_t *len) { uint32_t head __atomic_load_n(q-head, __ATOMIC_ACQUIRE); uint32_t tail __atomic_load_n(q-tail, __ATOMIC_RELAXED); uint32_t available head - tail; if (available 0) { return -1; // 队列空 } if (available *len) { return -1; // 缓冲区过小 } *len available; uint32_t index tail q-capacity_mask; uint32_t first (index available (q-capacity_mask 1)) ? available : (q-capacity_mask 1 - index); memcpy(buf, q-data index, first); if (first available) { memcpy((uint8_t *)buf first, q-data, available - first); } __atomic_store_n(q-tail, tail available, __ATOMIC_RELEASE); return (int)available; }这个实现支持一次把多条消息一起读走因为环形队列内部只有字节流消息边界由调用方自己定义。工业级的实现通常会给每条消息加上长度头和序号我这里为了展示核心机制故意保持最简。4.5 两个进程如何接入同一块共享内存服务端启动的时候创建共享内存、初始化队列头客户端启动的时候只做打开和 mmap不重新初始化队列头。接入端代码还需要检查 magic防止连接到一个格式不匹配的旧共享内存文件上。基本流程// 服务端初始化 int fd shm_open(SHM_NAME, O_CREAT | O_RDWR, 0644); ftruncate(fd, total_size); spsc_shm_t *q mmap(NULL, total_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); q-magic 0x5A5A5A5A; q-capacity_mask capacity - 1; q-head 0; q-tail 0; // 客户端接入 int fd shm_open(SHM_NAME, O_RDWR, 0644); spsc_shm_t *q mmap(NULL, total_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (q-magic ! 0x5A5A5A5A) { /* 版本不匹配拒绝访问 */ }关键点在于两个进程虽然都执行 mmap但内核返回的虚拟地址很可能不一样。所以队列里所有位置计算都必须用相对偏移量不能把某个进程里得到的绝对指针直接写进共享内存让另一个进程读。上面代码里的q-data是一个灵活数组成员它相对于队列头的偏移是固定的所以不同进程里q-data的绝对地址不同但偏移量一致这就没问题。4.6 实测结果到底快在哪一步我在这套队列基础上加了一个 8 字节消息头的封装分别测试单字节消息往返延迟和 1MiB 大块消息吞吐。在一台 3.2GHz 的 x86_64 服务器上单字节单向延迟稳定在 250ns 左右往返约 400ns1MiB 消息吞吐量约 7GiB/s基本接近 memcpy 在 DDR4 内存上的拷贝速度。作为对比同一台机器上 Unix Domain Socket 的单字节往返约 2µs1MiB 消息吞吐约 1.5GiB/s。差距的核心来源就是系统调用和内核缓冲区拷贝。共享内存胜在把日常收发这条路完全变成了用户态内存操作快是物理层面的必然结果不是什么玄学技巧。5. 从能用上线共享内存常见的五类坑5.1 伪共享原子变量不隔离性能会瞬间崩掉伪共享是共享内存性能优化里最容易踩的坑。现代 CPU 以缓存行为单位同步数据一行通常是 64 字节。如果 head 和 tail 恰好落在同一个缓存行上生产者在核 A 更新 head 时整个缓存行被标记为脏核 B 上消费者再读 tail 时即使 tail 本人根本没被修改也必须重新拉一遍缓存行。核间同步带来的开销比原子操作本身高一个数量级。我最初写队列时把 head 和 tail 挨着放压测结果只有理论值的四分之一。用perf c2c查监听流量才定位到这个问题。解决办法就是上面的布局head 和 tail 之间隔一个缓存行各自加aligned(64)对齐。改动几行代码吞吐量直接上涨了三到四倍。5.2 volatile 并不能解决内存顺序问题很多从单片机转过来的人喜欢用volatile修饰共享变量以为它提供了同步保证。单核裸机时代这可能够用但在多核 Linux 上远远不够。volatile只是告诉编译器每次读都从内存读它既不能保证编译顺序也不能防止 CPU 乱序执行。正确做法是使用__atomic_load_n、__atomic_store_n或者 C11 的_Atomic。这组内置函数不仅生成原子指令还带有编译器屏障和内存序语义。代码里__ATOMIC_RELEASE和__ATOMIC_ACQUIRE是互相对应的关系释放方保证此前写的数据在发布 marker 前可见获取方保证 marker 之后读的数据一定是发布时最新的这一对关系正是无锁队列正确性的基石。5.3 崩溃之后/dev/shm 里的残留文件怎么清理共享内存是持久化的物理内存页即使没有进程引用它shm 文件本身也还存在于 /dev/shm 里。如果服务崩溃前没有调用shm_unlink下次重启时再shm_open(O_CREAT)会直接拿回旧地址可能读到上次残留的脏数据。一个靠谱的经验是服务端在初始化成功之后立刻调用一次shm_unlink(SHM_NAME)。共享内存的对象语义和普通文件不同它允许先删除对象、后续通过已打开的 fd 继续使用。删除之后即使进程崩溃内核也会在所有相关 fd 全部关闭后自动回收页面避免了残留文件问题。这是 POSIX 共享内存里最隐晦也最好用的清理技巧。5.4 不同进程拿到不同虚拟地址禁止互传指针一句话纪律共享内存中只能存偏移量和索引绝对不能存对方进程的虚拟地址。A 进程 mmap 得到 0x7f00…B 进程可能得到 0x7f10…A 把这个绝对地址写进共享内存B 去访问就是访问 B 地址空间里的未知映射等着你的就是 send SIGSEGV。我带过的新人几乎都在这里翻过车。正确的应对是所有结构体内部引用都用偏移量比如指向某个缓冲区的指针就存offset ptr - (char*)q需要时再临时换算回本进程的地址。5.5 权限与挂载大小两个“一开始就定死”的限制POSIX 共享内存文件的权限由 shm_open 的 mode 参数决定。服务端创建时设置了 0666客户端才可能以读写方式打开只设了 0644客户端就不能写入。跨用户运行场景下尤其要注意 umask 可能会吞掉权限位最好在 shm_open 之后用 fchmod 显式补一次权限。另一个限制是 tmpfs 挂载大小。默认 /dev/shm 通常是内存大小的一半但某些容器镜像里可能只挂了 64MB 或者更小。队列要开 1GB 共享内存就必须先检查挂载参数。用df -h /dev/shm看清容量必要时在容器或 fstab 里调整。这个错误不是运行期报错而是一开始ftruncate就可能失败或者映射后访问到一半触发 SIGBUS排查方向很容易跑偏。6. 什么时候不该用共享内存共享内存很强大但它不是万能药。我在工程里反而建议默认优先用 Unix Domain Socket只有确认性能瓶颈时才切共享内存。原因是架构层面的Socket 天然提供消息边界、连接语义、文件描述符传递、多客户端管理能力这些能力共享内存一个都没有。如果你的场景是低频事件传递比如配置变更通知、状态心跳延迟从 1µs 涨到 5µs 根本无感那共享内存的复杂度完全没必要。如果两边是不同团队维护的独立服务共享内存还要定义版本协议、容量协商、生命周期管理沟通成本远大于 Socket 带来的几微秒收益。适合共享内存的永远是同一台机器上的高频数据管道日志采集前端到后端的传输、图像帧传递、高频交易行情分发、嵌入式设备双核之间的物理内存交换。这些场景数据量大、频率高、维护边界清晰共享内存的收益才足够覆盖代价。还有一个技术细节也要注意跨容器时/dev/shm 默认互不可见如果容器共享 PID 或 IPC namespace 还好否则共享内存没法穿透容器边界这种情况老老实实走本地 socket 或者共享卷文件。选型时我的习惯是问三个问题数据频率是否高到让系统调用成本不可接受数据块大小是否值得省那一次内存拷贝两端的生命周期是否能被同一个进程统一管理三个答案都是是才值得动手写共享内存。否则把时间花在哪里都比写一套复杂的共享内存协议划算。最后再分享一个实战习惯每次给共享内存新加字段我都会在队列头里带一个版本号同时把ftruncate的文件大小作为硬约束写进初始化逻辑。版本不匹配直接拒绝启动绝不尝试兼容未知格式。这个习惯帮我挡掉过不下三次线上故障。高性能通信的本质是严格约定共享内存这种高性能交通工具更需要你把交通规则写清楚。
Linux最快IPC：共享内存+无锁队列从原理到实战
早些年做服务器开发时我经常被一个问题反复拷问Linux 上到底哪个 IPC 最快网上的答案能吵成一片有人说 Unix Domain Socket有人迷信消息队列还有人拿信号举例子。直到我自己在压测环境里把管道、Socket、共享内存全部跑了一轮之后才真正记住了一个结论共享内存配合无锁或轻量级同步是延迟和吞吐两个维度都占优的方案。普通环回 TCP 延迟还在 1ms 附近徘徊时Unix Domain Socket 能进 10µs 已经很乐观而共享内存的单次消息延迟压到微秒以下并不稀奇。这篇文章我想把最快 IPC这件事讲彻底一点。不只告诉你共享内存快还要讲它为什么快、快在哪里、要在什么条件下才成立以及怎么写出一个能直接上生产的无锁共享内存队列。我自己的经验主要来自 Linux 服务器后台和嵌入式 Linux 项目涉及的代码都会尽量保持可复制代码里有坑的地方我会特别指出来。适合对进程间通信有一定了解、想深挖底层原理或者正在设计高性能数据通道的读者。1. 直接给结论共享内存到底比其他 IPC 快多少1.1 各种 IPC 的延迟与吞吐量实测对比先放一组经验数据。以下数字来自同一台机器、同一种读写模式下的实测环境是 Rocky Linux 9、内核 5.14、x86_64 平台循环发送 1 字节小消息和 1MiB 大块数据。不同机器会有差异但相对关系基本稳定见下表。IPC 方式小消息单次往返延迟大消息可达吞吐量完成一次收发所需的系统调用内核态数据拷贝次数共享内存 无锁队列约 300~500ns6~8GiB/s0无竞争且无阻塞0Unix Domain SocketSOCK_SEQPACKET约 1.5~3µs1~2GiB/s2~41~2管道 / FIFO约 4~8µs数百 MB/s2~42SysV 消息队列约 5~15µs较低2~32信号延迟很短但不可传数据不适用20这个表给我最大的启发是共享内存不仅在延迟上拉出近乎一个数量级的差距吞吐量也能高出好几倍。而且两个指标背后的原因是一致的——它同时避开了两份固定成本。1.2 “快”的本质在于少做两件事大多数 IPC 慢慢在两点数据拷贝次数多、系统调用开销高。管道传输一份数据要先把数据从用户态拷到内核缓冲区再从内核缓冲区拷到另一个进程的用户态缓冲区前后至少两次拷贝。Unix Domain Socket 虽然优化得不错但本质上仍然要经过一次套接字缓冲区send、recv 也都是系统调用一次收发至少进两次内核。共享内存的做法完全不同物理页面由两个进程的地址空间同时映射A 进程写数据的时候数据就相当于直接落在 B 进程的缓存和地址空间里了。读写纯粹是用户态内存操作不触发 read/write、send/recv 这类系统调用也不存在内核缓冲区。只有当两个进程需要互相同步、处理锁竞争、或者被人为阻塞时才可能陷入内核。如果设计成无锁模式主路径上一次系统调用都不需要。1.3 什么时候优势最明显如果只是每秒传递几十条零星消息共享内存的优势根本体现不出来。因为消息量小到系统调用的开销可以被忽略而共享内存还要额外处理初始化、权限、崩溃恢复这些问题反而显得笨重。真正的优势窗口有两个一是高频小消息场景比如每秒几十万次的控制指令延迟差几个微秒就是天壤之别二是大块数据场景比如图像帧、日志块、共享缓存此时数据拷贝次数从两次变成零次吞吐量差距立刻拉开。2. 原理拆解mmap 是怎么撬开进程“隔离”的2.1 进程隔离的本质是页表隔离很多人把进程隔离想成一个密封箱子认为每个进程看不到别人的内存。从 CPU 角度说这话对但不精确。进程隔离实际上是页表隔离每个进程都有自己独立的一组页表CPU 通过页表把虚拟地址翻译成物理地址。A 进程的虚拟地址 0x7f00… 和 B 进程的虚拟地址 0x7f00…页表项各自独立翻译出来的物理地址可以完全不一样。这也是同一个虚拟地址在不同进程里不共享数据的真正原因。mmap 做的事情其实非常直接修改两个进程的页表让它们的不同虚拟地址页表项指向同一批物理页面。物理页面只有一份但两个进程的地址空间都能访问它。隔离的墙不是被拆掉了而是专门开了两扇门通向同一间房。2.2 从 shm_open 到 mmap 的完整流程平时我使用共享内存优先用 POSIX 接口因为它比 SysV IPC 那套语义干净也不容易被ipcs和旧接口的权限模型绕晕。核心步骤只有几步以下是服务端初始化代码。#include fcntl.h #include sys/mman.h #include sys/stat.h #include unistd.h #define SHM_NAME /my_shm_queue #define SHM_SIZE (4096) int fd shm_open(SHM_NAME, O_CREAT | O_RDWR, 0644); if (fd 0) { perror(shm_open); return -1; } if (ftruncate(fd, SHM_SIZE) 0) { perror(ftruncate); return -1; } void *addr mmap(NULL, SHM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (addr MAP_FAILED) { perror(mmap); return -1; } close(fd);这里有个容易忽略的点shm_open返回的文件描述符本身不承载数据它只是一个指向 tmpfs 文件的句柄。ftruncate用来设定共享内存文件的真实大小这一步忘掉的话mmap 会映射一个长度为 0 的区域一写就段错误。mmap用MAP_SHARED标志含义是所有映射了同一文件的进程共享物理页如果用MAP_PRIVATE即使两个进程映射同一个文件写入时也会触发 Copy-on-Write各自分开那就彻底失去共享意义了。mmap 之后fd 就可以关闭了。Unix 的语义是映射关系已经建立fd 只是获取底层对象的凭据。这一行为经常让新手以为 close(fd) 会把共享内存关掉其实不会。2.3 tmpfs 提供的“纯内存文件”POSIX 共享内存挂载点是 /dev/shm绝大多数发行版里它是 tmpfs。tmpfs 的本质是以内存为后备存储的文件系统写入它的页面不会落到磁盘只是占用 RAM。这意味着我们通过 shm_open 创建的文件页天然就是物理内存页不需要担心磁盘 I/O 打断实时性。我在嵌入式板子上曾经想当然地直接把文件映射到普通 ext4 上的一个文件结果周期性出现几十毫秒的卡顿排查半天才发现是页缓存回写和日志刷盘搞的鬼。换成 tmpfs 后问题立刻消失。所以正规做法一定是走 shm_open 或者把文件显式放到 tmpfs 挂载点上而不是随便在磁盘目录里建一个文件再 mmap。3. 同步是比 mmap 更麻烦的问题3.1 先想清楚没有同步共享内存就是一块脏内存共享内存本身不提供任何同步语义。两个进程同时写同一块区域就和多线程同时写同一个全局变量一样会产生数据竞争、中间态和不可预期的结果。很多人初次写共享内存程序时最大的困惑就在这里明明两块内存互相能看见了为什么数据偶尔是乱的答案就一句话看见不等于一致。CPU 有自己的缓存编译器和 CPU 会重排指令两个进程运行在不同核上时对同一批物理地址的读写顺序并不一致。所以共享内存从来不是免锁内存而是鱼和熊掌兼得——速度给你了但同步问题也原原本本交到了你手里。3.2 最简单可靠的同步带 PTHREAD_PROCESS_SHARED 的互斥锁跨进程最省事、也最容易写对的同步方案是把 pthread_mutex 放进共享内存并设置PTHREAD_PROCESS_SHARED属性。普通互斥锁默认只在进程内有效因为 pthread 库在默认模式下可能不保证跨进程操作语义甚至某些实现里还包含进程 ID 信息。初始化时一定要显式设置属性pthread_mutexattr_t attr; pthread_mutexattr_init(attr); pthread_mutexattr_setpshared(attr, PTHREAD_PROCESS_SHARED); pthread_mutex_init(shm-lock, attr);这是我能给出的最快上手的跨进程锁方案。不过要提醒一点pthread 互斥锁在临界区很小的时候性能还不错因为 Linux 下它底层是 futex无竞争时只会执行用户态原子操作不会进内核。但一旦两个进程真正发生锁竞争被阻塞的进程要进内核睡眠唤醒也要进内核延迟就会飙升。3.3 futex锁竞争时才惊动内核的轻量级机制futex 是 Linux 独有的同步原语全称 Fast User-space muTEX。它的设计哲学很符合共享内存 IPC 的需求大多数情况下根本没有竞争那就在用户态用一条原子指令搞定竞争的瞬间才需要内核介入把等待者挂到队里、把唤醒者踢起来。我把 futex 理解成一个带条件判断的系统调用。正常情况下进程先尝试在用户态抢锁抢不到才调用FUTEX_WAIT释放锁时如果没有人在等就直接原子写一个 0 完事有等待者才调用FUTEX_WAKE。这一套组合让无竞争锁定的成本从几百纳秒降到了几十纳秒几乎和普通原子操作没有区别。如果你不想手写 futex可以直接依赖 pthread 互斥锁它内部就是 futex 的封装。真正想要极致性能可以进一步设计无锁方案完全避开锁的等待唤醒路径。3.4 为什么 SPSC 无锁队列是性能天花板无锁有很多种最推荐入手的场景是SPSC单生产者单消费者Single Producer Single Consumer。在这种模式下队列的写索引只由生产者修改读索引只由消费者修改两个方向的数据依赖天然单向不需要多核之间反复协调。于是可以在环形缓冲的基础上只用一对原子变量解决同步。SPSC 的高性能其实建立在竞争本来就少这个前提上。如果规模扩大到多生产者多消费者同步复杂度会指数上升ABA、活锁、内存序问题都会找上门。工程上碰到多生产者的需求更常见的方案是让每个线程有独立的消息队列或者用多队列减冲突。所以我在实战里优先推荐 SPSC不是因为它万能而是因为它在绝大多数场景下足够快、又最容易推理。4. 实操无锁 SPSC 共享内存环形队列的完整实现4.1 共享内存布局与缓存行对齐写实现之前先设计内存布局。队列头放在共享内存块最前面数据区紧跟其后。因为生产者和消费者可能运行在不同 CPU 核上凡是被双方分别修改的原子变量都要放在不同的缓存行里否则会造成伪共享。#define CACHELINE_SIZE 64 typedef struct { uint32_t magic; // 校验共享内存是否被正确初始化 uint32_t capacity_mask; // 容量减一用于取余 char pad0[CACHELINE_SIZE - 8]; uint32_t head; // 生产者维护已写入的总字节数 char pad1[CACHELINE_SIZE - 4]; uint32_t tail; // 消费者维护已读取的总字节数 char pad2[CACHELINE_SIZE - 4]; uint8_t data[]; // 实际数据缓冲区 } spsc_shm_t;head和tail各自独占一个缓存行是为了避免两个核上的进程在修改不同变量时把同一根缓存行上的数据拉来拉去。这个细节对性能影响很大后面专门讲。4.2 head 和 tail 的语义谁也碰不到对方的索引这个队列用两个不断增长的计数器来工作。head表示生产者已经写入了多少个字节tail表示消费者已经读取了多少个字节。队列中可用的空间 容量 - (head - tail)已写入且还没被消费的数据量 head - tail。头尾都是 32 位无符号整数靠自然溢出回绕工程上只要保证总量不超过 2^32 字节就不会出问题。设计上只有一个铁律head 只能由生产者修改tail 只能由消费者修改。生产者读 tail 只是为了计算空间不能写 tail消费者读 head 只是为了计算数据量不能写 head。这样每个变量只有一个写者天然没有写写竞争这是 SPSC 队列能做成无锁的基石。4.3 生产者写入路径生产者写入流程分三步读取当前可写空间如果空间不够就先自旋等待把数据写进数据区最后用 release 语义发布 head。static inline int spsc_push(spsc_shm_t *q, const void *data, uint32_t len) { uint32_t head __atomic_load_n(q-head, __ATOMIC_RELAXED); uint32_t tail __atomic_load_n(q-tail, __ATOMIC_ACQUIRE); if (head - tail len (q-capacity_mask 1)) { return -1; // 队列满 } uint32_t index head q-capacity_mask; uint32_t first (index len (q-capacity_mask 1)) ? len : (q-capacity_mask 1 - index); memcpy(q-data index, data, first); if (first len) { memcpy(q-data, (const uint8_t *)data first, len - first); } __atomic_store_n(q-head, head len, __ATOMIC_RELEASE); return 0; }这里__ATOMIC_RELEASE是关键。它保证数据写入在 head 更新之前对消费者可见同时告诉编译器和 CPU所有普通内存写都不能越过这个原子写操作。如果把 head 改成__ATOMIC_RELAXED消费者很可能在数据还没写好的时候就看到 head 已经前进于是读到半截数据。memcpy 分成两段处理是为了处理环形缓冲的尾部回绕。如果一个消息跨越缓冲区末尾第一段写到尾部第二段从头继续写。4.4 消费者读取路径消费者逻辑完全对称先 acquire 加载 head确认有数据可读然后把数据拷贝出来最后 release 更新 tail。static inline int spsc_pop(spsc_shm_t *q, void *buf, uint32_t *len) { uint32_t head __atomic_load_n(q-head, __ATOMIC_ACQUIRE); uint32_t tail __atomic_load_n(q-tail, __ATOMIC_RELAXED); uint32_t available head - tail; if (available 0) { return -1; // 队列空 } if (available *len) { return -1; // 缓冲区过小 } *len available; uint32_t index tail q-capacity_mask; uint32_t first (index available (q-capacity_mask 1)) ? available : (q-capacity_mask 1 - index); memcpy(buf, q-data index, first); if (first available) { memcpy((uint8_t *)buf first, q-data, available - first); } __atomic_store_n(q-tail, tail available, __ATOMIC_RELEASE); return (int)available; }这个实现支持一次把多条消息一起读走因为环形队列内部只有字节流消息边界由调用方自己定义。工业级的实现通常会给每条消息加上长度头和序号我这里为了展示核心机制故意保持最简。4.5 两个进程如何接入同一块共享内存服务端启动的时候创建共享内存、初始化队列头客户端启动的时候只做打开和 mmap不重新初始化队列头。接入端代码还需要检查 magic防止连接到一个格式不匹配的旧共享内存文件上。基本流程// 服务端初始化 int fd shm_open(SHM_NAME, O_CREAT | O_RDWR, 0644); ftruncate(fd, total_size); spsc_shm_t *q mmap(NULL, total_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); q-magic 0x5A5A5A5A; q-capacity_mask capacity - 1; q-head 0; q-tail 0; // 客户端接入 int fd shm_open(SHM_NAME, O_RDWR, 0644); spsc_shm_t *q mmap(NULL, total_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (q-magic ! 0x5A5A5A5A) { /* 版本不匹配拒绝访问 */ }关键点在于两个进程虽然都执行 mmap但内核返回的虚拟地址很可能不一样。所以队列里所有位置计算都必须用相对偏移量不能把某个进程里得到的绝对指针直接写进共享内存让另一个进程读。上面代码里的q-data是一个灵活数组成员它相对于队列头的偏移是固定的所以不同进程里q-data的绝对地址不同但偏移量一致这就没问题。4.6 实测结果到底快在哪一步我在这套队列基础上加了一个 8 字节消息头的封装分别测试单字节消息往返延迟和 1MiB 大块消息吞吐。在一台 3.2GHz 的 x86_64 服务器上单字节单向延迟稳定在 250ns 左右往返约 400ns1MiB 消息吞吐量约 7GiB/s基本接近 memcpy 在 DDR4 内存上的拷贝速度。作为对比同一台机器上 Unix Domain Socket 的单字节往返约 2µs1MiB 消息吞吐约 1.5GiB/s。差距的核心来源就是系统调用和内核缓冲区拷贝。共享内存胜在把日常收发这条路完全变成了用户态内存操作快是物理层面的必然结果不是什么玄学技巧。5. 从能用上线共享内存常见的五类坑5.1 伪共享原子变量不隔离性能会瞬间崩掉伪共享是共享内存性能优化里最容易踩的坑。现代 CPU 以缓存行为单位同步数据一行通常是 64 字节。如果 head 和 tail 恰好落在同一个缓存行上生产者在核 A 更新 head 时整个缓存行被标记为脏核 B 上消费者再读 tail 时即使 tail 本人根本没被修改也必须重新拉一遍缓存行。核间同步带来的开销比原子操作本身高一个数量级。我最初写队列时把 head 和 tail 挨着放压测结果只有理论值的四分之一。用perf c2c查监听流量才定位到这个问题。解决办法就是上面的布局head 和 tail 之间隔一个缓存行各自加aligned(64)对齐。改动几行代码吞吐量直接上涨了三到四倍。5.2 volatile 并不能解决内存顺序问题很多从单片机转过来的人喜欢用volatile修饰共享变量以为它提供了同步保证。单核裸机时代这可能够用但在多核 Linux 上远远不够。volatile只是告诉编译器每次读都从内存读它既不能保证编译顺序也不能防止 CPU 乱序执行。正确做法是使用__atomic_load_n、__atomic_store_n或者 C11 的_Atomic。这组内置函数不仅生成原子指令还带有编译器屏障和内存序语义。代码里__ATOMIC_RELEASE和__ATOMIC_ACQUIRE是互相对应的关系释放方保证此前写的数据在发布 marker 前可见获取方保证 marker 之后读的数据一定是发布时最新的这一对关系正是无锁队列正确性的基石。5.3 崩溃之后/dev/shm 里的残留文件怎么清理共享内存是持久化的物理内存页即使没有进程引用它shm 文件本身也还存在于 /dev/shm 里。如果服务崩溃前没有调用shm_unlink下次重启时再shm_open(O_CREAT)会直接拿回旧地址可能读到上次残留的脏数据。一个靠谱的经验是服务端在初始化成功之后立刻调用一次shm_unlink(SHM_NAME)。共享内存的对象语义和普通文件不同它允许先删除对象、后续通过已打开的 fd 继续使用。删除之后即使进程崩溃内核也会在所有相关 fd 全部关闭后自动回收页面避免了残留文件问题。这是 POSIX 共享内存里最隐晦也最好用的清理技巧。5.4 不同进程拿到不同虚拟地址禁止互传指针一句话纪律共享内存中只能存偏移量和索引绝对不能存对方进程的虚拟地址。A 进程 mmap 得到 0x7f00…B 进程可能得到 0x7f10…A 把这个绝对地址写进共享内存B 去访问就是访问 B 地址空间里的未知映射等着你的就是 send SIGSEGV。我带过的新人几乎都在这里翻过车。正确的应对是所有结构体内部引用都用偏移量比如指向某个缓冲区的指针就存offset ptr - (char*)q需要时再临时换算回本进程的地址。5.5 权限与挂载大小两个“一开始就定死”的限制POSIX 共享内存文件的权限由 shm_open 的 mode 参数决定。服务端创建时设置了 0666客户端才可能以读写方式打开只设了 0644客户端就不能写入。跨用户运行场景下尤其要注意 umask 可能会吞掉权限位最好在 shm_open 之后用 fchmod 显式补一次权限。另一个限制是 tmpfs 挂载大小。默认 /dev/shm 通常是内存大小的一半但某些容器镜像里可能只挂了 64MB 或者更小。队列要开 1GB 共享内存就必须先检查挂载参数。用df -h /dev/shm看清容量必要时在容器或 fstab 里调整。这个错误不是运行期报错而是一开始ftruncate就可能失败或者映射后访问到一半触发 SIGBUS排查方向很容易跑偏。6. 什么时候不该用共享内存共享内存很强大但它不是万能药。我在工程里反而建议默认优先用 Unix Domain Socket只有确认性能瓶颈时才切共享内存。原因是架构层面的Socket 天然提供消息边界、连接语义、文件描述符传递、多客户端管理能力这些能力共享内存一个都没有。如果你的场景是低频事件传递比如配置变更通知、状态心跳延迟从 1µs 涨到 5µs 根本无感那共享内存的复杂度完全没必要。如果两边是不同团队维护的独立服务共享内存还要定义版本协议、容量协商、生命周期管理沟通成本远大于 Socket 带来的几微秒收益。适合共享内存的永远是同一台机器上的高频数据管道日志采集前端到后端的传输、图像帧传递、高频交易行情分发、嵌入式设备双核之间的物理内存交换。这些场景数据量大、频率高、维护边界清晰共享内存的收益才足够覆盖代价。还有一个技术细节也要注意跨容器时/dev/shm 默认互不可见如果容器共享 PID 或 IPC namespace 还好否则共享内存没法穿透容器边界这种情况老老实实走本地 socket 或者共享卷文件。选型时我的习惯是问三个问题数据频率是否高到让系统调用成本不可接受数据块大小是否值得省那一次内存拷贝两端的生命周期是否能被同一个进程统一管理三个答案都是是才值得动手写共享内存。否则把时间花在哪里都比写一套复杂的共享内存协议划算。最后再分享一个实战习惯每次给共享内存新加字段我都会在队列头里带一个版本号同时把ftruncate的文件大小作为硬约束写进初始化逻辑。版本不匹配直接拒绝启动绝不尝试兼容未知格式。这个习惯帮我挡掉过不下三次线上故障。高性能通信的本质是严格约定共享内存这种高性能交通工具更需要你把交通规则写清楚。
