当前位置：首页 > 文章列表 > Golang > Go问答 > Go Flock 删除锁文件为什么可能破坏进程间互斥

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

来源：17golang原创 2026-10-29 14:23:13 0浏览收藏

我在排查一个“偶尔有两个进程同时进入任务”的问题时，第一眼看到的是同一个锁文件路径：/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 正在持有锁的旧对象，于是两个进程就可能同时进入本应互斥的临界区。这里的关键不是“删除操作一定立刻造成并发”，而是它破坏了所有进程通过同一对象竞争锁的前提。

路径名、旧文件对象、内核锁与删除后新文件对象之间的静态关系说明图 — 图1：边界说明图，路径名被重新创建后，旧文件对象上的锁不会自动转移到新对象。

这和“进程退出后内核自动释放锁”是两件事。进程正常退出或关闭句柄，锁会按平台规则释放；而主动删除路径只改变名称空间，不能替代对已打开对象执行 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 实例绑定，不要让另一个“清理文件”的协程凭路径猜测状态。

flock.New、TryLock、临界区、Unlock、Close、Stat 与清理策略的职责关系说明图 — 图2：生命周期结构图，释放锁应由 Unlock 或 Close 完成，文件清理由独立策略负责。

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

有些程序希望在重启后清理遗留的锁文件。此时不要用“文件存在很久”直接推出“锁已经失效”，更不能为了清理而无条件 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
}