Go Flock 怎样用上下文超时等待文件锁

需要让多个 Go 进程轮流处理同一份文件时，github.com/gofrs/flock 可以把“等待多久”交给 context.Context。关键写法是 TryLockContext(ctx, retryDelay)：它不会像 Lock() 那样无限阻塞，而是重复尝试获取独占锁，直到成功、底层返回错误，或者上下文结束。

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

下面的示例把等待上限设为 3 秒，把两次尝试之间的间隔设为 100 毫秒。拿到锁后才进入临界区，超时则把 context.DeadlineExceeded 作为可识别的失败原因返回。

先把锁等待和业务处理分开

文件锁的职责是协调多个进程访问同一个资源，超时策略则属于调用方。建议先创建锁对象，再创建带超时的上下文；这样锁路径、等待上限和重试间隔都能在入口处看清楚。

package main

import (
    "context"
    "errors"
    "fmt"
    "time"

    "github.com/gofrs/flock"
)

func acquire(ctx context.Context, path string) error {
    // 锁对象只负责协调同一个锁文件，不把业务状态放进 Flock。
    fileLock := flock.New(path)

    locked, err := fileLock.TryLockContext(ctx, 100*time.Millisecond)
    if err != nil {
        // 底层打开或加锁失败时保留原始错误，便于上层记录原因。
        return fmt.Errorf("acquire file lock: %w", err)
    }
    if !locked {
        // ctx 到期时通常走这里，用 ctx.Err() 区分超时和主动取消。
        return fmt.Errorf("lock wait stopped: %w", ctx.Err())
    }

    defer func() {
        // 只有成功持锁后才解锁；忽略解锁错误会掩盖资源释放问题。
        if unlockErr := fileLock.Unlock(); unlockErr != nil {
            fmt.Printf("unlock file lock: %v\\n", unlockErr)
        }
    }()

    // 这里放真正需要互斥的文件读写或生成动作。
    return nil
}

func main() {
    // 超时只约束等待锁的阶段，业务耗时不应继续复用这个短上下文。
    waitCtx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
    defer cancel()

    if err := acquire(waitCtx, "/tmp/report.lock"); err != nil {
        if errors.Is(err, context.DeadlineExceeded) {
            fmt.Println("等待文件锁超时")
            return
        }
        fmt.Printf("获取文件锁失败: %v\\n", err)
    }
}

TryLockContext 返回值应该怎样判断

这个方法返回 (bool, error)，两个返回值不能只看一个。err != nil 表示尝试过程遇到了底层错误；locked == true 表示当前 Flock 实例已经持有独占锁；当上下文结束且没有拿到锁时，通常是 locked == false，此时应该读取 ctx.Err() 判断是超时还是调用方主动取消。

不要用 Locked() 代替返回值判断。文档明确提醒，读取到的锁状态可能在随后发生变化；它适合做状态展示或诊断，不适合作为一次获取动作的成功凭据。

重试间隔、超时和释放动作怎么配

retryDelay 决定未拿到锁时多久再尝试一次。间隔太短会增加系统调用频率，间隔太长则会让短暂空闲被错过；常见的文件生成任务可以从几十到几百毫秒开始，再按竞争程度调整。超时应覆盖“愿意排队等锁”的时间，而不是覆盖整个业务处理时间。

拿到锁以后要立刻注册 defer fileLock.Unlock()，不要把解锁放在多个业务分支的末尾。Unlock 会释放文件锁并关闭底层文件描述符，但不会删除磁盘上的锁文件；锁文件存在不等于锁仍被占用。

常见误区与适用边界

• 把 Lock() 当成有超时的等待。它是阻塞调用，有限等待应改用 TryLockContext。
• 拿到锁后继续使用“等待锁”的短上下文。更稳妥的做法是让上下文只控制排队阶段，业务函数使用自己的取消策略。
• 把删除 report.lock 当成解锁。真正的释放动作是 Unlock；锁文件可以继续留在磁盘上供下一次打开。
• 在共享锁和独占锁混用时忽略平台差异。官方文档提醒，不同类 Unix 系统的锁行为并不完全一致，读锁在部分系统上可能被透明转换为独占锁。

如果需求是“尽量拿锁，拿不到就立即返回”，使用 TryLock() 更直接；如果需求是“最多等一段时间”，使用 TryLockContext 并明确记录超时；如果任务必须排队且没有上限，才考虑阻塞式 Lock()。

相关问题

超时后需要手动删除锁文件吗？

通常不需要。超时意味着当前实例没有成功持锁；锁文件只是协作所需的路径，是否清理由应用的文件管理策略决定。

成功拿锁后能否复用同一个 Flock 对象？

可以围绕明确的生命周期使用，但每次成功持锁都要对应一次可靠的 Unlock。如果业务希望重试，优先重新组织等待上下文和临界区，不要让旧的持锁状态跨越多个不相关任务。