flock 是建议性锁，依赖进程协作且绑定文件描述符而非文件路径或 inode，close(fd)才释放锁，故跨进程、多 fd、exec 后易“失效”。
flock 不是系统级强制锁，它依赖进程协作，且只对同一文件描述符有效 —— 这意味着用 flock 锁住一个文件后，另一个进程用 open() 重新打开该文件再加锁，完全不受影响。
为什么 flock 在不同进程间有时“失效”？
根本原因是 flock 实现的是“建议性锁（advisory lock）”，内核不拦截未加锁的读写操作。更关键的是：锁与文件描述符（fd）绑定，而非文件路径或 inode。
- 同一进程内多次
open("/tmp/a", O_RDWR)会得到不同 fd，flock(fd1, LOCK_EX)对fd2完全无效 - 子进程继承父进程的 fd 时，
flock锁也一并继承；但fork()后各自调用exec重置 fd 表，锁就丢失了 - Shell 中
flock -x /tmp/lockfile -c "cmd"是安全的，因为它确保cmd继承了带锁的 fd；但sh -c 'flock ……'嵌套调用容易因 fd 关闭时机出错
flock 和 fcntl(F_SETLK) 的关键 区别
两者都属建议锁，但生命周期和 作用域 完全不同：
-
flock(fd, LOCK_EX)：锁随 fd 存在，close(fd)自动释放；不支持部分文件区域锁 -
fcntl(fd, F_SETLK, &fl)：锁随进程存在，进程退出自动释放；支持对文件某一段加锁（fl.l_start/fl.l_len） - 二者互不感知 —— 用
flock加锁后，fcntl仍可成功加锁，反之亦然 - 跨 NFS 时
flock可能完全不可靠，而fcntl在较新 NFSv4 上有更好支持
Shell 脚本中正确使用 flock 的惯用写法
避免直接对路径加锁，应始终基于文件描述符，并控制其生命周期：
#!/bin/bash exec 200>/tmp/myapp.lock if ! flock -n 200; then echo "Another instance is running" >&2 exit 1 fi # 此处执行业务逻辑 echo "Working……" sleep 10 # 脚本退出时自动 close(200)，释放锁-
exec 200>/tmp/myapp.lock打开文件并绑定到 fd 200，不写入内容，仅用于锁载体 -
flock -n 200尝试非阻塞加锁；失败则立即退出 - 不用
flock /tmp/myapp.lock -c "……"，因为子 shell 无法保证锁持续到命令结束（尤其命令后台化或被信号中断时） - 若需长期持 有锁（如守护进程），应在主循环中保持 fd 200 打开，不能在每次循环里反复 open/close
Python 中调用 flock 的常见陷阱
Python 的 os.flock() 接口行为与 C 一致，但容易忽略 fd 生命周期管理：
import os import time fd = os.open("/tmp/worker.lock", os.O_CREAT | os.O_RDWR) try: os.flock(fd, os.LOCK_EX | os.LOCK_NB) print("Lock acquired") time.sleep(30) # 模拟工作 finally: os.close(fd) # 必须 close，否则锁不会释放！
- 不能用
with open(……) as f:然后对f.fileno()加锁 ——with块结束会自动close()，导致锁提前释放 -
os.O_TRUNC或os.O_WRONLY打开方式不影响flock效果，但若文件被截断，锁依然有效（锁对象是 fd，不是文件内容） - 在多线程程序中，
flock不能防止线程竞争 —— 它只在进程粒度起作用；线程间需用threading.Lock
真正容易被忽略的是：flock 锁在进程收到 SIGKILL 时一定会释放，但在 SIGTERM 后若未正常清理 fd，锁可能残留到下一次启动 —— 所以生产脚本务必确保所有退出路径（包括异常、信号处理）都显式 close() 锁 fd。
