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、semflg
2.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 对应的文件必须存在且进程有访问权限，否则返回 -1；proj_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 继承；如果确实需要无关进程 rendezvous，ftok 的 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/egid |
| EEXIST | 用了 IPC_CREAT|IPC_EXCL 且集合已存在 | 说明别人先创建了，转入连接流程 |
| ENOENT | key 不存在且没传 IPC_CREAT | 要么补 IPC_CREAT，要么先跑初始化流程 |
| EINVAL | nsems 小于 0、或大于已存在集合的大小、或超 SEMMSL | 打印 nsems 和 ipcs -s 的 nsems 列对照 |
| ENOSPC | 集合数达 SEMMNI，或信号量总数达 SEMMNS | 用 ipcs -s 数一下，清理残留集合 |
| ENOMEM | 内核内存不足 | 少见，多半是系统整体资源紧张 |
| EFAULT | 参数地址非法 | 基本只在传了坏指针时出现，纯 C 代码里少见 |
我遇到最多的是 EACCES 和 EINVAL。EACCES 往往是因为服务以非 root 用户跑，但信号量是 root 创建的、权限 0600，切换用户后必然连不上。EINVAL 则多半是代码里 nsems 写了个常量 3，实际上集合是上一个版本用 nsems=1 创建的，残留没清干净。这两种问题的共同点是：错误信息本身不告诉你现场长什么样，你必须自己上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> /* 返回 semid，created 输出 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，说明别人先到了，第二次用 nsems=0、semflg=0 去连接。为什么要用两次而不是一次 IPC_CREAT 搞定？因为一次调用你分不清自己是创建者还是连接者，而初始化动作只能由创建者做一次，重复初始化会把别人正在用的信号量值重置，直接破坏互斥。
这个“创建者负责初始化”的模式，在 System V IPC 里是通用范式，共享内存的 shmget、消息队列的 msgget 都是同样的套路。你把这套写熟了，三种 IPC 的初始化代码几乎可以复制粘贴。
再说 IPC_EXCL 的一个细节：它单独使用没有意义。man 手册写得很清楚，IPC_EXCL 只有在和 IPC_CREAT 同时存在时才有效果，单独传 IPC_EXCL 会被忽略。所以别写出semget(key, nsems, IPC_EXCL)这种代码，它等价于 semflg=0。
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.conf，B 看到的是/mnt/data/app.conf，两个路径指向同一个物理文件但 inode 不同。这种问题的排查手段是把 ftok 返回的 key 打日志，两边对一下就知道是不是同一个 key 了。
第三种是 key 碰撞的反向版本：两个不相干的项目用了同一个 key，A 的集合存在导致 B 拿到 EEXIST，B 清理时把 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 传大了直接 EINVAL
nsems 的 EINVAL 有两个来源，一个是超过 SEMMSL 上限，一个是大于已存在集合的大小。前者容易发现，因为错误稳定出现，查一下/proc/sys/kernel/sem就知道；后者才有迷惑性，因为它取决于“集合是不是已经存在”，第一次运行没问题，第二次运行就报错，看起来像偶发故障。
具体场景是这样的：代码里 nsems 写死 4，第一次运行创建了 4 个信号量的集合，正常。后来有人把代码改成 nsems=8，但没清理旧的 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 SETVAL | sem_open 时直接给 value，原子完成 |
| 权限模型 | semflg 低 9 位，不受 umask 影响 | mode 参数，受 umask 影响 |
| 是否支持集合 | 支持，nsems 个信号量原子操作 | 不支持，一个名字一个信号量 |
| 生命周期 | 显式 IPC_RMID 删除，否则常驻内核 | sem_unlink 删除名字，已打开者继续可用 |
| 系统上限 | SEMMNI / SEMMNS / SEMMSL 三个参数 | 受文件描述符和 tmpfs 容量约束 |
| 调试工具 | ipcs -s / ipcrm -s | ls /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 定得宽松一些，宁可浪费几个信号量槽位，也不给自己留技术债。
