Go Flock 锁文件还存在为什么不代表锁仍被占用

在 Go 项目里看到 /tmp/report.lock 还存在，不能直接推断文件仍被占用。github.com/gofrs/flock 把锁路径作为协作入口，真正的互斥状态由文件描述符和操作系统维护；调用 Unlock() 会释放锁并关闭底层文件描述符，但不会替应用删除磁盘上的锁文件。

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

判断是否仍被占用，要看一次实际的锁操作或当前 Flock 实例状态，而不是只看锁文件是否存在。锁文件可以长期留在目录里，下一次程序仍然可以通过 TryLock() 判断是否能取得独占锁。

锁文件、文件锁和 Flock 实例不是一回事

flock.New(path) 保存的是路径与本次操作的状态。路径指向一个普通文件，文件是否存在属于磁盘层面的事实；是否能取得独占锁，则是当前进程向操作系统发起锁请求后的结果。两者并不是同一个布尔值。

package main

import (
    "fmt"
    "path/filepath"
    "os"

    "github.com/gofrs/flock"
)

func main() {
    // 锁路径可以固定，真正的占用状态由 TryLock 的返回值决定。
    path := filepath.Join(os.TempDir(), "report.lock")
    fileLock := flock.New(path)

    locked, err := fileLock.TryLock()
    if err != nil {
        // 打开文件或请求系统锁失败时，保留底层错误供上层处理。
        panic(fmt.Errorf("try lock %s: %w", path, err))
    }
    if !locked {
        // 文件存在不等于这里能拿到锁；竞争失败应走业务重试或退出分支。
        fmt.Println("锁当前被其他进程占用")
        return
    }

    defer func() {
        // 成功拿锁后只做一次释放，避免多个分支遗漏 Unlock。
        if err := fileLock.Unlock(); err != nil {
            fmt.Printf("释放文件锁失败: %v\\n", err)
        }
    }()

    fmt.Println("已进入临界区")
}

这段代码里，即使 Unlock() 返回成功，report.lock 仍可能出现在磁盘上。它只是下一次参与协作时使用的名字，不是“当前有人持锁”的标记。

Unlock 释放的是占用，不是路径

把删除锁文件当成解锁，是最常见的误判。程序拿锁时，操作系统会针对打开的文件建立锁状态；释放时应调用同一个 Flock 实例的 Unlock()。删除路径既不能替代释放动作，也可能让其他进程失去共同的锁名。

如果程序异常退出，锁状态通常会随操作系统回收对应的文件描述符；但路径本身不一定消失。因此“重启后仍看到锁文件”并不能证明上一个进程还活着，也不能单凭文件修改时间认定它是死锁。

判断当前是否真的被占用

诊断时把三个问题分开：当前实例有没有成功持锁，其他进程现在是否能竞争成功，以及磁盘上的锁文件有哪些元数据。Locked() 只适合观察当前实例；它不是跨进程探针，官方文档也提醒返回值到使用时状态可能已经变化。

package main

import (
    "fmt"
    "os"
    "path/filepath"

    "github.com/gofrs/flock"
)

func inspect(path string) error {
    // 新建实例只是准备一次检查，不会因为路径存在就自动认为已占用。
    fileLock := flock.New(path)

    if fileLock.Locked() {
        // 这里只能说明当前实例的记录，不代表其他进程的状态。
        fmt.Println("当前实例已经持锁")
        return nil
    }

    locked, err := fileLock.TryLock()
    if err != nil {
        // 系统调用错误和竞争失败要分开记录，便于判断权限或路径问题。
        return fmt.Errorf("probe lock: %w", err)
    }
    if locked {
        defer func() {
            // 探针成功拿锁也必须释放，否则检查动作本身会制造占用。
            _ = fileLock.Unlock()
        }()
        fmt.Println("当前可以取得独占锁")
        return nil
    }

    // Stat 读取文件元数据；它不能替代 TryLock 判断内核锁状态。
    info, err := fileLock.Stat()
    if err != nil {
        if os.IsNotExist(err) {
            return fmt.Errorf("锁文件不存在: %w", err)
        }
        return fmt.Errorf("读取锁文件元数据: %w", err)
    }
    fmt.Printf("无法取得锁，文件修改时间: %s\\n", info.ModTime().Format("2006-01-02 15:04:05"))
    return nil
}

func main() {
    // 让检查路径与业务实际使用的路径保持一致。
    path := filepath.Join(os.TempDir(), "report.lock")
    if err := inspect(path); err != nil {
        fmt.Println(err)
    }
}

上面的探针有一个重要细节：如果 TryLock() 成功，它就真的拥有了锁，哪怕只为检查也必须立即 Unlock()。Stat() 可以查看文件信息，例如修改时间，但不能证明该文件当前仍被某个进程锁住。

异常退出与跨平台场景怎么处理

• 不要用文件存在判断“死锁”。先用一次非阻塞的 TryLock()，返回 false 才表示本次竞争没有成功。
• 不要用删除文件代替 Unlock。把删除作为独立的目录清理策略，并确保不会破坏其他进程使用同一路径的协作。
• 给成功持锁的实例绑定释放动作。拿锁后立即注册 defer Unlock()，并对释放错误保留日志。
• 留意平台差异。官方文档说明不同平台的锁行为不保证完全相同，共享锁与独占锁混用时尤其要按目标系统单独评估。

可以把结论简化为：路径解决“大家锁哪个对象”，TryLock() 解决“这一次能不能拿到”，Unlock() 解决“当前占用何时结束”，Stat() 只补充文件元数据。把这四件事分开，残留锁文件就不会再被误认为仍有进程占用。

相关问题

锁文件残留了，需要每次启动都删除吗？

通常不需要。先用与业务相同的锁路径尝试获取锁；只有目录清理策略明确要求时，才在确认没有并发使用者后处理文件。

能用 Locked() 判断整个机器上的锁状态吗？

不能。它反映当前 Flock 实例的状态，跨进程判断应使用一次实际的锁竞争结果，并把权限、路径和平台差异作为错误诊断的一部分。