搞并发服务这些年进程间互斥这块我踩过的坑比写过的代码还多。很多同事一开始觉得不就是加把锁嘛让多个进程别同时操作同一份资源就行。结果真上线了才发现锁没加上、持锁进程崩了、锁没被释放、死锁导致服务假死……问题一个接一个。今天我把进程间互斥的几种主流方式挨个拆开讲一遍包括每种方式的原理、适用场景、具体踩坑点最后说清楚到底怎么选型。先说清楚一个事我这里的“进程”指的不是线程。同一个进程里多个线程互斥很简单一把pthread_mutex就够了。但多进程场景下每个进程有独立的地址空间单纯的线程锁根本不通用必须借助操作系统提供的跨进程锁机制。常见方案就这么几类文件锁flock/fcntl、信号量System V和POSIX两套、共享内存配合互斥锁pthread_mutex、futex等底层机制、以及基于文件锁衍生出的“单实例守护进程”玩法。每个思路背后都是一套权衡我把它们按“上手难度”和“底层原理”两个维度串起来讲。1. 先想明白进程间互斥到底在解决什么问题1.1 为什么会有互斥需求你再怎么优化架构总有几个场景绕不开多个进程同时碰同一份资源多进程写入同一个日志文件日志互相穿插读出来的东西全是“缝合怪”。多进程并发操作同一张数据库表或者同一个Redis key导致覆盖更新。多个worker进程同时消费同一个目录下的任务文件文件被重复处理。多个实例部署在同一台机器上同时开始做定时任务任务被重复执行。这些问题本质都一样多个执行流并发访问同一个临界资源如果不做互斥就会产生竞态条件轻则数据不对重则整个进程崩溃。互斥锁的核心目标就一句话——保证任意时刻只有一个进程能进入临界区。1.2 选型前需要明确的几个关键问题动手之前有几个问题必须先问自己不然很容易走进死胡同进程间是否有亲缘关系有亲缘同一父进程fork出来的用共享内存加锁就能解决无亲缘完全独立的进程就得靠文件系统、信号量或命名对象。锁粒度要求多高是几毫秒的短临界区还是要长时间持有进程异常退出锁能不能自动释放这一条最容易被忽略。崩溃了、被kill -9了锁如果还在其他进程就会永久阻塞。性能要求量级每秒几百次操作还是每秒几十万次量级不同选的方案完全不一样。这些问题的答案直接决定方案选型。千万别上来就抄代码先搞清楚场景再动手。2. 文件锁实战最省事、最稳的跨进程互斥方案2.1 flock与fcntl锁的核心差异文件锁是进程间互斥最接地气的实现方式。原理上说穿了很简单把某个文件当成锁的载体进程通过加锁/解锁文件来宣告“这块地盘我占了”。Linux下有两大门派flock和fcntl。两者都支持读锁共享锁和写锁排他锁但细节差异很大特性flockfcntl锁粒度整个文件文件区域可以锁任意字节段锁语义建议锁基于打开文件表的描述符建议锁基于进程文件inode按进程记录同一进程重复打开第二个fd加锁会互相干扰可转换同一进程对同一文件加锁会合并/替换fork后行为fd被复制锁也继承锁不随fork继承子进程不会自动获得与NFS兼容传统flock在NFS上不工作新内核部分支持部分NFS实现支持fcntl锁API复杂度一个函数搞定需要设置struct flock结构体实际项目里我90%的场景都用fcntl不是因为它好用而是因为它的行为更接近我想要的“进程级锁”。flock的锁是和fd绑定而不是和进程绑定的这在某些场景会出幺蛾子——见后面避坑节。2.2 用fcntl写一把可用的进程锁fcntl加锁的核心结构体是struct flock代码长这样#include fcntl.h #include unistd.h #include stdio.h #include string.h #include errno.h int lock_file(int fd, int type) { struct flock fl; memset(fl, 0, sizeof(fl)); fl.l_type type; /* F_RDLCK 共享读锁 / F_WRLCK 排他写锁 / F_UNLCK 解锁 */ fl.l_whence SEEK_SET; /* 从文件头开始算偏移 */ fl.l_start 0; /* 锁区域起点 */ fl.l_len 0; /* 0 表示锁到文件末尾 */ fl.l_pid getpid(); /* 记录持有锁的进程PID */ return fcntl(fd, F_SETLK, fl); }注意F_SETLK是非阻塞的。如果锁被占用fcntl会立即返回-1errno为EACCES或EAGAIN。想阻塞等待就改用F_SETLKW。真实项目里我强烈建议先用非阻塞方式探测配合超时重试逻辑而不是傻等。为什么因为无脑阻塞太危险了——持锁进程没释放锁的话你就是等死。再看完整的加锁流程#include fcntl.h #include unistd.h #include stdio.h #include string.h #include errno.h #define LOCK_FILE /tmp/myapp.lock int try_lock(int fd) { struct flock fl; memset(fl, 0, sizeof(fl)); fl.l_type F_WRLCK; fl.l_whence SEEK_SET; fl.l_start 0; fl.l_len 0; if (fcntl(fd, F_SETLK, fl) -1) { if (errno EACCES || errno EAGAIN) return 0; /* 锁被占用 */ perror(fcntl); return -1; } return 1; /* 成功获取 */ } int main() { int fd open(LOCK_FILE, O_RDWR | O_CREAT, 0666); if (fd 0) { perror(open); return 1; } int ret try_lock(fd); if (ret 0) { printf(另一进程持有锁退出\n); close(fd); return 1; } if (ret 0) { close(fd); return 1; } printf(拿到锁开始干活 pid%d\n, getpid()); sleep(10); /* 模拟临界区 */ /* 解锁 关闭fd。注意close也会释放所有锁 */ struct flock fl; memset(fl, 0, sizeof(fl)); fl.l_type F_UNLCK; fl.l_whence SEEK_SET; fcntl(fd, F_SETLK, fl); close(fd); return 0; }这段代码有几个点要展开解释第一为什么用O_CREAT因为锁文件可能还不存在创建出来当“锁的载体”。这个文件本身不承载业务数据只承载“锁状态”所以永远别用锁文件存内容。第二为什么l_len 0POSIX标准里l_len 0表示从l_start到文件末尾如果文件为空就表示锁整个文件直到任何可能写入延伸的位置。这样写最省心。第三为什么锁完要sleep模拟这是临界区的替身。真实场景里临界区就是你保护的那段业务逻辑——写日志、改配置、处理任务文件。第四真正生产环境会加超时重试。比如锁被占用就每秒重试一次3次还不行就报警退出不会无限死等。这么做能避免程序挂在“等锁”上。2.3 文件锁的自带福利进程崩了锁自动释放文件锁最让人放心的特性就是无论是进程正常退出close、还是崩溃内核在进程退出时自动释放所有fd和锁都不会出现“死锁长存”问题。这个特性让文件锁成为我写“单实例守护进程”时的首选方案。单实例守护进程是文件锁最经典的玩法。需求很简单某定时任务只能同时跑一个实例如果上一次的还没跑完这一次直接退出。实现方式就是在启动时对锁文件加排他锁拿到锁就继续拿不到就退出#!/bin/bash exec 9/tmp/myjob.lock if ! flock -n 9; then echo 另一个实例正在运行 exit 1 fi # 进入临界区 echo 开始任务... sleep 30shell里用flock -n一行就搞定了。C语言里用open fcntl道理完全一样。这在业务上非常实用——很多定时任务框架比如crontab如果上一次任务还没结束下一次又会触发不加文件锁任务就会重叠执行出各种乱子。我在生产环境里见过一次最典型的事故两台机器同时部署了同一个定时任务脚本脚本里没加锁结果两台机器同时处理同一批订单状态订单被重复发货。后来加上文件锁一台一台做“领导者选举”问题再没出现过。3. 信号量老牌的System V与现代POSIX之争3.1 System V信号量功能强但API别扭文件锁是“慢动作”选手适合秒级甚至分钟级的操作。如果要保护更细粒度的资源比如共享内存里的一块数据信号量是更正统的进程间互斥手段。System V信号量的核心API是semgetsemopsemctl三件套。裸API对一个“就想加个锁”的开发者来说简直是劝退级的复杂度——一个semop要填struct sembuf一个semctl要传一堆参数。更烦人的是System V信号量存在“手动尸体清理”问题最后一个进程走了信号量对象还残留在内核里必须再写代码semctl(IPC_RMID)删除。程序反复启动退出内核里残留一堆没用的信号量时间长了ipcs -s一看就是一坨。我实际用它时都会封装一个简单的RAII类或C语言里的 init/destroy 函数构造时semgetsemctl(SETVAL)初始化计数析构时semctl(IPC_RMID)清理。但即便如此一旦进程被kill -9析构函数不执行残留还是在。所以用System V必须搭配“启动时检查清理”的逻辑否则就是个隐患。3.2 POSIX信号量名字优雅行为更现代POSIX信号量把这个痛解决了一部分并且API更简洁,主要有两个派系命名信号量named semaphore, 类似/mysem这种名字进程间随时可以共享连接和内存信号量unnamed semaphore要放在共享内存里才能跨进程。命名信号量用法最简单#include fcntl.h #include sys/stat.h #include semaphore.h #include stdio.h #include unistd.h int main() { /* 创建或打开一个命名信号量初始值为1互斥锁 */ sem_t *sem sem_open(/myapp_sem, O_CREAT, 0666, 1); if (sem SEM_FAILED) { perror(sem_open); return 1; } printf(pid%d 等待信号量...\n, getpid()); if (sem_wait(sem) -1) { perror(sem_wait); return 1; } printf(pid%d 拿到锁进入临界区\n, getpid()); sleep(5); sem_post(sem); /* 释放 */ sem_close(sem); /* 关闭连接 */ return 0; }sem_wait是阻塞的不想死等可以用sem_trywait非阻塞或sem_timedwait带超时。sem_timedwait是我最推荐的它能在锁竞争时给出的“等待上限”避免一台机器上的某一个进程永远卡住。但是POSIX命名信号量有个坑必须牢记/name这种命名方式不同平台行为有差异。Linux下以/开头名字最长不超过NAME_MAX-4通常 251 字节创建出来是放在虚拟文件系统里的用ls /dev/shm/能看到。但要注意如果信号量是被sem_unlink了但还有进程持有fd这个信号量不会真正销毁直到最后一个fd关闭。这个行为和Unix socket的“先unlink后连接”有点像理解了就不会慌。POSIX命名信号量最大的一个坑在于——如果你频繁创建/销毁信号量就会在/dev/shm或者/run下的一些临时文件系统留下垃圾文件。我把一条清垃圾命令写进定位文档了ls -l /dev/shm/ | grep sem没想到吧排查问题第一步竟然是看这个目录。3.3 System V vs POSIX到底用哪个以我的经验新项目直接用POSIX别碰System V。理由有三个POSIX信号量的API更安全、更不容易写错。一个sem_t加三四个函数就够了。POSIX具备超时语义sem_timedwaitSystem V的semop要模拟超时还得加SEM_UNDO和闹钟信号非常痛苦。POSIX更贴近现代编程习惯后续要扩展成“共享内存信号量”也顺路。但有个例外如果你要兼容老代码、或者需要跨平台必须考虑System V的可用性。有些看似老的系统对POSIX支持不完整那个场景下System V更稳。不过我合作过的项目里99%都直接上POSIX。4. 共享内存互斥锁高性能场景的杀手锏4.1 为什么需要共享内存这一层文件锁和信号量虽然能保证互斥但它们都是“慢悠悠”的同步手段。如果两个进程要共享一个大的数据结构比如一张百万级的哈希表、一段实时更新的监控数据每次都把数据写到文件里再锁来锁去性能根本扛不住。共享内存的思路是让多个进程的虚拟地址空间映射到同一块物理内存进程间直接读写同一块内存不需要拷贝。这是速度最快的进程间通信方式没有之一。但快归快同步还得自己做——多个进程同时往同一块内存写数据不加锁照样崩。4.2 实现方式共享内存里放pthread_mutex常规操作是用shm_open或System V的shmget分配一块共享内存然后在这块内存的头部放一个pthread_mutex_t其他位置放业务数据。这里有个关键点pthread_mutex默认是进程私有的必须设置PTHREAD_PROCESS_SHARED属性才能跨进程使用。完整步骤拆解用shm_openftruncate创建一块共享内存并设置大小。用mmap映射到当前进程。把共享内存首地址转型成pthread_mutex_t*初始化时设置pthread_mutexattr_t attr; pthread_mutexattr_init(attr); pthread_mutexattr_setpshared(attr, PTHREAD_PROCESS_SHARED); pthread_mutex_init(mutex, attr);后续所有进程都用pthread_mutex_lock/pthread_mutex_unlock操作这把锁。代码示例#include sys/mman.h #include sys/stat.h #include fcntl.h #include pthread.h #include unistd.h #include stdio.h #include string.h #define SHM_NAME /myapp_shm #define SHM_SIZE (4096) typedef struct { pthread_mutex_t mutex; int counter; char data[1024]; } shared_data_t; int main() { int fd shm_open(SHM_NAME, O_CREAT | O_RDWR, 0666); if (fd -1) { perror(shm_open); return 1; } if (ftruncate(fd, SHM_SIZE) -1) { perror(ftruncate); return 1; } shared_data_t *shared mmap(NULL, SHM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (shared MAP_FAILED) { perror(mmap); return 1; } close(fd); /* mmap之后fd可以关掉 */ /* 第一个进程负责初始化mutex */ static int initialized 0; if (!initialized) { pthread_mutexattr_t attr; pthread_mutexattr_init(attr); pthread_mutexattr_setpshared(attr, PTHREAD_PROCESS_SHARED); pthread_mutex_init(shared-mutex, attr); pthread_mutexattr_destroy(attr); shared-counter 0; initialized 1; } pthread_mutex_lock(shared-mutex); shared-counter; printf(pid%d, counter%d\n, getpid(), shared-counter); pthread_mutex_unlock(shared-mutex); /* 简化示例不演示内存清理 */ return 0; }这段代码里最容易翻车的就是initialized这个标志 —— 它是每个进程自己判断的不是真正“只初始化一次”。如果两个进程同时启动可能都看到initialized 0然后都去pthread_mutex_init直接双重初始化崩溃。怎么解决最简单的做法是让第一个启动的进程负责初始化。怎么判断谁是第一个可以用一个标志位配合原子操作C11的atomic_flag、GCC的__sync_bool_compare_and_swap或者干脆在共享内存里放一个“初始化完成”标记所有进程启动时检查并CAS置位。如果CAS失败说明别人在初始化自己等待即可。4.3 谁负责销毁共享内存共享内存不像命名的POSIX信号量那样自动清干净。进程退出后共享内存对象还留在内核里/dev/shm下能看到必须显式调用shm_unlink才能删除。如果忘了删下次启动时会拿到旧的、未初始化干净的内存数据全乱了。我的经验是共享内存的销毁交给“最后一个离开的人”来处理。比如约定好每个进程退出前递减一个引用计数减到0就shm_unlink。但更多时候因为业务下线时进程都没了我会加一个启动时清理流程。这个流程很别扭所以后来我干脆只在真正的“常驻内存”场景用共享内存短期内频繁启动/退出的任务直接退回到文件锁方案。核心结论是共享内存互斥锁适合“长生命周期、高并发读写的服务型进程”不适合短命脚本。5. 场景选型对照什么情况该用哪种方案问得最多的问题就是“到底该用哪种”。我直接给一个选型对照表这是我多年经验总结出来的场景特征推荐方案理由单机部署定时任务防重入文件锁flock/fcntl实现简单进程崩溃锁自动释放几乎不依赖额外机制多个无亲缘进程保护一个文件/资源fcntl区域锁或文件锁和文件生命周期绑定语义自然需要保护共享内存/数据结构的短临界区POSIX命名信号量API简洁开销比文件锁低长生命周期服务高频读写共享内存共享内存process-shared pthread_mutex性能最好同步和数据结构都在内存里需要跨进程计数/资源池如限制并发数为5POSIX命名信号量初始值N信号量天然适合资源计数互斥只是初始值为1的特例多进程分布式部署跨机器分布式锁数据库/协调服务单机锁跨不了机器不在此文讨论范围但选型时要警惕再强调一次文件锁慢信号量中等共享内存互斥锁快但复杂度也是递增的。选择标准永远是用最简单的方案搞定需求。能文件锁解决的绝对不上信号量能信号量解决的别动共享内存。很多人一上来就“高端方案”共享内存结果初始化、生命周期管理、崩溃恢复全是一坨糊的浪费了大量时间。6. 常见问题与排查技巧实录6.1 进程崩溃后锁没释放吗这个得分场景文件锁进程关闭fd或进程退出时内核自动释放锁。flock和open file description绑定close(fd)就释放进程退出也一样。POSIX命名信号量sem_wait之后进程崩溃信号量的值不会恢复。这是个大坑。比如信号量初值1进程A拿到后变成0然后A崩了信号量永远卡在0其他进程sem_wait永久阻塞。跟文件锁不一样信号量没有“自动解锁”机制。解决办法一是尽量避免“持有信号量时崩溃”的长时间临界区二是用sem_timedwait加超时超时后自己处理“疑似僵尸锁”的状态三是更高级点锁里带上持有者PID定期检查PID是否存在这算轻量级“锁租约”的实现思路。6.2 锁文件被外部删除了怎么办这个坑很经典。假设进程A持有锁文件运维误删了/tmp/myapp.lock。此时进程B重新open(O_CREAT)创建了新文件可以顺利加锁。A和B各自以为自己拿到锁了互斥失效。原因在于删除文件会破坏锁的“身份”。A持有的锁和B加的锁指向的是不同的inode锁自然不互斥。解决思路是别删锁文件。锁文件容器本身是安全门写入业务数据才是风险。可一旦误删互斥性就没了。真没法避免误删时可以考虑“把锁文件放在进程中定期touch的地方”或者用flock 记录PID配合告警及时发现。更稳的方案是不用文件锁改用信号量它没有“文件被删”这个概念。6.3 死锁和锁顺序问题文件锁之间也有死锁风险。比如两个进程进程A先锁文件1再锁文件2进程B先锁文件2再锁文件1两边都拿着自己的锁等对方的锁就死锁了。这个和线程死锁一模一样解法也一模一样——全局锁顺序所有进程都按同样的顺序加锁先锁文件1再锁文件2就不会交叉等待。另外一个典型的场景是“递归加锁”。同一进程对同一文件用F_SETLK重复加锁比如两段代码路径都调用了同一个加锁函数POSIX文件锁的语义是“同一进程对同一文件的锁是合并的”不会导致死锁但可能导致提前解锁——明明外层还应该持锁内层的一个unlock直接把整个锁解了。这个行为很反直觉。我有个做法文件锁要封装成“一次加锁统一解锁”不要在函数里随用随解否则排查起来非常痛苦。6.4 用strace查锁状态排查锁问题strace是神器。可以直接看系统调用层面锁加在哪里、有没有返回错误strace -f -e traceflock,fcntl,lockf ./myapp输出里能看到fcntl(5, F_SETLK, {l_typeF_WRLCK, ...}) 0或者失败返回EACCES。配合cat /proc/pid/fdinfo/5还能看到当前进程对某个fd持有的锁范围格式如下pos: 0 flags: 05 mnt_id: 32 lock: 1: WRITE 234881024 0 0 12345这个信息在排查“谁占着锁”时非常有用。先lsof /tmp/myapp.lock找到占用进程的PID再看/proc/pid/fdinfo/几秒钟就能定位。6.5 NFS上的锁是纸糊的在NFS文件系统上文件锁行为非常不可靠。某些NFS实现下fcntl锁是“建议锁”里的“假锁”互相之间根本不冲突或者因为网络分区导致锁状态无法同步。如果锁文件放在NFS共享目录上多个机器上的进程都来抢锁看起来能抢到实际全靠运气。解决办法很简单锁文件必须放在本地磁盘不要放NFS。分布式场景请直接上分布式锁别拿单机锁硬凑。7. 实操心得我在生产环境怎么选怎么写最后说几个我自己写代码时的固定习惯。第一个习惯是“加了锁的代码一定要伺候好多路关闭路径”。一个进程拿锁后可能有十几种退出路径正常业务结束、出错return、被信号打断、超时等等。每条路径都要保证“释放锁/关闭fd”否则下次启动大概率被自己上次的“僵尸锁”卡住。我通常把“获锁后的临界区”隔离成一个独立函数用deferGo或 RAIIC思想自动释放纯C语言里就手动把解锁放到唯一的出口宏里绝不提前return。第二个习惯是“永远用带超时的等待不要死等”。文件锁用非阻塞F_SETLK信号量用sem_timedwait共享内存锁用pthread_mutex_timedlock。宁可稍微重试一下也不要把进程挂死在锁上。第三个习惯是“给锁加审计信息”。生产环境里没有审计信息出问题连谁拿着锁都不知道。我会在锁文件旁边额外写一个 pid启动时间 的txt文件每次拿锁的时候更新。排查时直接cat /tmp/myapp.lock.pid就能知道是哪个进程在占有锁。花一分钟写这个省下排查时间的价值是不可估量的。第四个习惯是“能不开共享内存就不开”。共享内存虽然快但生命周期管理太考验工程能力。多数业务场景的并发量不足以让文件锁或信号量成为瓶颈性能不够再加共享内存也不迟。进程间互斥的本质就是在一堆并发里找到一条“单行线”。条条大路通罗马但每条路各有脾气——文件锁稳重但慢信号量均衡但要注意崩溃释放共享内存最快但最复杂。搞清楚自己的核心诉求按部就班落地别贪多、别追新很多问题根本不值得你踩一遍。