很多年前我第一次在生产环境里排查性能问题遇到一个诡异的现象两个服务通过消息队列通信流量一大就出现秒级延迟CPU 也没跑满但整个链路就像堵车一样。后来把通信方式换成了共享内存shmem同样的机器配置延迟直接降了两个数量级。从那以后我就养成了一个习惯——凡是进程间高频、大批量交换数据的场景第一反应就是看能不能用共享内存解决。这篇文章想把 shmem 的原理彻底讲透包括内核里发生了什么、为什么它比管道和消息队列快那么多、两套接口System V 和 POSIX怎么选、参数怎么调、以及真正会在生产环境里坑你的那些细节。适合刚接触 Linux IPC 的开发者也适合已经用了共享内存但没想明白底层机制的人。1. 共享内存到底快在哪从页表映射说起1.1 一次拷贝都不做的真相要说清楚共享内存为什么快得先理解普通 IPC 为什么慢。管道、消息队列、Socket本质上都是数据从 A 进程复制到内核缓冲区再从内核缓冲区复制到 B 进程。一次通信至少两次拷贝如果跨网络还得更多。数据量一大拷贝消耗的时间会直接成为瓶颈。共享内存的思路完全不一样。它不拷贝数据而是让两个进程的虚拟地址空间映射到同一组物理内存页上。进程 A 往自己的地址空间写数据进程 B 在自己的地址空间里直接就能看到中间没有内核参与也谈不上数据搬运。这是怎么做到的呢Linux 的进程地址空间是虚拟的进程以为自己拥有完整的内存实际上每个页面都要通过页表映射到真实的物理页框。普通内存分配是我的页表 → 某个物理页。共享内存做的事情是让两个进程的页表条目指向同一个物理页框。我用一个生活化的类比普通 IPC 是两个人通过中间人传话A 把话告诉中间人中间人再告诉 B每句话都要过一遍手共享内存是两个人同时站在一块白板前A 写一个字B 立刻看见不需要任何中间环节。1.2 写时复制不是共享内存的工作方式很多人学操作系统时接触过 Copy On WriteCOWfork 出来的子进程会共享父进程的物理页面只有一方写入时才真正复制。于是就把这个逻辑套到共享内存上以为 shmem 也搞 COW这是一个常见的误解。共享内存本身不具备 COW 语义。两个进程通过 shmat 或者 mmap 映射同一段内存时权限是显式设置的共享的物理页就是同一份。任何一方写入改的就是那份物理内存本身另一方立即可见。这和 fork 的 COW 有本质区别——COW 的共享是临时性的、为了惰性拷贝服务的而共享内存的共享是永久的、目的就是让两边直接读写同一份数据。说个更极端的例子你用shm_openmmap映射一个 1GB 的文件操作系统的缺页异常处理会按需把物理页映射进来但映射成功后这个物理页就是共享的写操作绝对不会有复制一份再改的行为。如果你在代码里观测到写共享内存的速度变慢通常不是 COW 在起作用而是别的机制在影响比如 TLB 抖动或者 NUMA 远端访问。1.3 为什么零拷贝会有这么大优势共享内存常被归入零拷贝方案但这个零拷贝和 sendfile、splice 那种内核态零拷贝不是一回事。sendfile 的零拷贝是数据从磁盘到网卡的过程中避免经过用户态共享内存的零拷贝是数据在进程间传递的过程中避免进出内核态。这种零拷贝带来三个直接收益第一延迟低。一次写加一次读纯用户态两次操作几十纳秒级别就完成了。对比管道write 和 read 各触发一次系统调用还要经过内核缓冲区调度微秒级是常态。第二吞吐高。拷贝的本质是 CPU 执行内存搬运指令数据量大了之后 CPU 周期全耗在 memcpy 上。共享内存省掉这些拷贝动作CPU 可以被用在真正的业务逻辑里。第三锁开销可控。虽然共享内存本身不提供锁机制但它和原子操作配合得很好。两个进程可以直接对共享变量做 CAS不需要像别的 IPC 那样把数据 状态分开传送省了很多同步成本。2. 两套 shmem 接口怎么选System V 与 POSIX 的细节差异2.1 System V 共享内存的老派做法Linux 上最早普及的共享内存接口是 System V 那套核心函数是shmget、shmat、shmdt、shmctl。它的工作流程分三步shmget创建或获取一个共享内存段传入 key 和大小返回一个标识符 shmid。shmat把这段共享内存挂到当前进程的地址空间返回映射后的指针。用完shmdt摘除映射所有进程都不再需要时shmctl(IPC_RMID)删除。这套接口的特点是 key 驱动的。shmget用的 key 是一个整数可以用ftok根据文件路径和项目 ID 生成。这意味着两个独立的进程只要约定同一个文件路径就能拿到同一个共享内存段。这种按名寻址的方式在传统 UNIX 程序里非常常见。不过 System V 接口用起来有几个别扭的地方。shmget创建段的时候必须一次性指定大小不能之后动态扩展。而且删除共享内存段的时机不好掌握——IPC_RMID标记删除后如果还有进程挂着映射这段内存并不会立刻释放直到所有进程都shmdt才会真正回收。这个特性本身是安全的但容易让人误以为删除无效。2.2 POSIX 共享内存的现代风格POSIX 系列接口是后来补充的标准核心函数变成shm_open、mmap、munmap、shm_unlink。它和 System V 最大的区别是把共享内存抽象成了一个文件对象。shm_open打开或创建一个位于 tmpfs 文件系统上的对象路径名以斜杠开头比如/myshm。拿到文件描述符之后用mmap映射到进程地址空间操作方式就和映射普通文件一样。这套接口更符合现代 Linux 的编程习惯。对象生命周期管理清晰shm_open创建的对象内核会维护引用显式shm_unlink之后只要还有人持有映射就能继续用等最后一个映射消失才真正清理。这比 System V 的微妙语义直观不少。POSIX 接口还支持ftruncate调整大小虽然映射区域本身无法动态扩展但至少可以在映射之前灵活设置尺寸用起来比shmget灵活。2.3 生产选型不要只看 API 顺不顺手接触过这两种接口的人通常会觉得 POSIX 版本更友好但生产环境选型不能只看 API 手感。有些老系统、某些嵌入式环境对 POSIX 共享内存的支持并不完整而 System V 接口因为是历史标准兼容性反而更稳。再考虑诊断和运维。System V 共享内存可以用ipcs -m直接查看当前系统中所有的共享内存段包括大小、PID、权限排查问题非常直观。POSIX 共享内存虽然也可以用ls /dev/shm看到文件列表但对象内部的权限和持有者信息不如ipcs那么一目了然。我自己在实际项目里的选型经验是这样的新项目、团队对现代接口接受度高优先用 POSIX 版本代码简洁配合 mmap 操作顺手但如果是维护老系统或者需要频繁用ipcs做监控和清理System V 版本更方便。两种方案没有绝对优劣都是合格工程师需要掌握的工具。3. 内核参数怎么调、代码怎么写从配置到最小可运行示例3.1 影响共享内存的关键内核参数动手写代码之前先搞清楚内核层面有哪些参数会限制你的共享内存使用。这决定了你的程序能开多大的段、能开多少个段。常用的参数有三个kernel.shmmax单个 System V 共享内存段的最大字节数。默认值在 64 位系统上通常是 32MB 左右但很多发行版已经调大到几 GB 甚至更多。需要大段共享内存时必须确认这个值。kernel.shmall允许创建的共享内存页总数单位是页通常 4KB。这个参数限制的是总容量的上限等于说所有共享内存段加起来不能超过这个值。kernel.shmmni系统范围内共享内存段的最大数量默认通常是 4096。如果程序会频繁创建删除共享内存段或者系统里同时跑的服务很多要注意这个限制。POSIX 共享内存没那么受shmmax和shmall约束因为它本质是 tmpfs 文件主要看/dev/shm挂载点的大小。默认情况下/dev/shm是物理内存的一半如果不够用可以临时加大mount -o remount,size8G /dev/shm在生产环境我更推荐直接改/etc/fstab把 tmpfs 那行加上 size 参数避免每次重启都要手动挂载。注意/dev/shm调得太大意味着 tmpfs 可能占用大量物理内存。即使页面长期不写、只是在页表里挂着它依然占据物理页帧不会像普通文件那样被换出到磁盘。务必要按实际需要设置不要无脑给满。3.2 System V 版本完整示例结合前面的原理看一段能直接编译的 C 代码会更直观。这个示例创建一段共享内存父进程写入数据子进程读取#include stdio.h #include stdlib.h #include string.h #include sys/ipc.h #include sys/shm.h #include sys/types.h #include unistd.h #define SHM_SIZE 4096 int main(void) { int shmid; char *shm_addr; pid_t pid; // 用 ftok 生成 key文件路径和项目 ID 双方约定好即可 key_t key ftok(/tmp/shm_test, 42); if (key -1) { perror(ftok); exit(1); } // 创建共享内存段IPC_CREAT | 0666 表示不存在则创建 shmid shmget(key, SHM_SIZE, IPC_CREAT | 0666); if (shmid -1) { perror(shmget); exit(1); } // 挂载到当前进程地址空间 shm_addr shmat(shmid, NULL, 0); if (shm_addr (char *)-1) { perror(shmat); exit(1); } pid fork(); if (pid 0) { perror(fork); exit(1); } if (pid 0) { // 子进程直接读取共享内存里的内容 printf(child read: %s\n, shm_addr); // 摘除映射 shmdt(shm_addr); } else { // 父进程写入内容 strcpy(shm_addr, hello from parent); // 等待子进程结束再清理共享内存段 wait(NULL); shmdt(shm_addr); shmctl(shmid, IPC_RMID, NULL); } return 0; }这段代码结构很典型。ftokshmget做创建和定位shmat做映射读写操作就是对普通指针的操作最后shmdt摘除、shmctl删除。注意父子进程通过fork继承共享内存映射这件事并不适用于两个独立启动的进程——独立进程之间必须各自做shmget和shmat。3.3 POSIX 版本完整示例再来看 POSIX 版本同样实现父子进程间共享内存读写#include fcntl.h #include stdio.h #include stdlib.h #include string.h #include sys/mman.h #include sys/stat.h #include sys/types.h #include unistd.h #define SHM_NAME /my_shm #define SHM_SIZE 4096 int main(void) { int fd; char *shm_addr; pid_t pid; // O_CREAT 不存在则创建O_RDWR 要求读写权限 fd shm_open(SHM_NAME, O_CREAT | O_RDWR, 0666); if (fd -1) { perror(shm_open); exit(1); } // 共享内存对象默认大小为 0必须用 ftruncate 设置目标大小 if (ftruncate(fd, SHM_SIZE) -1) { perror(ftruncate); exit(1); } // MAP_SHARED 表示映射为共享模式对映射区域的修改会写回对象 shm_addr mmap(NULL, SHM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (shm_addr MAP_FAILED) { perror(mmap); exit(1); } pid fork(); if (pid 0) { perror(fork); exit(1); } if (pid 0) { printf(child read: %s\n, shm_addr); munmap(shm_addr, SHM_SIZE); } else { strcpy(shm_addr, hello from parent); wait(NULL); munmap(shm_addr, SHM_SIZE); // 显式删除共享内存对象 shm_unlink(SHM_NAME); } return 0; }POSIX 版本的思路更贴近文件操作shm_open打开一个文件ftruncate设定大小mmap映射到地址空间。这里最容易犯错的是忘记ftruncate因为新建的共享内存对象长度是 0mmap之后一旦访问直接触发 SIGBUS。这个信号基本没法优雅处理程序直接崩溃新手踩这个坑的比例非常高。4. 真正会坑你的不是内存是这些细节4.1 无锁编程只是传说同步永远需要共享内存本身不提供任何互斥机制。两个进程同时写同一块区域会产生数据竞争data race这是 C/C 标准里的未定义行为在实际表现中通常就是数据错乱、程序崩溃。有些场景可以避开锁。比如一个进程只写、一个进程只读并且通过原子操作处理写入完成的标记一个典型方案是生产者在共享内存中准备数据先写数据最后用原子操作__sync_synchronize或者 C11 的atomic_store发布数据就绪的标记。消费者先读取标记确认已就绪再读数据。这种方案对单写单读的队列很有效。但如果存在多写多读或者数据长度不固定老老实实用互斥锁、读写锁、信号量都行。共享内存和锁是配合关系不是替代关系。Linux 下常用的进程间锁有三种pthread_mutex加PTHREAD_PROCESS_SHARED把互斥锁放到共享内存里多个进程共享同一个锁对象。sem_t加pshared参数POSIX 信号量也是放在共享内存中供多进程使用。System V 信号量通过semget创建配合共享内存段使用。我自己用下来单生产者单消费者场景用原子标记 环形队列吞吐最高多生产者场景用pthread_mutex的 process-shared 锁代码可读性最好。4.2 虚假共享和 Cache 行撕裂性能杀手共享内存性能问题里有一个特别隐蔽的坑叫伪共享false sharing。CPU 访问内存是以缓存行cache line为单位的典型大小 64 字节。如果两个进程分别频繁读写共享内存中相距很近的不同变量它们落在同一个缓存行上那么任何一方修改数据都会导致对方的缓存行失效被迫重新从内存加载。结果是明明共享内存省掉了内核拷贝却又因为缓存同步的开销让性能大打折扣。解决办法是空间换时间把高频访问的变量按缓存行对齐或者干脆给每个变量加上 padding让它们分布在不同缓存行上。另外一个方向是缓存行撕裂cache line tearing。如果一个 64 位变量跨越两个缓存行CPU 读这个变量的时候需要锁定两个缓存行性能会下降。对抗手段是保证关键数据结构按 64 字节对齐必要时用__attribute__((aligned(64)))。提示这些优化在单核环境下毫无意义但现代服务器动辄几十核DPDK、数据库等高性能项目里伪共享的损耗可以轻易达到 30% 以上值得认真对待。4.3 内存黑洞共享内存不会自动清理共享内存和普通内存不一样它不随进程退出而消失。如果程序崩溃前没有执行shmctl(IPC_RMID)或者shm_unlink那段共享内存就会一直存在系统里类比重启后还在。如果一个服务频繁崩溃重启每崩溃一次就漏掉一段共享内存最终会把shmall或者/dev/shm空间耗尽。排查这种问题System V 用ipcs -m查看残留段POSIX 用ls -lh /dev/shm看残留文件。处理方式也很直接。System V 残留用ipcrm -m shmidPOSIX 残留用rm -f /dev/shm/shm_name想避免这个问题最稳妥的办法是把清理逻辑写进进程的信号处理流程里或在程序启动时检测到同名的共享内存对象已存在就主动清理重建。4.4 tmpfs 和 page cache 的关系POSIX 共享内存基于 tmpfs它的数据本身是放在 page cache 里的。很多人误以为 tmpfs 是虚构的文件系统数据只存内存不会占用真实物理内存。这个理解既对也不对——准确说法是 tmpfs 的数据占用的就是物理内存只是表现为 page cache 的形式同样会被计入内存占用。这就带来一个实际问题/dev/shm里放了大量数据时free 命令看到的 available 内存会减少。这些数据不受普通文件系统的脏页回写机制影响不会写回磁盘因为 tmpfs 根本没有对应的磁盘后端。在内存压力大的机器上一个没控制好大小的共享内存对象可能直接挤占掉业务进程可用的内存。这不是内核 bug而是 tmpfs 的设计使然。运维监控时要注意区分 cached 和 available别等到 OOM 了才反应过来。5. 常见问题与排查技巧实录5.1 问题速查表现象可能原因排查方法解决方案shmget返回 EINVAL请求大小超过shmmaxsysctl kernel.shmmax查看限制调整shmmax或减小共享内存段大小shm_open返回 EMFILE进程文件描述符耗尽ulimit -n查看限制提高 nofile 限制检查 FD 泄漏mmap之后访问 SIGBUS忘记ftruncate或者映射超过文件大小检查共享内存对象的大小显式ftruncate设置正确长度shmat返回 EACCES共享内存段权限不够ipcs -m查看权限位创建时指定合适的权限或调整属主多个进程映射同一段但数据不一致缺少同步机制检查是否有锁、原子操作引入 process-shared 锁或原子标记性能远低于预期伪共享、缓存行撕裂、NUMA 远端访问perf 分析缓存 miss检查数据对齐按 cache line 对齐分配内存时绑 NUMA 节点系统无法创建更多共享内存段shmmni或shmall耗尽ipcs -m统计数量sysctl查限制清理无用段调整内核参数/dev/shm空间不足tmpfs 大小限制df -h /dev/shm查看使用量mount -o remount,size...调整大小程序退出后共享内存没释放异常退出未执行清理ipcs -m或ls /dev/shm手动ipcrm或rm代码里加清理逻辑共享内存的写操作特别慢可能触发真实的 COW 以外的 refaultvmstat观察 page fault检查是否频繁 munmap/remap减少重复映射5.2 一个真实的生产排查案例我之前维护过一个网关服务它用 System V 共享内存和另外一个分析进程交换流量数据。上线一段时间后突然出现严重的抖动服务延迟从 5ms 涨到了 200ms但 CPU 和内存看起来都正常。先用ipcs -m查看共享内存段发现系统里堆积了几十个残留段再看大小每个段都设定为 64MBshmall默认值早就被吃满了。新的共享内存段创建失败业务代码没做错误处理直接降级到用 Socket 通信性能瞬间崩了。排查过程其实很简单就是先看残留、再验证配置、最后补齐清理机制。但这个问题暴露出来的教训值得分享所有用共享内存的服务启动时和数据段使用完以后都必须有明确的清理动作。它不像 Socket 那样进程结束就自动回收这是共享内存最大的便利也是最大的陷阱。5.3 实测经验和性能数据参考我在一台 32 核的机器上做过一次简单的对比如下两个进程通过 Unix domain socket 通信10 万次小消息往返耗时大约 40ms。换成共享内存加原子标记同样规模的消息耗时不到 3ms。这个差距会随着消息变大而扩大例如 1MB 以上的数据块Socket 的多次拷贝开销会让延迟呈线性增长而共享内存依然稳定在几十微秒级别。做测试时要注意一点环境温度、CPU 频率调度会影响绝对数值更应该关注的是趋势和量级差异。共享内存的延迟优势在微秒和纳秒级别而 Socket 往往在百微秒甚至毫秒量级这种跨数量级的差距才是关键。6. 写在最后做了这么多年 Linux 后台开发共享内存始终是我心里性价比最高的 IPC。它不像 TCP 那样要处理黏包拆包也不像消息队列那样有中间件的额外开销本质上就是给你一块随便写的内存区域有多快完全取决于你怎么用。要说有什么个人体会最重要的一条是共享内存节省的是数据通路的时间省不掉的是并发控制的心智负担。把锁设计好、把清理逻辑写严谨、把缓存行对齐做扎实它就是你高性能架构里最趁手的兵器。如果只是贪图零拷贝的名头就乱用那它很容易变成排查问题时最头疼的黑洞。最后分享一个小经验新代码里我用 POSIX 版本更多但设计文档里我一定写清楚用到的内核参数、预期的对象大小、进程退出时的清理路径。这类基础设施代码做对一次不如说清一次后来人维护起来能少走很多弯路。
