Golang 如何实现一个基于文件系统的锁-Golang-PHP中文网

不能直接用os.openfile加o_excl做锁，因nfs不保证原子性、删文件导致锁失效、无超时及持有者识别机制；推荐用flock系统调用或跨平台lockfile库。

golang 如何实现一个基于文件系统的锁

为什么不能直接用 `os.OpenFile` 加 `O_EXCL` 做锁

很多人第一反应是：创建临时文件时加 O_EXCL，靠原子性实现互斥。这在单机、同一文件系统下确实可行，但实际会踩几个坑：
– NFS 或某些网络文件系统不保证 O_EXCL 的原子性，可能多个进程同时创建成功
– 文件删除后锁就失效，没人负责清理时容易“假死锁”
– 没有超时机制，一旦持有锁的进程崩溃，锁无法自动释放
– 无法区分“谁持有了锁”，不利于调试和抢占式释放

推荐方案：用 `flock` 系统调用（Linux/macOS）+ `syscall.Flock`

Go 标准库没封装 flock，但可通过 syscall 直接调用。它基于内核文件描述符，比文件存在性更可靠，且支持阻塞/非阻塞、共享/独占模式。
关键点：
– 必须对**同一个打开的文件描述符**调用 flock，不是对路径
– 锁随 fd 关闭自动释放（包括进程崩溃时内核回收 fd）
– 不跨进程继承，需显式 fork 才能传递（Go 中通常不涉及）
– Windows 不支持，需 fallback 到命名管道或 syscall.LockFileEx

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

fd, err := syscall.Open("/tmp/myapp.lock", syscall.O_CREAT|syscall.O_RDWR, 0644)
if err != nil {
    return err
}
defer syscall.Close(fd)

err = syscall.Flock(fd, syscall.LOCK_EX|syscall.LOCK_NB) // 非阻塞
if err != nil {
    if err == syscall.EWOULDBLOCK {
        return errors.New("lock not available")
    }
    return err
}
// 成功持有锁，后续操作...

跨平台兼容：用 `github.com/nightlyone/lockfile` 库

自己写 syscall 适配 Windows 太重，日常项目建议用成熟封装。这个库的核心逻辑是：
– Linux/macOS：用 flock
– Windows：用 syscall.CreateFile + syscall.LOCKFILE_EXCLUSIVE_LOCK
– 所有平台都支持 TryLock、Unlock、WithTimeout
注意：
– 锁文件路径必须是绝对路径，相对路径在不同工作目录下会冲突
– 不要手动删锁文件，应调用 Unlock 或让 defer 触发
– 若进程 panic 未 unlock，下次 TryLock 会失败，但库内部会检查锁文件 mtime 是否超期（可配）

l, err := lockfile.New("/tmp/myapp.lock")
if err != nil {
    log.Fatal(err)
}
if err := l.TryLock(); err != nil {
    log.Fatal("can't acquire lock:", err)
}
defer l.Unlock()

// do work...

文件锁 ≠ 分布式锁，别在 NFS 或容器共享卷上强依赖

即使用了 flock，如果多个进程挂载的是同一个 NFS 共享目录，依然可能失效——因为 NFSv3 及更早版本不转发 flock 请求到服务端，客户端各自维护本地锁状态。
常见误用场景：
– Kubernetes StatefulSet 多副本挂同一 PVC（NFS 类型）
– Docker 容器通过 -v 挂载宿主机目录，宿主机本身是 NFS
– CI/CD 流水线中多个 job 并发跑在不同节点，但共享构建目录
此时必须换方案：
– 用 Redis + SET key value NX PX timeout
– 用 etcd 的 lease + compare-and-swap
– 或退回到中心化协调服务（如 ZooKeeper）