Go Flock 同一个 Flock 实例加锁状态为什么不能代表其他进程

使用 github.com/gofrs/flock 时，Flock.Locked() 很容易被误读成“这个锁文件现在是否被任意进程占用”。它实际返回的是当前 *Flock 实例记录的锁状态，而且官方文档明确提醒：读取结果到真正使用它之间，状态可能已经改变。要判断其他进程能不能拿到同一把锁，应创建指向同一路径的另一个实例并调用 TryLock()，让操作系统完成一次真实竞争。

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

Locked() 为什么不能代表其他进程

可以把场景拆成三个实体：锁文件路径是共同约定，内核文件锁是跨进程资源，而 Flock 结构体只是当前 Go 进程用来操作资源的句柄。一个进程里写下 f1 := flock.New(path) 后，f1.Locked() 只能说明 f1 是否成功获得过对应锁，以及它自己的状态是否被更新。

另一个进程即使使用相同路径，也会创建自己的 Flock 实例。它不会自动修改第一个进程内存中的字段。因此，下面这种写法没有跨进程查询意义：

package main

import (
    "fmt"

    "github.com/gofrs/flock"
)

func main() {
    f := flock.New("/tmp/report.lock")
    // Locked 只读取当前实例，不会查询另一个进程的 Flock 对象。
    fmt.Println(f.Locked())
}

即使两个进程打印出不同结果，也不能把某个实例的结果当作全局事实。更重要的是，Locked() 本身是一个瞬时快照：返回 true 后，当前代码到下一步动作之间可能发生解锁、进程退出或其他状态变化。

用第二个实例通过 TryLock 判断占用情况

观察“其他进程是否持有锁”的可靠动作不是读取 f1.Locked()，而是让观察者也尝试获取同一路径的独占锁。若其他进程仍持有锁，TryLock() 会返回 false；若返回 true，说明观察者确实取得了锁，此时它必须在工作结束后调用 Unlock()。

package main

import (
    "fmt"
    "log"

    "github.com/gofrs/flock"
)

func probe(path string) {
    probeLock := flock.New(path)
    // TryLock 不等待；false 表示当前竞争失败，error 表示调用本身出错。
    acquired, err := probeLock.TryLock()
    if err != nil {
        log.Printf("尝试锁定 %s 失败: %v", path, err)
        return
    }
    if !acquired {
        fmt.Println("锁正在被其他进程占用")
        return
    }
    // 只有本次 TryLock 成功的实例才负责释放这次锁。
    defer probeLock.Unlock()
    fmt.Println("探测进程已获得锁，原占用者并不存在")
}

这段逻辑仍然是一次竞争，而不是无副作用的查询：探测成功意味着探测者短暂成为持有者。若业务只是要进入临界区，应直接把真正工作放在成功分支中，减少“先检查、后加锁”造成的检查与使用之间竞态。

Unlock、Close 和锁文件存在性要分开理解

Unlock() 释放当前实例持有的文件锁，但不会自动删除磁盘上的锁文件；Close() 等价于释放锁并关闭底层文件描述符，文件是否删除仍由应用决定。因此，os.Stat(path) 成功只能说明路径上的文件存在，不能说明它当前被哪个进程持有。

还要注意平台差异。官方文档提示，不同操作系统的锁行为并不完全相同；共享锁和独占锁在部分类 Unix 系统上可能发生透明转换。生产代码应让所有参与者使用一致的路径、锁类型和生命周期，不要混用“文件存在”“进程号写入文件”和 Locked() 三种不等价信号。

常见问题

同一个 Flock 实例能不能在多个 goroutine 中使用？

库将 Flock 描述为线程安全接口，但线程安全不等于跨进程共享内存。多个 goroutine 可以共同操作一个实例，其他进程仍需通过自己的实例竞争同一路径。

TryLock 返回 false 时一定是其他进程占用吗？

它首先表示本次非阻塞获取没有成功；权限、路径或平台调用异常应结合返回的 error 判断。不能只看 false 就推断唯一原因。

能否用 Stat 判断锁是否过期？

Stat() 可以提供锁文件的文件信息，文档提到修改时间可用于辅助发现陈旧锁，但它不能直接证明持有者，也不能代替一次真实的锁竞争。

判断边界可以记成一句话：Locked() 看自己，TryLock() 争资源，Stat() 看文件元数据。跨进程互斥代码优先把“获取锁”和“执行临界区”放在同一个成功分支里。