Linux 进程崩溃后，它的 flock / fcntl 文件锁会自动释放吗？

结论先行：会，Linux 内核会强制帮你收尾。

无论是被 kill -9 强杀、段错误（Segmentation fault）崩溃，还是正常 exit 退出，该进程持有的 flock 和 fcntl 文件锁都会被内核自动释放。

但这里面隐藏着一些极其隐蔽的“连环坑”（特别是多线程和 fork 场景）。如果对内核释放锁的底层机制不了解，在写高并发或高可用服务时，很容易遇到莫名其妙的锁失效或死锁问题。

一、 内核是如何保证“自动释放”的？

要理解为什么会自动释放，需要深入到 Linux 内核对进程销毁的处理流程。

当一个进程由于任何原因退出时，内核都会调用 do_exit() 函数来回收该进程的资源。在这个收尾过程中，有两步关键的操作：

1. 对于 flock（关联到“文件打开表项”）

flock 锁是关联到 Open File Description（打开文件表项） 的，而不是直接关联到文件描述符（FD）或进程本身。

• 当进程退出时，内核会调用 exit_files(tsk)，自动关闭该进程打开的所有文件描述符（FD）。
• 每一个 FD 被关闭时，对应打开文件表项（File Description）的引用计数就会减 1。
• 当该文件表项的引用计数降为 0 时，内核会自动释放该文件表项上绑定的 flock 锁。

2. 对于 fcntl（关联到“进程 + Inode”）

fcntl 记录锁（Record Lock）是直接关联到 进程（Process） 和 Inode 的。

• 内核在进程退出时，会遍历该进程持有的所有 POSIX 锁。
• 在 exit_files(tsk) 执行期间，内核会调用 locks_remove_posix()，强制清理掉所有属于该进程的 fcntl 锁。

因此，从操作系统的维度来看，不存在“因为进程崩溃而导致文件锁永久残留”的情况。

二、 避坑指南：看似释放了，实则有诡异行为

虽然内核有兜底机制，但在复杂的工程实践中，以下几个场景经常让开发者怀疑人生：

陷阱 1：flock 与 fork() 导致的“锁不释放”

因为 flock 锁关联的是“打开文件表项”，而 fork() 会让子进程继承父进程的 FD 拷贝。

父进程 open("lock.db") -> 获得 FD 3 (引用计数 = 1)
父进程 flock(3, LOCK_EX) -> 锁定成功
父进程 fork() -> 子进程继承 FD 3 (引用计数变为 2)

这时候，如果父进程意外崩溃退出，内核会关闭父进程的 FD 3，引用计数减 1（变为 1）。
由于子进程仍然持有 FD 3，引用计数不为 0，该文件锁依然生效！
其他独立进程尝试去获取该锁，依然会被阻塞。这看起来就像是“父进程退出了，但锁没释放”。

• 解决方案：在 fork 之后，子进程如果不需要该锁，应立刻显式 close 掉继承过来的 FD；或者在打开 FD 时设置 O_CLOEXEC 标志。

陷阱 2：fcntl 的“一处关闭，满盘皆输”

这是 POSIX fcntl 锁设计上最著名的槽点（甚至被称为 Bug 级设计）。

只要进程关闭了指向某个文件的“任意一个”文件描述符，该进程在这个文件上加的所有 fcntl 锁都会被立刻释放！

int fd1 = open("data.bin", O_RDWR);
fcntl(fd1, F_SETLK, ...); // 加锁成功

int fd2 = open("data.bin", O_RDONLY); // 打开了同一个文件
close(fd2); // 关掉了 fd2！
// 此时，通过 fd1 加的锁已经被内核悄悄释放了！

在多线程环境下，如果 A 线程在用 fcntl 锁读写文件，B 线程（同进程）莫名其妙去 open 并 close 了一下这个文件，锁就失效了。如果此时 A 线程所在的进程突然崩溃，你可能在日志里发现崩溃前锁就已经失效了，从而误判是崩溃导致的问题。

陷阱 3：网络文件系统（NFS）的延迟与残留

如果你的文件锁是挂载在 NFS（网络文件系统）上的：

• 当客户端进程崩溃，而客户端主机依然在线时，锁通常能较快释放。
• 但如果整台客户端主机突然断电/死机，NFS 服务端可能无法立刻感知，锁会一直残留在服务端，直到服务端的“租约时间（Lease Time）”过期，或者触发了 Keepalive 检测。这段时间内，其他机器是无法获取该锁的。

三、 现代 Linux 的终极解决方案：OFD 锁

为了解决 flock 无法支持分段锁（Record Lock），而 fcntl 又有“一处关闭，锁即释放”的弱智设计，Linux 自 3.15 内核开始，引入了 OFD 锁（Open File Description Locks）。

它兼具两者的优点：

1. 像 flock 一样安全：锁关联到打开文件表项，即使你在线程里关闭了其他的 FD，锁也不会失效。只有当所有指向该文件的 FD 都被关闭（或进程退出）时，锁才释放。
2. 像 fcntl 一样强大：支持针对文件特定区间（Offset / Length）进行加锁。

使用方法非常简单，依然用 fcntl 系统调用，只是把参数换成 F_OFD_SETLK：

struct flock fl = {
    .l_type   = F_WRLCK,
    .l_whence = SEEK_SET,
    .l_start  = 0,
    .l_len    = 0, // 锁定整个文件
};

// 使用 F_OFD_SETLK 代替 F_SETLK
fcntl(fd, F_OFD_SETLK, &fl);

总结