Go sync.Mutex.TryLock 怎样判断锁能否立即获取

如果一个后台任务“拿不到锁就跳过本轮”，可以用 sync.Mutex.TryLock 做一次非阻塞尝试。判断规则很简单：返回 true 才表示当前调用已经持有锁；返回 false 只表示这次没有拿到锁，不能进入受保护的临界区。

官方地址：https://pkg.go.dev/sync#Mutex.TryLock

先把 TryLock 的 bool 结果当成所有权判断

我在处理一个可选的周期性刷新任务时，真正需要的不是“等多久”，而是“本轮有没有机会立即做”。这种语义下，TryLock 的返回值就是所有权边界：true 说明当前 goroutine 获得了锁，false 说明锁仍被占用，本轮应当离开或走备用路径。

package main

import "sync"

var refreshMu sync.Mutex

func refreshIfIdle() bool {
    // TryLock 不等待；false 表示本轮不拥有 refreshMu。
    if !refreshMu.TryLock() {
        return false
    }
    defer refreshMu.Unlock() // 只有成功拿锁后，当前函数才负责解锁。

    rebuildSnapshot()
    return true
}

func rebuildSnapshot() {
    // 这里放需要 refreshMu 保护的最小临界区。
}

这个判断不能写成“调用 TryLock 后无论结果如何都 Unlock”。失败时当前 goroutine 根本没有锁，强行解锁会触发运行时错误。图 1 把调用方、返回值和解锁责任放在同一张静态关系图中，便于记住这条边界。

true 之后要把解锁放在成功路径内部

成功调用 TryLock 后，当前代码拥有和 Lock 成功后相同的解锁义务。把 defer Unlock 放在成功判断之后，既能覆盖中途返回，也不会让失败路径误解锁。

func publishOptional(state *State) bool {
    // 只有需要修改共享状态时才尝试进入临界区。
    if !state.mu.TryLock() {
        return false // 忙时交给下一轮，不把等待变成隐式阻塞。
    }
    defer state.mu.Unlock()

    if state.closed {
        return false // defer 仍会在返回前释放成功获得的锁。
    }
    state.lastPublished = nextPayload()
    return true
}

type State struct {
    mu            sync.Mutex
    closed        bool
    lastPublished string
}

func nextPayload() string {
    // 示例只表达临界区内生成新状态的占位逻辑。
    return "ready"
}

解锁责任和 goroutine 身份没有绑定：官方文档允许一个 goroutine 加锁后安排另一个 goroutine 解锁，但普通业务代码仍应让获取锁和释放锁的生命周期尽量靠近，避免所有权难以追踪。TryLock 不是“试一下就自动释放”的探测 API，成功后仍然要按互斥锁规则管理资源。

false 不建立同步关系，不能拿它当安全读取许可

这是最容易被忽略的区别。官方文档明确说明，成功的 TryLock 等价于成功的 Lock；失败的 TryLock 不建立任何 synchronizes-before 关系。因此，下面这种写法并不安全：先 TryLock，失败后直接读取共享字段，认为“只是读一下所以没关系”。

func readWhenFree(state *State) (string, bool) {
    // false 只说明没有拿到锁，不能授权读取受保护字段。
    if !state.mu.TryLock() {
        return "", false
    }
    defer state.mu.Unlock()
    return state.lastPublished, true
}

如果读取结果必须准确，失败时应返回“暂时不可用”、使用独立的原子变量，或改用能表达等待/通知的通信方式。不要把失败分支伪装成低成本的无锁读。

什么时候应该使用 TryLock

TryLock 的价值不在于让所有锁都变成“更快”，而在于业务已经允许本次工作放弃或降级。例如刷新缓存、采集非关键指标、合并重复通知时，可以在锁忙时记录一次跳过，等待下一轮重新尝试。

官方文档也提醒，TryLock 的正确使用场景较少，经常提示更深层的互斥设计问题。这个提醒不是说它不能用，而是要求先写清“失败时业务做什么”。如果失败只能继续无限重试，或者为了保证正确性必须等待，那么直接使用 Lock 往往更清楚。

常见问题

TryLock 返回 false 是不是超时？

不是。它只做一次立即尝试，没有等待时长和超时语义；false 表示当前调用没有获得锁。

TryLock 成功后可以不 Unlock 吗？

不可以。成功后当前调用持有锁，通常应立刻安排 defer Unlock()，否则后续调用可能永久阻塞。

失败后能否读取只读字段？

如果该字段由这把锁保护，就不能因为“只读”而绕过同步。应使用原子或不可变数据等明确的并发方案。

TryLock 是否适合实现通用超时锁？

通常不应直接循环调用它模拟超时。这样会把等待、退避和取消语义藏在自旋逻辑里，优先重新评估锁、channel 或上下文协调模型。