c++如何实现文件锁定防止并发修改_flock与LockFile【深度】

文件锁的真相：flock与LockFile，远不止“加锁”那么简单

先明确一个核心概念：文件锁，无论是Linux的flock还是Windows的LockFile，它们提供的保护边界远比想象中要窄。简单来说，它们能告诉你“现在谁拿着这把钥匙”，但完全不管“拿钥匙的人在房间里具体干了什么”。理解这个本质区别，是避免踩坑的第一步。

Linux 下用 flock 锁文件，但进程退出就自动释放

很多开发者把flock当作一把万能锁，其实它可能是最“轻量”也最“脆弱”的一种。它是一种典型的“劝告锁”（advisory lock），其生命周期与文件描述符（fd）深度绑定。这意味着什么？锁的存亡完全取决于那个fd。一旦fd被关闭——无论是你主动调用close()，还是进程崩溃退出——锁就会立刻烟消云散。它不绑定在文件路径上，也不会在fork后自动继承给子进程。

这里有个高频误区：打开文件获得fd后，调用一次flock就以为高枕无忧了，长期持有这个fd却不再关心锁的状态。殊不知，只要这个fd通过任何途径被关闭，你的锁就失效了。

那么，具体该怎么用才稳妥？

• 锁的时机是关键：必须在每次需要进行互斥写入操作前，重新调用flock(fd, LOCK_EX)。别指望一次上锁就能长期生效。
• 守护进程的锁怎么保：如果需要实现进程级的持久锁，通常需要结合fork、setsid以及一个独立进程来专门持有fd和锁，并且必须妥善处理SIGTERM等信号，在退出前主动解锁。
• 注意NFS这个“天坑”：flock在NFS文件系统上的行为是不可靠的，在某些挂载选项下甚至会静默失败。稳妥的做法是，增加对errno == ENOTSUP的错误判断，并准备好降级方案。
• 如何验证锁的效果：测试时，最直观的方法是在两个终端分别运行：./a.out && sleep 1 && ./a.out。观察第二个进程是阻塞等待，还是直接报错，这能清晰验证锁的互斥行为。

Windows 下 LockFile 需手动指定字节范围，且不支持共享锁语义

切换到Windows世界，情况又不一样了。LockFile和UnlockFile提供的是字节范围（byte-range）级别的强制锁。麻烦之处在于，Windows没有提供类似flock那种“一键锁定整个文件”的便捷模式。你必须事无巨细地告诉系统：从哪个偏移量开始，锁多长。

比如你想锁住整个文件，必须先调用GetFileSize获取文件大小，然后把起始偏移0和这个size传给LockFile。而且要注意，如果文件之后被追加写入了，新增长的部分是不受这个锁保护的。

Windows下的实操，细节决定成败：

• 别想当然地锁“整个文件”：传入0和MAXDWORD来试图锁定整个文件？这招行不通。Windows会将其截断为当前文件的实际大小，对于超大文件，甚至可能直接返回ERROR_NOT_ENOUGH_MEMORY。
• 如何实现“读写锁”语义：Windows原生没有共享锁（读锁）的概念。如果你需要“多个读不互斥，但写互斥”的效果，得自己动手实现。一个常见的方案是：约定用LockFile去锁定文件开头的一个固定字节（例如offset=0, length=1），将这个字节区域视为“写权限标志位”。
• 优先考虑LockFileEx：相比基础的LockFile，LockFileEx功能更强大，支持重叠I/O和超时设置，实用性更高。当然，代价是需要初始化OVERLAPPED结构体，如果是异步操作，还得配合GetOverlappedResult来获取结果。
• 分清错误码的含义：ERROR_IO_PENDING不代表失败，它仅仅表示异步锁操作正在等待中。真正的锁定冲突错误码是ERROR_LOCK_VIOLATION。

跨平台代码别硬套 flock / LockFile，得封装抽象层

想要写出健壮的跨平台文件锁代码，直接用#ifdef WIN32写两套分散的逻辑，绝对是埋雷之举。两个平台的语义差异太大了：在Linux上，flock默认是可重入的，同一进程对同一个fd多次请求LOCK_EX不会阻塞自己；而在Windows上，对同一个文件句柄重复调用LockFile会直接失败。更根本的是，flock有清晰的LOCK_SH（共享锁）语义，这在LockFile的世界里根本不存在。

所以，正确的姿势是抽象和封装：

• 定义统一的接口：设计一个如bool file_lock(int fd, bool exclusive, int timeout_ms = -1)这样的函数，内部根据平台派发到不同的实现。
• 处理平台差异：在Windows实现里，当exclusive=false（请求共享锁）时，可以将其退化为“尝试检查是否存在写锁”：用LockFileEx尝试锁定一个标志字节，如果失败就认为当前有写者。
• 弥补功能缺口：Linux的flock没有原生超时参数。如果需要超时功能，当timeout_ms > 0时，通常需要借助pthread_cond_timedwait配合一个单独的线程进行非阻塞轮询来实现。
• 利用RAII防泄漏：这是C++的最佳实践。务必使用RAII（资源获取即初始化）技术，在锁对象的析构函数中自动调用解锁操作，确保即使发生异常，锁也能被正确释放，避免死锁。

真正危险的是“锁了文件却没锁住业务逻辑”

这才是最隐蔽、也最危险的陷阱。文件锁只是一个底层的同步原语，它不是事务。想象这个典型场景：进程A成功调用flock加锁，然后读取config.json到内存，修改某个值，再写回磁盘，最后解锁。问题在于，进程B完全可能在A“读取”之后、“写回”之前，也完成了自己的一套“读取-修改”流程。当A写回并解锁后，B紧接着将其修改写回，最终导致A的更改被完全覆盖。

看到了吗？锁只保证了“写文件”这个动作本身不会并发执行，但它完全无法保证“读取-修改-写回”这一连串业务逻辑的原子性。

如何规避这个经典问题？

• 优先采用原子写：对于JSON、YAML这类结构化配置文件，首选的方案是“原子替换”。即：将内容写入一个临时文件 → 调用fsync确保落盘 → 使用rename系统调用将临时文件原子性地覆盖原文件。文件锁可以用在重命名操作之前，锁住那个临时文件。
• 确保锁覆盖完整周期：如果必须原地修改文件，那么锁的持有范围必须覆盖从“读取”开始到“写入并刷盘”结束的完整周期。并且在写入后立即调用fsync，否则数据可能还在内核缓存里，锁一释放，其他进程读到的就是过时的“脏数据”。
• 善用系统原子性保证：对于日志追加这类场景，可以组合使用O_APPEND标志和write()调用。POSIX标准保证了对以O_APPEND模式打开的文件进行write操作是原子的，无需额外加锁。

说到底，文件锁的职责边界非常清晰：它只管理“哪个进程正在操作这个文件描述符”，至于“进程用这个描述符做了什么、数据是否一致”，它一概不管。业务逻辑层面的竞态条件，最终要靠良好的架构和设计来解决，而不能指望flock或LockFile替你包办一切。理解并接受这一点，是正确使用文件锁的前提。