flock不能替代fcntl做跨进程文件锁，因为flock是建议性锁且依赖文件描述符继承，在fork后行为不稳定，子进程关闭fd或exec时锁可能意外释放；而fcntl的f_setlk是内核级强制锁，只要进程存活且fd未关闭，锁即持续有效，更适合严格同步场景。

python如何利用fcntl实现跨进程的文件加锁机制？

为什么`flock`不能替代`fcntl`做跨进程文件锁？

因为flock是建议性锁且依赖文件描述符继承，在多进程fork后行为不稳定，尤其在子进程关闭fd或exec新程序时锁可能意外释放；而fcntl的F_SETLK是内核级强制锁，只要持有锁的进程存活、fd未关闭，锁就持续有效，更适合严格同步场景。

常见错误现象：OSError: [Errno 11] Resource temporarily unavailable——说明另一个进程已持写锁；IOError: [Errno 9] Bad file descriptor——fd在子进程中被提前关闭，导致锁失效。

必须用os.open()打开文件（而非open()），才能获得可被fcntl.fcntl()操作的原始fd
锁作用于整个文件，不支持字节范围锁以外的粒度（如某段偏移）
Python 3.8+ 中fcntl在Windows不可用，仅限Unix/Linux/macOS

如何用`fcntl.flock`和`fcntl.fcntl`区分使用？

fcntl.flock是flock(2)系统调用的封装，和fcntl模块里真正的fcntl.fcntl(fd, fcntl.F_SETLK, ...)不是一回事——前者仍是建议锁，后者才是POSIX强制锁。很多人误以为调用fcntl.flock就等于用了fcntl机制，其实它底层走的是flock系统调用。

正确做法：只用fcntl.fcntl()配合fcntl.F_SETLK/fcntl.F_SETLKW，传入struct.pack('hhll', ...)构造的锁结构体。

F_SETLK：非阻塞，冲突时立即报错
F_SETLKW：阻塞等待，直到锁可用或被信号中断
锁结构体字段顺序固定：type（fcntl.F_WRLCK或fcntl.F_RDLCK）、whence（通常0）、start（0）、length（0表示全文件）、pid（内核自动填，传0即可）

实际加锁代码中容易漏掉的关键步骤

最常被忽略的是：锁必须绑定在**未关闭的文件描述符**上，且该fd不能被子进程继承后意外关闭——否则锁立刻释放。这意味着不能依赖with open(...) as f:上下文管理器，也不能在fork()后让子进程执行os.close()或sys.stdout.close()等全局fd操作。

Python Packaging

深度Python打包工作流——pyproject元数据、依赖与可选额外项、构建后端、wheel、版本控制、发布及CI发布规范……

下载

import fcntl
import os
import struct
<p>fd = os.open('/tmp/shared.lock', os.O_RDWR | os.O_CREAT)</p><h1>构造锁结构：type, whence, start, length, pid</h1><p>lock_data = struct.pack('hhll', fcntl.F_WRLCK, 0, 0, 0, 0)
try:
fcntl.fcntl(fd, fcntl.F_SETLK, lock_data)</p><h1>✅ 此时已持锁，可安全操作共享资源</h1><pre class="brush:python;toolbar:false;">with open('/tmp/data.txt', 'a') as f:
    f.write('written by pid {}\n'.format(os.getpid()))

except OSError as e: if e.errno == 11: # EAGAIN print("Lock held by another process") raise

注意：不要在这里 os.close(fd)，否则锁立即释放

锁文件本身可以是空文件，甚至不存在——os.open(..., O_CREAT)会创建它
进程退出时，内核自动释放所有fd上的锁，无需显式解锁（但主动fcntl.F_UNLCK更清晰）
若需重入锁（同一进程多次加锁），需确保复用同一个fd，不能重复os.open

为什么锁住文件后其他进程仍能`write()`成功？

因为fcntl锁是**强制锁但非I/O拦截锁**：它只在进程调用read()/write()前由内核检查，如果对方绕过Python层直接用C库write(2)、或用shell重定向echo "x" > file，内核仍会拒绝——但前提是对方也用了fcntl或flock尝试加锁。如果完全不加锁就写，内核不会阻止。

换句话说：fcntl锁只对“也遵守锁协议”的进程生效，它不是文件系统级别的写保护。