semget 是 Linux 下 System V 信号量的“身份证办理窗口”——你要用信号量做进程间互斥第一步永远是拿它去申请或者获取一个信号量集合semaphore set拿到 semid 之后才有后续的 semop、semctl。很多人第一次接触这个函数是被它的三个参数卡住的key 从哪来、nsems 到底填几、semflg 那一串八进制和宏怎么拼。更让人头疼的是它在“创建”和“获取”两种语义之间反复横跳同一段调用第一次是新建设置第二次是连接已有集合第三次可能直接甩你一个 EEXIST。这篇文章面向已经写过几行 Linux C、但被 SysV 信号量参数搞懵的读者也兼顾想把这套老接口彻底吃透的系统方向同学。我会把三个参数一个个拆开讲清楚它们各自在什么时机被内核读取、失败时对应哪个 errno、哪些组合有意义、哪些组合纯粹浪费还会给出可以直接抄的封装代码和一份踩坑速查表。1. semget 在 System V IPC 里的真实坐标1.1 进程间同步为什么绕不开内核对象线程之间共享地址空间一个 pthread_mutex_t 放在全局变量里就够了进程之间不行两个独立进程的地址空间互不相干你在 A 进程里声明的锁B 进程根本不知道它存在。想跨进程同步必须有第三方来托管这个“锁”的状态而这个第三方就是内核。System V 信号量、共享内存、消息队列这套 IPC 家族本质都是内核维护的一张全局对象表每个对象有个整数 ID进程拿着 ID 去找内核要操作。理解这一点semget 的参数就不再是玄学了。它的工作只有一件告诉内核“我要一张信号量集合的凭证”内核根据你给的 key 去对象表里查查到就把已有的 ID 返给你查不到就看你给不给创建许可给就新建一个再返 ID。所以 semget 从来不做加减操作也不初始化信号量的值它只负责“办证”。信号量值是多少、什么时候 P 什么时候 V那是 semop 的事改权限、设初值、删集合那是 semctl 的事。把职责边界划清后面看参数就顺了。我在带新人的时候常用一个类比把内核的 IPC 对象表想成政务大厅的档案柜key 是你填的申请编号nsems 是你申请的材料份数semflg 是“如果没有档案请新建”加上“这份档案谁能看谁能改”的勾选项。窗口工作人员内核按编号查档案查到了就直接给你档案号查不到再看你有没有勾“允许新建”。这个类比虽然粗糙但能把三个参数的分工讲明白。1.2 semget 的职责边界只“办证”不“上锁”再强调一遍这个边界因为大量 bug 都出在这里。有人以为 semget 返回的 semid 就是一把锁拿到就能互斥其实它只是集合的句柄。真正的互斥发生在 semop 用 P 操作把信号量值从 1 减到 0 的那一刻。也有人以为 semget 会把信号量初始化为 1实测在 Linux 上新建集合的信号量值通常是 0但这个行为并不在标准里明确规定你不能依赖它。正确姿势是semget 拿到 semid 之后立刻用 semctl 的 SETVAL 或者 SETALL 把值设成你要的初值然后再进入 semop 流程。这一点在跨平台场景尤其重要某些 Unix 变体上新建集合的值是未定义的不初始化直接 semop 会出现莫名其妙的时序问题。还有一点semget 本身不是原子的“检查并创建”。两个进程同时用 IPC_CREAT 去创建同一个 key内核会让其中一个成功、另一个也成功返回同一个 ID这没问题但如果你用的是 IPC_CREAT | IPC_EXCL就变成了“必须新建”其中一个必然拿到 EEXIST。这个差异决定了你该选哪个组合后面第 3 节会详细展开。2. 三个参数逐个拆key、nsems、semflg2.1 key_t key内核索引表里的那把钥匙key 的类型是 key_t在 Linux 上就是一个 int。它的取值有两种流派。第一种是 IPC_PRIVATE这个宏的值是 0含义是“别查表了直接给我新建一个”。用 IPC_PRIVATE 创建的集合其他进程没法通过 key 找到它只能靠父进程把 semid 通过 fork 继承或者用别的方式传出去。这种用法适合父子进程之间的私有同步好处是绝对不会和别的程序撞 key坏处是没法做无关进程之间的 rendezvous。第二种是自定义的 key通常通过 ftok 生成。ftok 的原型是key_t ftok(const char *pathname, int proj_id)它把 pathname 对应文件的 st_dev 和 st_ino 拿出来和 proj_id 的低 8 位拼在一起凑成一个 key。这里有几个必须知道的坑pathname 对应的文件必须存在且进程有访问权限否则返回 -1proj_id 只有低 8 位有效你传 A 和传 0x141 得到的 key 是一样的不同文件系统上 st_dev、st_ino 的编码方式不一样同一个路径在容器内外可能算出不同的 key。更麻烦的是 key 碰撞。key_t 只有 32 位去掉一些保留位实际可用的组合并不多两个不相干的项目选中同一个 key 的概率是存在的。碰撞的后果很隐蔽你的进程拿到了别人创建的信号量集合nsems 对不上直接 EINVAL或者凑巧对上了就在别人的信号量上做 P/V把别人系统搞乱。我见过一个团队把 proj_id 随手写成 0结果和同机器上另一个服务的 key 撞了排查了两天才定位到。所以我的建议是如果只是家族内部同步优先用 IPC_PRIVATE 加 fork 继承如果确实需要无关进程 rendezvousftok 的 proj_id 用一个项目内唯一的字符pathname 选一个项目专属、长期存在、路径稳定的文件并且把 key 打到启动日志里方便出问题时用ipcs -s对照。2.2 nsems创建时定容量连接时做校验nsems 是集合里信号量的个数不是“第几个信号量”。这个参数的行为分两种情况。当 key 不存在、你又有创建权限时内核会新建一个有 nsems 个信号量的集合这个数量一旦定下来就改不了后续想扩容只能删了重建。当 key 已经存在时内核会用 nsems 和你已有集合的大小做比较如果 nsems 大于已有数量直接返回 EINVAL如果 nsems 小于等于已有数量则连接成功。这里有个很多人不知道的技巧nsems 传 0 是合法的。当集合已经存在时传 0 相当于“我只想连接不关心里面有几个信号量”内核跳过大小校验直接给你 ID。当集合不存在时传 0 会创建一个空集合但这种集合没什么用因为规模为 0 的集合做什么都 EINVAL。所以 0 的实用场景就是“只获取不创建”配合 semflg 不传 IPC_CREAT 使用是一个干净的存在性探测手段。nsems 的上限受内核参数 SEMMSL 约束这个值在/proc/sys/kernel/sem的第一列。Linux 默认给得很大常见 32000超了返回 EINVAL。但真正容易撞的是系统级上限 SEMMNI也就是整台机器能有多少个集合默认常见 32000以及 SEMMNS所有集合里信号量总数上限。这两个数值在容器环境里经常被调小跑批量任务时 ENOSPC 就是这么来的。实际项目里我一般这么定 nsems一个业务模块只申请一个集合把模块内所有需要同步的资源都放进这个集合用下标区分。这样做的好处是减少集合数量、降低撞 SEMMNI 的风险也方便统一初始化和统一删除。拆成多个集合看起来清晰但每个集合都要走一遍 semget/semctl 流程管理成本反而更高。2.3 semflg权限位与创建标志的位运算组合semflg 是最容易写错、也最容易理解错的一个参数。它本质上是两部分按位或低 9 位是权限位高位是行为标志。权限位和文件权限长得一模一样S_IRUSR(0400)、S_IWUSR(0200)、S_IRGRP(0040)、S_IWGRP(0020)、S_IROTH(0004)、S_IWOTH(0002)。注意信号量没有执行的概念所以 0100、0010、0001 这三位写了也没用。行为标志有三个宏IPC_CREAT 是 01000含义是“不存在就创建”IPC_EXCL 是 02000含义是“和 IPC_CREAT 一起用时已存在就报错”IPC_NOWAIT 是 04000但在 semget 的语境里它没有实际作用这个标志是给 semop、msgrcv 这类可能阻塞的调用准备的写在 semget 里属于误用。这就有四种组合行为完全不同semflg 组合key 不存在key 已存在典型场景0无标志ENOENT返回已有 semid只连接不创建IPC_CREAT新建并返回返回已有 semid幂等获取最常用IPC_CREAT | IPC_EXCL新建并返回EEXIST明确判断“我是不是第一个”IPC_PRIVATE 作为 key总是新建总是新建私有集合与 semflg 无关权限位这里有一个反直觉的点SysV IPC 对象的权限不受 umask 影响。你用 open 创建文件传 0666 但 umask 是 022最后拿到的是 0644但 semget 传 0666 就是 0666内核不会拿 umask 去削它。这意味着你随手写 0666 就等于把信号量暴露给同机器上所有用户配合一个可预测的 key别人可以对你的信号量做任意 P/V。生产环境该用 0600 就用 0600跨用户协作再按需开组权限。另外IPC_CREAT 不检查权限位的变化。集合已经存在时就算你这次传的权限和创建时不一样内核也不会去改它只会原样返回 semid。想改权限得用 semctl 的 IPC_SET。这一点很多人踩过以为 semget 传 0666 就能把之前 0600 的集合改成可读可写结果一直 EACCES。2.4 返回值与 errno 的对应关系成功时返回一个非负整数 semid失败返回 -1 并设置 errno。semid 的值是可以复用的删掉一个集合之后新建的集合可能拿到同一个 ID所以不要把 semid 当唯一标识长期缓存尤其是跨进程场景。errno 是排查 semget 问题的唯一线索必须一个个记住errno触发条件排查方向EACCES集合已存在但当前进程无权限看 ipcs -s 的 perms 列对照进程 euid/egidEEXIST用了 IPC_CREAT|IPC_EXCL 且集合已存在说明别人先创建了转入连接流程ENOENTkey 不存在且没传 IPC_CREAT要么补 IPC_CREAT要么先跑初始化流程EINVALnsems 小于 0、或大于已存在集合的大小、或超 SEMMSL打印 nsems 和 ipcs -s 的 nsems 列对照ENOSPC集合数达 SEMMNI或信号量总数达 SEMMNS用 ipcs -s 数一下清理残留集合ENOMEM内核内存不足少见多半是系统整体资源紧张EFAULT参数地址非法基本只在传了坏指针时出现纯 C 代码里少见我遇到最多的是 EACCES 和 EINVAL。EACCES 往往是因为服务以非 root 用户跑但信号量是 root 创建的、权限 0600切换用户后必然连不上。EINVAL 则多半是代码里 nsems 写了个常量 3实际上集合是上一个版本用 nsems1 创建的残留没清干净。这两种问题的共同点是错误信息本身不告诉你现场长什么样你必须自己上ipcs -s去看。3. 从零写一个能复用的 semget 封装3.1 原子创建加容错获取的标准写法裸调 semget 的代码通常长这样问题是一旦 EEXIST 就崩了。真实项目里我们需要的是“首次创建、后续连接、并且能区分这两种情况”的语义。下面这段封装我用了好几年改改就能直接用#include sys/types.h #include sys/ipc.h #include sys/sem.h #include errno.h #include stdio.h /* 返回 semidcreated 输出 1 表示本次新建0 表示连接已有-1 表示失败 */ int sem_get_or_create(key_t key, int nsems, int perm, int *created) { int semid; *created 0; semid semget(key, nsems, IPC_CREAT | IPC_EXCL | perm); if (semid 0) { *created 1; return semid; } if (errno ! EEXIST) { perror(semget create); return -1; } /* 已存在连接它nsems 传 0 跳过大小校验 */ semid semget(key, 0, 0); if (semid 0) { perror(semget attach); return -1; } return semid; }这段代码的关键在两次调用。第一次用 IPC_CREAT | IPC_EXCL成功了说明自己是创建者可以放心去 setval 初始化失败了且 errno 是 EEXIST说明别人先到了第二次用 nsems0、semflg0 去连接。为什么要用两次而不是一次 IPC_CREAT 搞定因为一次调用你分不清自己是创建者还是连接者而初始化动作只能由创建者做一次重复初始化会把别人正在用的信号量值重置直接破坏互斥。这个“创建者负责初始化”的模式在 System V IPC 里是通用范式共享内存的 shmget、消息队列的 msgget 都是同样的套路。你把这套写熟了三种 IPC 的初始化代码几乎可以复制粘贴。再说 IPC_EXCL 的一个细节它单独使用没有意义。man 手册写得很清楚IPC_EXCL 只有在和 IPC_CREAT 同时存在时才有效果单独传 IPC_EXCL 会被忽略。所以别写出semget(key, nsems, IPC_EXCL)这种代码它等价于 semflg0。3.2 权限位怎么算八进制 0666 到底给了谁权限位这块我建议直接用八进制字面量别去拼 S_IRUSR 这些宏因为信号量的权限模型和文件完全一样八进制一眼能读懂。0600 是只有属主可读写0660 是属主和同组可读写0666 是所有人可读写。谁算属主创建时进程的 euid 就是属主egid 就是属组之后权限检查就按这套 euid/egid 走。问题在于服务类程序经常有权限切换。比如一个守护进程以 root 启动drop privilege 到业务用户之后再 semget这时如果集合是 root 创建的、权限 0600业务用户就拿不到 EACCES。反过来如果业务用户先创建root 后来想操作root 有 CAP_IPC_OWNER 可以绕过权限检查没这个 capability 的受限容器里就会失败。我的经验是把创建信号量的动作放在权限已经稳定的阶段。如果服务必须 root 启动再降权那就在降权之前创建好信号量权限设成 0660把业务用户加进属组或者干脆在降权之后创建让属主和属组天然就是业务用户。不要在两个阶段之间来回切换那是最容易出 EACCES 的写法。还有一个隐蔽点容器里的 IPC namespace 是隔离的。你在宿主机上ipcs -s看到的集合在容器里ipcs -s可能完全看不到因为 namespace 不同。这既是好事天然隔离不会和宿主机撞 key也是坑排查时你在宿主机上死活找不到容器里那个集合。排查容器内信号量问题必须 exec 进容器去执行 ipcs。3.3 初始化信号量的时机与 semctl 配合拿到 semid 且确认自己是创建者之后下一步是设初值。用 semctl 的 SETVAL 命令union semun { int val; struct semid_ds *buf; unsigned short *array; }; int sem_set_val(int semid, int idx, int val) { union semun arg; arg.val val; return semctl(semid, idx, SETVAL, arg); }这里有个历史遗留问题union semun 在 glibc 的头文件里没有定义需要调用方自己声明。有些新版本 glibc 在_GNU_SOURCE下会给出定义但为了兼容性自己写一份是最稳的。如果你把这段代码编译到只支持 POSIX 的环境可能会报重复定义加个条件编译或者改个名字就行。初值设多少互斥锁场景设 1计数信号量场景设你的资源池大小。要注意 SETVAL 是立即生效的如果你在“创建者初始化”和“其他人开始 semop”之间存在时间窗口别人可能在你初始化之前就抢到了信号量。标准做法是在创建完成后立刻初始化中间不做任何可能阻塞的操作更严格的做法是在初始化完成之前用一个额外的“就绪标志”信号量或者文件锁挡住其他进程等全部初始化完毕再放开。删除集合用 semctl 的 IPC_RMID不需要任何参数。什么时候删我的建议是服务优雅退出时删异常退出时留着也无妨因为下次启动的“连接已有集合”流程能接上信号量的值可能会残留成错误状态。这时候就需要一个恢复机制在服务启动时如果是连接已有集合先用 semctl GETVAL 读一遍当前值如果和预期初值不符说明上次异常退出留下了脏数据直接 SETVAL 重置。这个重置有风险如果确实有别的进程正在用这个集合重置会破坏它的状态。所以更稳妥的做法是给集合打一个“属主 PID”的标记比如再开一个信号量存 PID检测到属主已死才重置。4. 参数用错时的真实故障现场4.1 EEXIST 与 ENOENT 的拉锯两个进程互相“看不见”有一类故障特别典型A 进程和 B 进程用同一个 key 调 semget但一个一直 EEXIST另一个一直 ENOENT看上去像内核状态错乱。实际原因通常有三种。第一种是 ftok 的 pathname 在两个进程的工作目录下解析到了不同文件比如传了相对路径。ftok 用的是真实文件的 inode相对路径在不同 cwd 下指向不同 inode算出来的 key 自然不同。修复很简单pathname 一律写绝对路径。第二种是容器或 chroot 环境导致路径映射不一致A 看到的是/data/app.confB 看到的是/mnt/data/app.conf两个路径指向同一个物理文件但 inode 不同。这种问题的排查手段是把 ftok 返回的 key 打日志两边对一下就知道是不是同一个 key 了。第三种是 key 碰撞的反向版本两个不相干的项目用了同一个 keyA 的集合存在导致 B 拿到 EEXISTB 清理时把 A 的集合删了导致 A 下次 ENOENT。这种问题的特征是“故障和业务逻辑无关随机出现重启就好”。定位方法是ipcs -s看 key 列如果发现自己的 key 对应的 semid 变来变去基本就是撞了。修复就是换 proj_id。我在一个多服务同机部署的场景里踩过这个坑。当时三个服务都用 ftok(/tmp, S) 生成 key单机测试时因为启动顺序固定没出问题上了生产环境三个服务并发启动信号量互相删来删去日志里 ENOENT 和 EEXIST 交替出现。后来统一改成 ftok(/etc/svc-a.conf, A) 这种项目专属路径加专属字符问题就消失了。教训是key 的生成规则要当成配置项来管理不能随手糊一个。4.2 nsems 传大了直接 EINVALnsems 的 EINVAL 有两个来源一个是超过 SEMMSL 上限一个是大于已存在集合的大小。前者容易发现因为错误稳定出现查一下/proc/sys/kernel/sem就知道后者才有迷惑性因为它取决于“集合是不是已经存在”第一次运行没问题第二次运行就报错看起来像偶发故障。具体场景是这样的代码里 nsems 写死 4第一次运行创建了 4 个信号量的集合正常。后来有人把代码改成 nsems8但没清理旧的 4 个信号量的集合重启后 semget 发现集合已存在8 4直接 EINVAL。修复要么清理旧集合ipcrm -s semid要么把 nsems 改回 4。但在生产环境里改 nsems 意味着集合语义变了正确的做法是删旧建新并且在删除和新建之间保证没有进程在用。这个话题延伸出一个工程约束nsems 一旦定了就不要随便改。如果你预见到业务会扩张宁可一开始申请大一点多出来的信号量闲置不用成本几乎为零。信号量本身不占多少内存集合数量才是稀缺资源。我一般会在设计阶段就把模块内所有可能用到的同步点列出来nsems 取个有余量的值比如实际用 5 个就申请 16 个后面加功能不用动 semget。4.3 残留集合与系统上限ipcs -s输出里经常能看到一堆没人用的集合key 是 0x00000000这就是 IPC_PRIVATE 创建后被遗弃的。这类集合没有 key 能被别人连接只能靠 semid 或者创建者自己记住进程退出后如果没 IPC_RMID它就永远留在内核里直到重启。残留集合的危害是累积达到 SEMMNI。现代 Linux 默认 SEMMNI 很大不太容易撞但在容器里经常被 cgroup 或者启动参数调小几百个残留集合就能把上限吃满后续 semget 全部 ENOSPC。更麻烦的是 ENOSPC 的错误信息不告诉你“是谁占满了”你得自己数。我的习惯是给每个集合配一个清理脚本用 key 前缀或者固定的 key 段来识别自己的集合启动时先扫一遍把 key 匹配的孤儿集合删掉。ipcs -s的输出格式固定用 awk 提取 semid 和 key 就行ipcs -s | awk $1 ~ /^0x/ $2 ~ /^0x0*61/ { print $2 } | while read id; do ipcrm -s $id done上面这个只是示例实际要按你自己的 key 规则写匹配条件。注意别写错匹配范围把别人的集合删了是要出事故的。稳妥一点的做法是在集合创建时把 semid 写到一个 pid 文件里退出时按文件删异常退出则靠下次启动时的检测逻辑收拾。5. 参数设计背后的取舍与选型建议5.1 为什么是 key 而不是路径名看到这里你可能会问为什么 SysV 信号量要用一个整数 key 来寻址而不是像 POSIX 信号量那样直接用名字这就要回到设计年代了。System V IPC 成型于 1980 年代初那时候文件系统命名空间、路径解析、权限模型都还没有今天这么统一用一个 32 位整数做全局索引是最简单、最省内核结构的方案。内核只要维护一张哈希表key 到对象查找是 O(1)。这个设计的代价是把“命名”这件事推给了用户。key 怎么生成、怎么保证唯一、怎么跨进程约定全得你自己解决于是 ftok 这种“拿文件 inode 凑 key”的补丁式方案才出现。ftok 的本质是把文件系统当成了命名服务的替代品但它的碰撞率和环境依赖又带来了新问题。相比之下POSIX 信号量直接用sem_open(/name, ...)名字就是一个路径风格的字符串内核负责在 tmpfs 里维护命名空间语义干净得多。那为什么今天还有大量代码用 SysV 信号量因为存量。大量老系统、老库、老中间件用的都是这套接口新代码想和它们协作就得跟上。另外 SysV 信号量有个 POSIX 信号量没有的特性它是“集合”一次可以原子地操作多个信号量semop 支持一次传一个 sembuf 数组内核保证这批操作要么全成功要么全失败。这个能力在需要同时锁多个资源的场景里很有用POSIX 信号量只能一个个来得自己处理死锁。5.2 System V 和 POSIX 信号量的参数对比如果你正在选型下面这张表可以帮你快速判断。参数层面的差异其实反映了两种设计哲学SysV 是“内核对象 用户约定 key”POSIX 是“命名空间 文件描述符”。维度System V 信号量POSIX 命名信号量创建/获取接口semget(key, nsems, semflg)sem_open(name, oflag, mode, value)寻址方式32 位 key需自行保证唯一路径风格字符串内核维护命名空间初值设置创建后单独 semctl SETVALsem_open 时直接给 value原子完成权限模型semflg 低 9 位不受 umask 影响mode 参数受 umask 影响是否支持集合支持nsems 个信号量原子操作不支持一个名字一个信号量生命周期显式 IPC_RMID 删除否则常驻内核sem_unlink 删除名字已打开者继续可用系统上限SEMMNI / SEMMNS / SEMMSL 三个参数受文件描述符和 tmpfs 容量约束调试工具ipcs -s / ipcrm -sls /dev/shm或 sem 相关调试接口从参数设计上看semget 最不讨喜的地方就是“创建”和“获取”混在一个调用里必须靠 semflg 的位组合来区分意图还得配合两次调用才能拿到“我是不是创建者”的信息。POSIX 的 sem_open 用 O_CREAT 和 O_EXCL 两个独立标志语义更直白而且 open 的返回值直接就是句柄不需要额外的 ID 概念。但 SysV 也不是没有优势。它的集合语义在复杂同步场景里确实好用比如生产者消费者模型里“空位”和“满位”两个计数需要同时调整用 semop 一次提交两个操作就能保证原子性。另外 SysV 信号量的权限检查和文件系统解耦在 chroot 或者 rootfs 只读的环境里更省心不需要 /dev/shm 可写。我的实际选型原则是新项目、只需要单信号量、追求代码可读性用 POSIX 信号量需要和存量 SysV 代码协作、或者确实需要集合原子操作、或者部署环境 /dev/shm 不可用用 SysV。不要因为“SysV 是老的所以不能用”就一刀切也不要因为“老代码都用它”就无脑跟看场景。最后分享一个我这些年养成的习惯凡是涉及 semget 的模块我都会在第一行注释里写清楚三件事——key 的生成规则、nsems 的预期值、权限位的含义。这三样东西一旦写进代码半年后接手的人很可能就是你自己能省下大量猜测时间。信号量这种内核对象出问题时现场信息太少能提前写在代码里的线索就别省。还有一个实操小技巧调试阶段可以故意把 semflg 的权限位设成 0777让任何用户都能连上来方便你用不同账号跑测试程序去观察行为上线前统一改成 0600 或 0660。改的时候用 grep 搜一遍整个仓库的 semget 调用确保没有漏网之鱼因为这类权限漏洞不会在功能测试里暴露只有安全审计才会翻出来。我在实际使用中发现semget 最容易被低估的参数其实是 nsems因为它不像 key 那样需要你主动设计、也不像 semflg 那样有一堆位要拼很多人随手写个 1 就过去了。但恰恰是这个随手写的 1在业务扩张时成了绊脚石——想加第二个同步点发现集合里没位置删旧建新又怕影响正在跑的服务最后只能再申请一个集合管理复杂度翻倍。踩过几次这样的坑之后我现在设计阶段就会把 nsems 定得宽松一些宁可浪费几个信号量槽位也不给自己留技术债。