有段时间我负责维护一批数据同步脚本每隔五分钟跑一次拉取上游文件、解析、写入本地库。某天早上运营反馈当天凌晨的数据少了整整一个批次。查日志发现脚本确实执行了但只跑完一半就退出了——没报错没异常比平时缩短了一分多钟。后来加了一行日志才发现同一时刻有两个脚本实例在同时跑一个把临时文件截断了另一个写到一半正好撞上直接把新数据当成乱码跳过这才丢了数据。这种问题在单机环境里的经典解法就是文件锁。而谈到文件锁绕不开flock这个看似简单、实际坑极多的系统调用。很多人在网上搜到一段加锁代码贴进项目里就完事直到线上出事故才回头补课。我属于后者。这篇文章不打算从 man page 逐字翻译而是把我对flock的完整理解、实际用法、以及踩过的几个典型坑一次性讲清楚。1. 先别急着加锁弄清文件操作到底哪里会出问题很多人上来就问怎么给文件加锁但我建议先想清楚一个问题你锁的是什么是文件内容本身还是对文件的整个操作流程这两种情况需要的锁策略完全不同。1.1 一次 write 并不保证落盘也不保证排它初学文件 I/O 的时候大家听过的最大误区就是一次 write 是原子的。这句话只说对了一半write系统调用在进程内部的执行确实不会被打断但它只保证这段数据一次性交给内核不保证数据写到磁盘也不保证两次write之间的相对顺序。举个例子两个进程同时往同一个文件追加日志各自执行一次open(fd, O_WRONLY | O_APPEND)然后分别write(AAAA)和write(BBBB)。虽然O_APPEND能保证每次write的偏移量定位到文件末尾看起来不会互相覆盖但这两段数据进入内核之后最终落到哪个磁盘块、落盘顺序如何完全不可控。如果数据量大一次write也会被拆成多个块写入两个进程的块还会交错排列最后日志文件的中间行变成AABBAA这种鬼样子排错的时候煞费苦心。更隐蔽的是读-改-写这个组合动作。比如共享配置文件的更新流程读出文件、修改几个字段、把整个文件写回去。这个流程在逻辑上是一个整体但每一步都是独立的系统调用。进程 A 读出旧配置进程 B 也读出旧配置A 先写回新配置B 跟着把基于旧配置改出来的内容写回去——A 的修改就这么被静默覆盖了而且程序不会报任何错。1.2 锁要解决的三个典型问题内容破坏、重复执行、逻辑竞态从我的实际排查经验看文件锁真正要解决的并发问题大致分三类对症下药才有效。第一类是内容破坏。多进程写同一文件日志串行、配置错乱、共享数据文件变脏都属于这一类。这种场景最直接锁住写在文件的这段操作即可。第二类是重复执行。典型例子就是 crontab 定时任务。任务第一次跑还没结束第二次又被调度器拉起来了。两个实例同时处理同一批消息队列大概率不只是一份数据被重复消费还可能互相删掉对方正在处理的临时状态。这类问题锁的不一定是文件内容而是整个脚本的运行权。第三类是逻辑竞态。多个进程需要协作修改一个共享状态比如读取计数器、加一、写回。就算每次读写文件本身没问题两个进程交错执行这个流程最终结果也会丢更新。这类场景锁的粒度要覆盖完整的读-改-写周期而不是单次读写。搞明白这三类问题的区别后你才能判断自己到底需不需要文件锁、需要哪种锁、加在哪里。有很多人一遇到并发问题就想上消息队列、上 Redis 分布式锁其实同一台机器上的进程互斥一个几百字节的锁文件就能解决成本和心智负担都小得多。2. flock 的锁类型和底层语义为什么它和别的文件锁不一样flock是 Linux/BSD 提供的文件锁系统调用声明在sys/file.h中原型非常简洁#include sys/file.h int flock(int fd, int operation);operation支持四个宏可以两两组合。我先把它的基础矩阵列出来后面再展开讲底层语义。操作宏含义搭配建议LOCK_SH共享锁也叫读锁多个进程可以同时持有只读场景LOCK_EX排他锁也叫写锁同一时间只允许一个进程持有写操作、读-改-写场景LOCK_UN解锁一般不需要显式调用关闭 fd 自动释放LOCK_NB非阻塞标志拿不到锁立即报错返回与LOCK_SH或LOCK_EX用按位或组合2.1 三种锁模式的应用直觉共享锁和排他锁的语义和数据库里的读写锁完全一样。持有共享锁时其他进程也可以拿共享锁但拿排他锁会被挡在外面持有排他锁时什么锁都不让你拿。实际开发里我用共享锁的场景其实不多因为大多数需要文件锁的操作都涉及写。但有一种情况很典型多个进程需要检查某个配置文件是否变更又不希望文件在读取过程中被重写这时候各进程拿LOCK_SH就够了大家互不阻塞只是把写进程挡在外面。排他锁则是单生产者/单消费者模型的基础。日志写入、状态文件更新、数据文件整体替换统统用LOCK_EX。LOCK_NB这个标志很多人容易忽略。它的存在意义是让你在拿不到锁就死等和拿不到锁立刻失败之间做选择。我之前做过一个任务分发模块多个 worker 进程抢一个任务索引文件抢不到锁的 worker 不应该挂起等待而是立刻退出把任务留给下一次调度。这种情况非阻塞模式是关键。阻塞模式下多个进程排队拿锁看起来公平但如果持有锁的进程异常卡死后面排队的所有进程都会跟着卡死检查问题都无从下手。2.2 锁与 open file description 绑定这是理解 flock 一切行为的钥匙flock和大部分程序员熟悉的锁有一个本质区别它的锁不是绑定在进程上也不是绑定在文件 inode 上而是绑定在 open file description打开文件描述以下简称为 OFD上。怎么理解 OFD每次open()系统调用成功返回一个 fd内核都会创建一个新的 OFD。也就是说同一个进程里调用两次open()打开同一个文件得到的是两个独立的 fd对应两个独立的 OFD它们持有的flock锁会互相冲突。反过来如果用dup()复制一个 fd或者fork()创建子进程它们共享的是同一个 OFD这几个 fd 视为一个整体锁不会被自己人挡住。这个特性导致了一个很多人第一次接触都会懵的行为同一进程内如果两次 open 同一文件然后分别对两个 fd 加排他锁第二次加锁会阻塞死自己。这不是 bug而是 OFD 锁设计如此。它保证了锁的粒度精确到每次打开文件的上下文而不是笼统地限制整个进程。既然锁绑定在 OFD 上生命周期就很好推导当指向这个 OFD 的所有 fd 都关闭后内核自动释放锁。不需要调用LOCK_UN当然你显式调也没问题。这里有个容易忽略的细节如果我在 fd 上dup出一个副本然后关闭原始 fd只要副本还开着锁就还在非得等所有副本都关闭锁才真正释放。很多人只关闭了其中一个 fd以为锁已经释放了实际上另一个进程还傻傻等着。2.3 非阻塞模式与 EWOULDBLOCK当LOCK_NB生效且锁已被其他 OFD 持有时flock返回 -1errno 设置为EWOULDBLOCK。C 代码里的判断范式对应如下int ret flock(fd, LOCK_EX | LOCK_NB); if (ret -1) { if (errno EWOULDBLOCK) { // 拿不到锁做别的事或者退出 } else { perror(flock); // 其他错误fd 无效、文件系统不支持等 } }很多人在网上抄代码时只判断返回 -1 就是没拿到锁不区分 errno。我建议还是区分一下因为有些文件系统比如某些网络文件系统可能压根不支持flock这时候 errno 会是ENOLCK或者EOPNOTSUPP之类如果你一律当成锁被占用处理排查问题的方向就全歪了。3. flock 与 fcntl、lockf 的选型对比换了方案就得换踩坑姿势Linux 上能用的锁不止flock一个还有 POSIX 记录锁fcntl以及基于fcntl封装出来的lockf。很多人以为它们只是 API 不同实际底层语义差异很大选错了方案踩坑姿势完全不同。3.1 三套锁的关键差异我曾经在大版本重构时把一批flock调用按第三方库的建议换成了fcntl结果同一个进程里两个线程各打开一个 fd互相把对方锁释放了数据写坏两回。这件事让我把两套锁的差异牢牢记住了。对比维度flockfcntl / lockfPOSIX 记录锁锁粒度整个文件可以锁文件中的一段字节范围记录锁锁关联对象open file description进程传统 POSIX 锁fork()后子进程继承锁共享同一 OFD子进程不继承锁close()行为关闭所有指向同一 OFD 的 fd 才释放进程内关闭任意一个指向该文件的 fd都有可能释放该进程在此文件上的所有锁死锁检测无内核会检测死锁返回EDEADLK递归加锁一个 OFD 上重复加锁会替换旧锁类型记录锁可以叠加不同字节区间的锁看到close 任意 fd 可能释放整个锁这一条你就明白为什么fcntl这么容易出诡异问题。POSIX 语义下锁是挂在进程维度的内核为每个进程维护一份该进程在某文件上的锁信息所以当你在这个进程里随便关掉一个指向该文件的 fd内核认为你对这个文件可能不再感兴趣了于是把这个进程在此文件上的所有记录锁全部释放。这不是实现 bug是标准就这么定的。很多人踩坑之后抱怨莫名其妙锁就没了根源往往是在持锁期间同进程的另一个线程恰好 close 了同一个文件的另一个 fd。3.2 OFD locks兼顾两者优点的现代方案如果你既需要fcntl的字节范围锁能力又想要flock的锁跟随 OFD语义Linux 内核从 3.15 版本开始提供了 OFD locks也就是F_OFD_SETLK、F_OFD_SETLKW、F_OFD_GETLK这几个命令。它们本质上是fcntl的扩展但锁的所有者从进程变成了open file descriptionclose 任意 fd 不会误释放锁fork()后子进程也不会继承。我的建议很简单除非你的代码需要兼容老内核或者跨 BSD/macOS 之类的平台新代码里做记录锁优先考虑 OFD locks单纯想要整个文件互斥就用flock它简单、直观、坑最少。lockf这个接口我基本只在查看老项目时才会遇到新代码不建议再引入它它的定位就是 fcntl 记录锁的简化封装没有额外能力。3.3 哪些场景必须弃用 flock用flock有一个硬限制它只能锁整个文件。如果你有两个进程需要同时访问同一个大文件的不同区域一个写头部一个写尾部用flock会把另一个进程完全挡在外面并发度直接砍半。这种场景就该用fcntl或 OFD locks精确锁住各自的字节范围。此外flock不能跨线程做锁继承管理因为同一个进程内的多个线程共享同一套 fd 表属于同一个 OFD 的锁天然对同进程线程不设防。如果你需要的是线程之间的互斥那应该用线程库或进程内同步原语文件锁本来就不是干这个的。4. 可以直接抄走的六个 flock 落地场景理论上讲再多不如给几段能直接用的实操代码。这六种场景是我在真实项目中沉淀下来的覆盖了从 shell 到 C、从防重到抢占的常见需求。4.1 shell 脚本防重复执行定时任务最常见的坑crontab 任务防重是我见过flock命令用得最多的场景。定时任务周期短、执行时间长非常容易重叠。用 util-linux 提供的flock命令一行就能解决flock -n /var/run/my_cron.lock -c /opt/scripts/sync_data.sh-n表示非阻塞拿不到锁立即退出-c后面跟要执行的命令。这样配置在 crontab 里任务上次还没跑完这次调度到达时会直接失败退出不会叠起来跑。flock命令还支持-w参数指定等待秒数比如-w 10表示等待 10 秒超过就放弃。这个参数在任务可以稍微延迟但绝对不能漏跑的场景下很实用。我用过一个数据回补任务单次执行要 20 分钟周期正好 20 分钟偶尔抖动就会重叠。把-n改成-w 300之后后到的实例会等前面的先跑完重叠率降为零也没有漏跑。4.2 Python 脚本实现单实例守护进程Python 里fcntl.flock是对系统调用的直接封装写法非常经典import fcntl import sys lock_path /var/run/my_daemon.pid lock_file open(lock_path, w) try: fcntl.flock(lock_file, fcntl.LOCK_EX | fcntl.LOCK_NB) except OSError: print(another instance is running, exiting) sys.exit(1) # 可以在这里把 pid 写入锁文件方便排查 lock_file.write(str(os.getpid())) lock_file.flush() # 程序主体 try: run_forever() finally: fcntl.flock(lock_file, fcntl.LOCK_UN)注意fcntl模块只在 Unix 系平台可用Windows 下没有对应实现。如果你的脚本要跑在 Windows 上要么用msvcrt.locking要么用第三方库filelock做跨平台封装。我一般建议工具脚本只跑在 Linux 上的就简单直接用fcntl少引一个依赖少一份麻烦。4.3 C 语言里多进程写同一个数据文件C 语言的用法最贴近内核语义也最容易把原理讲明白。多进程追加日志的完整写法如下int fd open(/var/log/app.log, O_WRONLY | O_CREAT | O_APPEND, 0644); if (fd 0) { perror(open); exit(1); } if (flock(fd, LOCK_EX) -1) { perror(flock); close(fd); exit(1); } // 临界区write、fsync 等 write(fd, log_buf, len); fsync(fd); flock(fd, LOCK_UN); close(fd);这段代码的精髓在于open时用了O_APPEND标志。即使锁保护的代码以外还有别的进程绕过锁直接追加数据O_APPEND也能保证每次write的目标偏移在文件末尾减少内容互相覆盖的概率。锁 O_APPEND是双保险不要去掉任何一个。4.4 用 LOCK_NB 做轻量任务抢占当你有多个 worker 进程需要争抢谁能处理这一批任务时flock可以当作一个非常轻量的抢占锁来用。核心思路是任务索引文件上拿锁拿到锁的进程负责处理拿不到的退出等下一轮。import fcntl import os task_index_path /var/run/task_worker.lock # 尝试抢占锁 lock_fd open(task_index_path, w) try: fcntl.flock(lock_fd, fcntl.LOCK_EX | fcntl.LOCK_NB) except OSError: # 没抢到锁本轮不处理 sys.exit(0) # 抢到锁读取任务队列处理任务 process_task_queue() # 处理完释放锁 fcntl.flock(lock_fd, fcntl.LOCK_UN)这种模式比所有 worker 同时处理任务靠分布式事务保证幂等简单太多代价是同一时刻只有一个进程在工作扩展性有限。我做过的一个索引重建模块就是这么设计的低谷期只有一个 worker 在跑高峰期多挂几个 worker 也只是在那排队抢锁其余全部休眠整体稳定性反而更好。4.5 锁文件内容该写什么pid 与身份标识锁文件本身只有 inode 有意义文件内容完全由你决定。我个人习惯在锁文件里写入持有者的 pid以及加锁时间配合ps命令在排障时可以立刻定位是谁占据了锁flock -n /var/run/app.lock -c echo $$ /var/run/app.pid; /opt/app/bin/start.sh不过flock命令的-c写法里$$是 shell 扩展的 pid不一定是最终执行程序的 pid我一般更推荐在脚本内部写 pid更准确。锁文件本身不需要删除我一直留着好处是下次加锁不需要重新担心文件权限和 inode 变化的问题详见后面的坑。4.6 把 flock 当分布式锁用之前先想清楚这几件事flock本身是单机方案依赖本地文件系统。但有不少人想把它用在多台机器共享的 NFS 目录上当作简易分布式锁。我做过类似尝试结论是理论上可行但坑很多建议谨慎。Linux 内核从 2.6.12 开始在 NFS 上会把flock映射成 POSIX 记录锁来模拟NFSv4 协议更是原生支持锁。问题是 NFS 的服务端实现五花八门有的文件系统语义不完整锁可能不生效或者异常丢失。如果你非要用至少要做到三点确认所有客户端挂载参数一致在目标环境做多客户端并发加锁的实测不要把锁的可靠性寄托在跨公网的网络文件系统上。跨机房的真正分布式场景建议直接用 Redis、etcd 或者 ZooKeeper 这类专门的协调服务成熟可靠调试工具也多。5. 我在生产环境踩过的 flock 坑每一个都是真金白银换来的这一节的内容是我认为这篇文章最有价值的部分。flock的语法很简单但实际用起来十个里有八个问题出在下面这些细节上。5.1 忘记 flush锁内写的数据看不见这个坑我印象最深排查了一下午。场景是这样的主进程持有排他锁向共享文件写入一批配置数据然后解锁。另一个进程拿到锁后读取这个文件结果读到的还是旧数据。代码层面没有任何问题锁也正常但为什么读不到新数据答案在缓冲区。Python 的open(path, w)默认带用户态缓冲区write()只是把数据写进了缓冲区还没真正交给内核更没落到磁盘。主进程在解锁之前没有调用flush()或者fsync()所以另一个进程拿锁后打开同一个文件看到的还是磁盘上的旧内容。我在踩坑后总结了一条铁律临界区结束前必须保证数据已经离开用户态缓冲区。在 Python 里调用flush()在 C 里调用fsync(fd)。尤其要注意fsync不只是刷文件数据还会刷文件元数据比如大小、修改时间代价比较高但换来的是一致性值。分布式环境里讲究先落盘再发确认本地多进程协作也是一样的道理。5.2 锁文件被删除互斥锁形同虚设有一段时间我的定时任务偶尔会出现并发跑起来的告警毫无规律。后来抓到一个现场发现锁文件不见了。排查才知道脚本里有人写了一行清理临时文件的逻辑把包含锁文件的目录整个清空了。这个坑的根源在于flock锁绑定的是 inode而不是文件路径。进程 A 打开锁文件拿到了锁此时锁文件的 inode 是 N另一个进程把锁文件删除进程 B 再创建一个同名文件得到的是全新的 inode M。进程 B 对 inode M 加锁和进程 A 持有的 inode N 的锁毫无关系互斥直接失效。从那以后我定了两条规矩第一锁文件一旦创建就不再删除哪怕内容没用了也要留着占位第二清理临时文件的脚本绝对不允许按通配符rm -rf /var/run/*.lock之类的方式乱删。锁文件长期存在不会有任何问题它只是一个逻辑标志不是业务数据。5.3 fork 与 exec 之后锁到底还在不在fork()之后子进程会继承父进程的 fd 表所有 fd 指向同一个 OFD。如果你在父进程里持有 flock 排他锁然后 fork子进程里这个 fd 也共享同一个锁。重点来了只要子进程还持有这个 fd锁就不会释放。父进程就算调用了LOCK_UN或者关闭了自己的 fd只要子进程那边还开着对应的 fd锁就一直存在。这个行为导致过一个诡异问题主程序在启动时获取了单实例锁然后 fork 出工作子进程子进程异常退出但 fd 没有关闭主程序结束前尝试解除锁结果第二个实例怎么也启动不了因为锁一直被那个僵死的子进程占着。处理办法是在 fork 出来的子进程里尽快关闭不再需要的 fd尤其是持有锁的那个 fd。如果子进程确实需要共享这个锁就要明确锁的生命周期由谁负责否则就等着清理进程残留吧。exec的情况又不一样了。exec 执行新程序会替换进程映像默认情况下 fd 是保持打开的除非设置了FD_CLOEXEC所以新程序如果持有了这个 fd锁还是有效的。很多语言的高级文件 API 默认给 fd 设置了CLOEXEC比如 Python 的os.open()默认O_CLOEXEC这时候你 exec 出去锁就莫名其妙被释放了。排查思路非常难受我建议所有涉及锁的 fd明确标注它的 cloexec 状态不要赌默认值。5.4 NFS 与容器环境行为漂移与权限分层flock的行为在不同文件系统上并不一致。除了前面说的 NFS 模拟行为Docker 容器也藏了一个坑。容器里的文件系统可能是 overlayfs不同层的文件操作最终会落到宿主的底层文件系统但有些 overlay 实现并不保证锁语义和原生文件系统一致。更常见的问题是两个容器如果挂载同一个宿主机目录容器内进程的 UID 映射可能不同一方创建的锁文件另一方没有权限打开直接 open 失败锁完全用不了。跨环境行为漂移的应对方案很统一在目标环境的真实文件系统上做一次并发加锁验证。写一个简单的测试程序两个进程同时加锁确认其中一个等待、一个成功然后再放开业务代码上线。这种测试花不了十分钟却能避免大量只在特定环境出现的玄学问题。6. 给一套我自己的 flock 落地建议如果你现在正要在项目里引入文件锁以下是我在多次踩坑、重构之后形成的个人习惯直接拿走可用。第一锁文件统一放到一个专用目录比如/var/run/app/目录权限固定锁文件的权限设置成只允许启动进程的用户读写。不要把锁文件放到业务数据目录里避免被业务逻辑误清理。第二明确使用场景。只是防重复执行或者单实例守护用LOCK_EX | LOCK_NB拿不到锁就快速退出这是最简单可靠的模式。需要多读单写的场景用LOCK_SH配合LOCK_EX但一定要保证所有参与方都遵守同一套加锁协议。任何一方绕过锁直接操作文件整个方案就崩了因为flock是劝告锁不是强制锁。第三拿锁之后偶尔加一个自检意识程序启动时打印一条日志包含锁文件路径、加锁结果、当前 pid。这个习惯陪我排查过太多环境差异问题一行日志能省下一整天的定位时间。第四在锁的粒度上宁可大不要小。文件锁的粒度比数据库行锁粗得多但它的代价也小得多。如果你发现锁竞争激烈、性能不行第一反应不应该是拆成更细的锁而是确认你是否真的需要多进程同时处理同一个文件。很多时候用单进程 线程并发或者把大文件拆成多个文件分片处理都比精细化的文件锁好维护得多。flock的本质是在极其简单的 API 后面藏了一套文件描述符生命周期的复杂语义。真正把它用好不在于记住多少个宏而在于理解锁和 OFD 绑定之后随之而来的继承、释放、跨文件系统行为。这些经验是用几次告警和数据损失换来的希望你读完能绕开这些坑一次就把并发控制做对。