Go Flock 删除锁文件为什么可能破坏进程间互斥

我在排查一个“偶尔有两个进程同时进入任务”的问题时，第一眼看到的是同一个锁文件路径：/var/lock/job.lock。后来才发现，文件名相同并不等于两个进程拿到的是同一个文件对象。持锁期间把这个路径删掉，再让后续进程按原路径重新打开，可能让互斥关系断开。

结论很简单：Flock 的锁应该通过 Unlock() 或 Close() 释放，不要把“删除锁文件”当成解锁动作。删除路径后，后续打开可能得到一个全新的文件对象，而旧对象上的锁不会自动转移。

官方地址：https://pkg.go.dev/github.com/gofrs/flock

先把路径名、文件对象和锁分开

flock.New(path) 保存的是锁文件路径。真正参与加锁的是随后打开的文件句柄，以及操作系统针对该对象维护的锁状态。路径只是查找入口，不是锁本身。

这也是为什么“文件还在不在”不能直接回答“锁有没有被占用”。文件可能存在但当前没有锁，也可能已经被删除，持锁进程仍然握着打开的对象。Flock 官方文档还特别提醒：锁行为并不保证在所有平台完全相同，不能把某个系统上的细节当成跨平台合同。

package main

import (
    "fmt"
    "github.com/gofrs/flock"
)

func main() {
    // 路径只用于定位锁文件，互斥状态由已打开的文件对象承载。
    lock := flock.New("/var/lock/job.lock")

    locked, err := lock.TryLock()
    if err != nil {
        // 打开文件或申请锁失败时，不能把失败误判成“没人占用”。
        panic(err)
    }
    fmt.Println("acquired:", locked)

    if locked {
        // 临界区结束后由 Unlock 释放内核锁，不删除路径。
        if err := lock.Unlock(); err != nil {
            panic(err)
        }
    }
}

删除后为什么会出现两个锁对象

假设进程 A 已经按 /var/lock/job.lock 打开文件并成功加锁。此时清理脚本执行删除，删除的是目录项，也就是“路径到旧文件对象”的名称映射；进程 A 已打开的对象并不会因为目录项消失就自动变成另一个对象。

随后进程 B 再次使用同一路径打开文件。如果系统允许创建，它可能得到一个新文件对象。进程 B 对新对象申请锁时，检查到的不是进程 A 正在持有锁的旧对象，于是两个进程就可能同时进入本应互斥的临界区。这里的关键不是“删除操作一定立刻造成并发”，而是它破坏了所有进程通过同一对象竞争锁的前提。

这和“进程退出后内核自动释放锁”是两件事。进程正常退出或关闭句柄，锁会按平台规则释放；而主动删除路径只改变名称空间，不能替代对已打开对象执行 Unlock。Flock 的 Close 文档也明确说它等价于解锁并关闭底层文件描述符，但不会删除磁盘文件。

安全做法：让 Unlock 和 Close 管理生命周期

应用层最稳妥的约定是：创建 Flock 实例，拿锁，进入临界区，退出临界区时解锁；是否删除一个长期存在的空锁文件，交给单独的部署或清理策略，并且不能在仍有持锁对象时执行。

func runOnce() error {
    // 固定锁路径，所有进程都应使用同一个共享位置。
    lock := flock.New("/var/lock/job.lock")

    ok, err := lock.TryLock()
    if err != nil {
        return fmt.Errorf("申请文件锁失败: %w", err)
    }
    if !ok {
        // 未拿到锁是正常竞争结果，调用方可稍后重试或跳过。
        return nil
    }

    // defer 绑定释放动作，避免中途 return 时遗留持锁状态。
    defer func() {
        // Close 会释放锁并关闭底层文件描述符；这里不删除锁文件。
        _ = lock.Close()
    }()

    // 这里放只能由一个进程执行的临界区工作。
    return doExclusiveWork()
}

如果业务需要阻塞等待，可以使用 Lock；如果需要超时，可以使用 TryLockContext。无论选择哪种入口，释放动作都应该和取得锁的 Flock 实例绑定，不要让另一个“清理文件”的协程凭路径猜测状态。

清理陈旧文件时要看对象状态而不是只看文件名

有些程序希望在重启后清理遗留的锁文件。此时不要用“文件存在很久”直接推出“锁已经失效”，更不能为了清理而无条件 remove。Flock 提供了 Stat()，可以获得锁文件的 FileInfo，官方说明它适合辅助查看修改时间、识别可能的陈旧锁。

实际策略应至少包含三层：第一，优先让持锁者按正常路径 Unlock 或 Close；第二，只有在明确知道没有活跃持锁者时才处理遗留目录项；第三，清理之后重新创建或打开锁文件时，让所有进程回到同一条稳定的生命周期约定。不要把删除动作塞进每次任务结束的 defer，否则一个进程的收尾会影响另一个仍在工作的进程。

func lockInfo(lock *flock.Flock) error {
    // Stat 用来观察文件信息，不等价于判断当前是否有人持锁。
    info, err := lock.Stat()
    if err != nil {
        return fmt.Errorf("读取锁文件信息失败: %w", err)
    }
    fmt.Println("lock file modified:", info.ModTime())
    return nil
}

记住这三个判断

• 同一个路径字符串，不保证当前仍指向原来的文件对象。
• 删除锁文件不是解锁；解锁应调用持有该 Flock 实例的 Unlock 或 Close。
• Stat、文件存在与否和锁占用状态是不同信息，跨平台代码还要遵循库文档的行为边界。

因此，修复这类问题的重点不是给删除操作加一个更长的延时，而是把锁的所有权和释放动作收回到同一个 Flock 实例，并禁止持锁期间删除共享路径。

相关问题

Flock 的 Close 会删除锁文件吗？不会。官方文档说明 Close 等价于 Unlock，会释放锁并关闭文件描述符，但不会从磁盘删除文件。

文件不存在能说明没有锁吗？不能。已打开的旧文件对象仍可能存在并持有锁；路径是否存在只是目录项层面的信息。

所有操作系统都一定复现这个问题吗？不能这样保证。Flock 文档明确提示不同平台的锁行为不完全相同，但依赖“删除后仍然安全”的代码设计本身就不稳妥。

参考资料

官方 API 文档：https://pkg.go.dev/github.com/gofrs/flock

官方源码：https://github.com/gofrs/flock/blob/v0.13.1/flock.go