Go sync.Mutex.TryLock 失败时为什么不能当作已经解锁

我在排查“非阻塞刷新”这类代码时，最容易被忽略的一点不是 TryLock 怎么调用，而是失败以后到底有没有获得释放锁的资格。结论先说：sync.Mutex.TryLock() 返回 true，才表示当前调用成功取得了锁；返回 false 只表示这次没有取得锁，不能把它理解成“锁已经解锁”，更不能在失败路径里无条件调用 Unlock()。

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

先把 TryLock 的两个结果分开

TryLock 是一次“尝试取得锁”的动作，不是“查询锁状态后顺便修改状态”的两个独立步骤。调用返回 true 时，当前调用已经完成加锁；返回 false 时，当前调用没有取得锁，应该把这次尝试当作没有进入临界区。

这也是标题中那个误解的根源：中文里“失败”容易被联想到“没有锁住”，但这里的“没有锁住”是指当前调用没有持有，而不是它替别人做了释放。谁成功加锁，谁就要负责匹配解锁；失败者没有这个责任。

支持范围和最小安全写法

Mutex.TryLock 是 Go 标准库的方法，官方文档标记为 Go 1.18 加入。只要项目的最低 Go 版本满足要求，就可以直接使用；如果还要兼容更早版本，不能仅靠改写调用名解决，需要回到阻塞式 Lock，或者重新设计“不等待”的业务路径。

在一个缓存刷新任务里，常见的意图是：如果刷新锁空闲就做一次刷新；如果已经有人刷新，则本轮跳过。此时可以把清理动作放在成功判断之后：

package main

import (
    "fmt"
    "sync"
)

// refreshOnce 只在本轮成功取得锁时执行刷新，忙时直接放弃本轮。
func refreshOnce(mu *sync.Mutex) {
    if !mu.TryLock() {
        // false 表示没有取得锁；当前函数没有 Unlock 的责任。
        fmt.Println("刷新正在进行，本轮跳过")
        return
    }
    // defer 必须写在成功之后，保证只为本次成功加锁登记一次解锁。
    defer mu.Unlock()

    // 这里才是需要互斥保护的刷新工作。
    fmt.Println("开始刷新共享状态")
}

func main() {
    var mu sync.Mutex
    refreshOnce(&mu)
}

这个顺序有两个好处：失败路径在视觉上就是“打印并返回”，成功路径才拥有临界区；同时 defer 紧跟成功判断，后续在函数中增加返回分支时也不容易漏掉解锁。

为什么无条件 Unlock 会把失败路径变成运行时错误

下面这种写法看起来像是“无论是否成功都清理一下”，但它把没有获得锁的分支也送进了 Unlock：

func unsafeRefresh(mu *sync.Mutex) {
    // 尝试失败时，ok 为 false，当前调用并没有持有 mu。
    ok := mu.TryLock()
    // 错误：无论 ok 是什么都解锁，失败分支会在未持锁时调用 Unlock。
    defer mu.Unlock()
    if !ok {
        // 这里没有临界区，也没有可以由当前调用释放的锁。
        return
    }
    // 只有 ok 为 true 时，下面的工作才处于互斥保护中。
    fmt.Println("执行刷新")
}

sync.Mutex.Unlock 的约束不是“把锁状态尽量改成未锁定”，而是调用时这个 Mutex 必须已经被锁定。官方文档明确说明，未锁定时进入 Unlock 是运行时错误。因此，TryLock 的返回值必须参与控制流，而不是只用于打印日志。

把 Unlock 放进成功分支

如果代码不是一个短函数，而是包含多个早退点，可以先把成功结果转成明确的“持锁作用域”。关键仍然是：所有能执行 Unlock 的路径，都必须先经过成功返回。

func refreshWithFallback(mu *sync.Mutex, cached string) string {
    if !mu.TryLock() {
        // 没有取得锁时直接返回旧值，避免等待和错误解锁。
        return cached
    }
    // 只有成功分支能走到这里，所以 defer 与本次加锁一一对应。
    defer mu.Unlock()

    // 模拟在临界区内更新共享缓存；真实代码应缩短这段持锁时间。
    updated := "fresh-value"
    if updated == "" {
        // 即使临界区内提前返回，defer 仍会释放已经取得的锁。
        return cached
    }
    return updated
}

这里的“降级”只是示例：返回旧缓存、跳过可合并任务、把工作放进下一轮队列，都是业务决定。不要为了复用一个返回值而把失败和成功混成同一条清理路径；失败分支应该明确表达“这次没有进入临界区”。

兼容处理、性能和安全边界

从体验上看，TryLock 的价值是“不等待”，但“不等待”不等于“更快”。失败时如果每次都放弃工作，可能造成刷新饥饿；成功后如果把网络请求、磁盘操作或慢查询放在锁内，又会让其他调用长期失败。一个实用的判断顺序是：

1. 先确认业务确实允许本轮跳过，不能把必须完成的写入改成静默丢弃。
2. 成功后尽快复制必要状态，再缩短持锁区；不要把不可控的外部 I/O 放在 Mutex 保护范围内。
3. 如果失败任务必须最终完成，使用队列、信号或普通 Lock，不要靠高频轮询 TryLock。
4. 如果项目要兼容 Go 1.17 及更早版本，优先改回 Lock 或调整接口，不要伪造一个没有原子语义的“先检查再加锁”。

官方文档也提醒，正确使用 TryLock 的场景较少，频繁出现时往往说明锁的职责或任务调度方式还可以重新设计。它不是一个通用的性能开关，更不是用来掩盖共享状态边界不清的工具。

常见问题

TryLock 返回 false 后能不能由当前 goroutine 调用 Unlock

不能。失败返回表示这次调用没有取得锁，当前 goroutine 没有可匹配的解锁责任；调用 Unlock 可能触发运行时错误。

成功后一定要由同一个 goroutine Unlock 吗

不是。Go 文档说明 Mutex 不绑定特定 goroutine，确实允许一个 goroutine 加锁、另一个 goroutine 解锁。但这种交接必须是明确的所有权设计；在普通函数中，成功后用同一作用域的 defer Unlock 更容易维护。

TryLock 失败会不会建立同步关系

不会。官方文档说明，失败的 TryLock 不建立任何“先发生于”同步关系。不要把一次失败尝试当成读取共享状态的同步屏障。

什么时候应该直接使用 Lock

当任务不能跳过、需要稳定完成，或失败后还要等待资源时，阻塞式 Lock 通常更直接。只有当业务明确允许“忙时跳过或降级”，并且你能接受失败策略，才考虑 TryLock。