Linux多进程并发读写文件需用文件锁协调，推荐fcntl()记录锁（粒度细、支持读写区分）或flock()全文件锁（简单可靠），须统一方案、全程保护读-改-写、注意继承性与O_APPEND的局限性。
Linux中多进程并发读写同一文件，不加锁极易导致数据错乱或覆盖。文件锁不是万能的，但它是协调进程行为最直接的手段——关键在于选对锁类型、用对系统调用，并理解其作用范围和局限性。
fcntl() 文件锁：建议优先使用的记录锁
fcntl() 提供的是“记录锁”（advisory lock），它不阻塞文件I/O本身，只在所有进程都主动检查锁时才生效。它的优势是粒度细（可锁文件任意字节区间）、支持读写区分、且与文件描述符绑定（fork后子进程继承锁，但execve后通常丢失）。
- 使用 F_SETLK 尝试加锁，失败立即返回错误（非阻塞）；F_SETLKW 会阻塞直到获得锁
- 锁是基于进程+fd的：两个不同进程打开同一文件得到不同fd，各自加的锁互不影响；同一进程重复open两次，得到两个独立fd，需分别解锁
- 进程退出或关闭对应fd时，内核自动释放该fd上的所有锁——这是可靠性的基础，但也是陷阱：若程序异常崩溃未显式解锁，锁仍会被释放，不会死锁
flock() 简单文件锁：适合单机协作场景
flock() 是更轻量的“整个文件锁”，操作简单（LOCK_EX 排他、LOCK_SH 共享），语义清晰，且与fork行为友好（子进程默认继承锁，可通过 LOCK_UN 或 FD_CLOEXEC 控制）。
- 它基于文件inode而非字节偏移，无法做部分锁定；也不兼容NFS（某些旧版本可能失效）
- 加锁对象是“打开的文件表项”，同一进程多次flock同一fd，后一次会覆盖前一次；不同fd指向同一文件，flock互斥有效
- 推荐用于日志追加、配置文件更新等不需要精细控制的场景，代码简洁不易出错
真实并发场景中的典型误用与规避
很多问题并非锁本身失效，而是逻辑设计偏差：
- 混合使用 flock 和 fcntl：二者互不感知，一个进程用flock加了锁，另一个用fcntl仍可成功加锁——必须全项目统一方案
- 只锁写不锁读：若多个进程同时读取并基于旧值计算新值再写入（如计数器+1），即使写入时加锁，读取阶段已发生竞争——应全程锁住“读-改-写”原子块
- 忽略锁的继承性：fork后子进程持有父进程的锁，若子进程不主动处理（如解锁或设置FD_CLOEXEC），可能干扰父进程后续操作
- 用O_APPEND绕过锁：以O_APPEND打开文件写入时，内核保证写入位置是文件末尾，但写入内容本身仍需锁保护（例如先读长度再写入结构化数据）
一个安全的日志追加示例（C语言片段）
以下是在多进程环境下安全追加日志的关键逻辑：
int fd = open("/var/log/app.log", O_WRONLY | O_APPEND | O_CREAT, 0644);
if (fd == -1) { /* 错误处理 */ }
<p>// 使用flock确保追加原子性
if (flock(fd, LOCK_EX) == -1) { /<em> 失败处理 </em>/ }</p><p>// 此时可安全写入，O_APPEND保证位置正确，flock保证无其他进程同时写
dprintf(fd, "[%ld] %s\n", time(NULL), msg);</p><p>// 内核会自动在close时释放锁，也可显式flock(fd, LOCK_UN)
close(fd);</p>注意：这里没用write()而用dprintf()，是因为格式化与写入需视为一个逻辑单元；若分步做（先格式化到buffer，再write），则需确保整个过程被锁包裹。
