Go Flock 怎样用 TryLock 实现非阻塞进程互斥

Go 进程之间需要“抢到就做、抢不到就返回”时，github.com/gofrs/flock 的 TryLock() 比阻塞式 Lock() 更合适。它返回两个值：locked 表示是否拿到排他文件锁，err 表示路径、权限或平台调用是否出错。locked=false 通常只是说明已有进程持有锁，不应被当成系统故障。

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

准备稳定的 Flock 锁对象

先在模块中加入依赖，再为同一资源选一个固定路径。路径不是随手生成的临时文件名：两个进程只有打开同一个锁文件，操作系统层的互斥才有共同边界。生产环境通常把它放在服务有权限访问、且所有实例都能看到的目录中。

# 在 Go module 根目录固定依赖版本，避免不同构建环境漂移
go get github.com/gofrs/flock
go mod tidy

package main

import (
    "path/filepath"

    "github.com/gofrs/flock"
)

func newJobLock() *flock.Flock {
    // 所有执行同一任务的进程都必须使用同一个绝对路径。
    path := filepath.Join("/var", "lock", "report-job.lock")
    return flock.New(path)
}

如果锁文件目录不存在、不可写，或者不同容器看到的不是同一文件系统，后面的 TryLock 可能返回错误。先把目录和路径策略定下来，再编写抢锁逻辑。

先区分 TryLock 的占用结果与错误

TryLock() 对排他锁执行非阻塞尝试：成功返回 true；文件已被其他持有者锁住时返回 false，而不是等待；底层打开文件或加锁失败时才返回错误。它内部仍可能短暂等待同一个 Flock 实例的内部互斥，但文件锁本身不会排队等待。

func tryRun(lock *flock.Flock) error {
    // locked=false 代表竞争失败，调用方可以跳过本轮任务。
    locked, err := lock.TryLock()
    if err != nil {
        // 这里处理权限、路径或平台层错误，而不是把它当作“忙”。
        return fmt.Errorf("try lock %q: %w", lock.Path(), err)
    }
    if !locked {
        // 非阻塞策略的正常分支：让其他进程继续持有临界区。
        return ErrBusy
    }

    // 只有 locked=true 才允许进入临界区。
    return doExclusiveWork(lock)
}

上面的示例需要补充 fmt、errors 和业务错误定义；关键判断顺序不能反过来。先处理 err，再处理 locked，可避免把权限错误误报成“任务正在运行”。

把临界区和 Unlock 责任绑在一起

抢到锁后应立即安排释放责任，再执行真正的工作。这样即使函数在中途返回，清理逻辑也仍然存在。Unlock() 会释放锁并关闭底层文件描述符，但不会删除磁盘上的锁文件；不要把“文件还在”误认为“锁仍被持有”。

var ErrBusy = errors.New("job is already running")

func doExclusiveWork(lock *flock.Flock) error {
    // 成功抢锁后立刻登记释放动作，覆盖业务早退路径。
    defer func() {
        if err := lock.Unlock(); err != nil {
            // 真实服务应记录释放错误，不能静默吞掉资源异常。
            log.Printf("unlock %q: %v", lock.Path(), err)
        }
    }()

    // 临界区只放需要跨进程互斥的读写或生成动作。
    return rebuildReport()
}

如果业务必须区分“没抢到”与“锁操作失败”，可以让上层用 errors.Is(err, ErrBusy) 做跳过、延迟或指标统计。不要在未成功加锁时调用临界区，也不要把整个长生命周期服务包在文件锁里。

等待窗口要交给 TryLockContext

有些任务允许等待几秒，但不能无限阻塞。TryLockContext(ctx, retryDelay) 会重复尝试，直到成功、遇到错误或 ctx.Done() 关闭。retryDelay 控制重试间隔，context 的 deadline 负责总等待上限；两者分别解决“多久试一次”和“最多等多久”。

func tryRunWithDeadline(lock *flock.Flock) error {
    // deadline 约束总等待时间，避免进程无限卡在资源竞争上。
    ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
    defer cancel()

    // 200ms 是示例间隔，生产值应结合任务时延和冲突率调整。
    locked, err := lock.TryLockContext(ctx, 200*time.Millisecond)
    if err != nil {
        // 库错误与 context 结束都应交给调用方决定是否重试。
        return fmt.Errorf("wait for lock: %w", err)
    }
    if !locked {
        // 在等待窗口内仍未得到锁，保持“未执行”语义。
        return ErrBusy
    }
    return doExclusiveWork(lock)
}

如果需求是绝不等待，直接使用 TryLock()；如果需要重试但可以取消，才引入 TryLockContext()。不要用固定间隔的无限 for 循环替代 context，否则服务停机时很难收敛。

按平台和部署边界做检查

文件锁的行为受操作系统和文件系统影响，不能把一次机器上的结果推成所有平台都完全相同。重点检查四件事：锁文件目录是否对服务用户可写；所有进程是否看到了同一个路径；锁文件是否位于支持目标锁语义的文件系统；是否在日志和指标中区分忙、错误与成功。

另外，Locked() 只是某个时刻的状态查询，返回后状态仍可能变化，不能用它代替 TryLock() 的原子竞争。需要清理锁文件时由应用自行决定，但删除文件不能作为释放锁的替代方案。

常见问题

TryLock 返回 false 时要立刻重试吗？

不一定。无阻塞任务通常直接结束或记录跳过；有明确等待预算时用 TryLockContext，把重试次数和总时长交给 context 约束。

Unlock 会删除 .lock 文件吗？

不会。它释放文件锁并关闭底层描述符，锁文件是否删除由应用决定；保留空锁文件本身是常见做法。

可以先调用 Locked 再决定是否执行吗？

不建议。状态查询和真正加锁之间存在竞争窗口，应该直接检查 TryLock 返回值。