Go sync.Mutex.TryLock 什么时候反而会让逻辑更难验证

如果一段代码只是“抢到锁就做，没抢到就算了”，sync.Mutex.TryLock 可以表达这种最佳努力语义；但只要失败后还必须保证状态更新、任务不丢或请求最终完成，TryLock 往往会让逻辑更难验证。它不会像 Lock 那样排队，失败返回 false 也不建立任何同步关系。判断标准很简单：失败是否允许业务跳过？不允许，就不要把 TryLock 当成带超时的 Lock。

先看清 TryLock 返回值代表什么

sync.Mutex 的零值就是未加锁状态，TryLock 在 Go 1.18 加入标准库。调用成功返回 true，这次调用与 Lock 一样取得互斥权；调用失败返回 false，不会阻塞当前 goroutine，也没有“稍后一定能拿到”的承诺。

更容易被忽略的是内存模型边界：成功的 TryLock 等同于成功的 Lock，而失败的 TryLock 不建立 synchronizes-before 关系。因此，失败分支只能处理不依赖临界区状态的事情，不能把它写成“锁住前先看一眼数据”。

为什么失败分支会让测试变得困难

最常见的写法是把失败直接当作“本轮不处理”。如果这个动作只是刷新一个可重算缓存，问题不大；但如果它代表确认订单、写入游标或发送任务，结果就会随着调度时序改变：测试环境恰好空闲时成功，线上有竞争时静默跳过。

另一种误用是循环调用 TryLock：

for !mu.TryLock() {
    // 忙等会把“等待”变成不可控的 CPU 消耗
}
defer mu.Unlock()
update()

这段代码没有等待上限、取消入口或退避策略。它既不像 Lock 那样清楚地表达等待，也不像任务队列那样能记录未完成工作。即使加上 time.Sleep，测试仍要猜测某个 goroutine 何时刚好释放锁，导致偶发失败。

把 TryLock 限定为可选工作

更稳妥的模式是：核心状态走确定路径，可选工作才尝试抢锁。例如后台指标快照不是每次都必须刷新，失败时返回旧快照或跳过一次即可。成功后要用 defer 释放锁，失败则立即返回，避免在未同步的情况下读取缓存字段。

type Snapshot struct {
    mu    sync.Mutex
    value []byte
}

func (s *Snapshot) RefreshIfIdle(build func() []byte) bool {
    if !s.mu.TryLock() {
        // 刷新是可选工作；失败时不读取或修改受保护数据
        return false
    }
    defer s.mu.Unlock()

    // 只在持锁期间替换完整快照，读者不会看到半成品
    next := build()
    s.value = append(s.value[:0], next...)
    return true
}

这个接口把失败变成明确的返回值，调用方可以统计跳过次数、保留旧结果，或者下一轮再尝试。注意 build 本身如果耗时很长，仍会延长持锁时间；实际项目可以先在锁外构建不可变结果，再短暂加锁完成替换。

按真实需求选择等待方式

如果任务不能丢，使用 Lock 让等待语义显式化；如果等待还要响应取消，把工作交给带 context.Context 的任务循环或 channel。若多个 goroutine 争抢的是“谁来做一次工作”，可以让一个 Worker 串行消费队列，避免每个调用方都对同一把锁做时序猜测。

选择 TryLock 前可以问四个问题：失败是否允许丢弃？失败后是否需要读取共享状态？是否要等待或取消？测试能否不依赖调度顺序？只要第二、第三个问题回答“是”，或者第四个问题回答“不能”，优先改用确定的同步结构。

常见问题

TryLock 失败后能马上读取只读字段吗？

如果该字段由同一把锁保护，不能仅凭失败结果读取。只读不等于无同步要求，应该使用另一套明确的快照或原子同步方案。

TryLock 能实现带超时的加锁吗？

它只提供一次立即尝试，不提供超时、公平性或取消语义。循环重试只是应用层策略，必须额外设计退避、截止时间和退出条件。

什么时候使用 TryLock 是合理的？

当工作是最佳努力且失败可安全丢弃，例如低优先级统计、缓存刷新或非关键清理，并且失败分支不依赖临界区状态时，TryLock 才比较合适。

TryLock 的价值不在于把所有阻塞都消除，而在于表达“现在有空就做一次”。如果业务真正需要最终完成，就让等待、排队和取消成为代码中可观察的结构，测试也会随之简单很多。