Go 并发编程中的非阻塞锁：TryLock()

Chloe

发布时间：2026-08-25 | 6人浏览过

原创

前言

做 Go 并发开发时，大家最熟悉的通常是 `Lock()`：先把共享资源保护起来，拿不到锁的协程就等着。但项目里并不是所有场景都适合“等到拿到为止”，有些操作更需要快速判断能不能执行，不能执行就立刻退出。本文就围绕 Go 1.18 引入的 `TryLock()` 来看它和普通加锁的区别、适合放在哪些业务位置，以及什么时候应该优先考虑 `channel`、`context`、`select` 这类更贴近 Go 风格的并发方案。

做 Go 并发开发时，大家最熟悉的通常是 Lock()：先把共享资源保护起来，拿不到锁的协程就等着。但项目里并不是所有场景都适合“等到拿到为止”，有些操作更需要快速判断能不能执行，不能执行就立刻退出。本文就围绕 Go 1.18 引入的 TryLock() 来看它和普通加锁的区别、适合放在哪些业务位置，以及什么时候应该优先考虑 channel、context、select 这类更贴近 Go 风格的并发方案。

Lock() 和 TryLock() 到底差在哪

在 Go 里，常见的锁主要是互斥锁 sync.Mutex{} 和读写锁 sync.RWMutex{}。它们都实现了 sync.Locker 接口：

对比 Lock 和 TryLock 行为差异的暖色专栏手绘图 — **阻塞等待与立即返回**用两条不同处理路径展示阻塞等待与失败即返的核心区别，帮助读者快速判断两者适用前提。

// A Locker represents an object that can be locked and unlocked.
type Locker interface {
    Lock()
    Unlock()
}

调用 Lock() 之后，如果锁已经被别的协程持有，那么当前协程会被阻塞，直到前一个持锁者释放锁。这种方式适合“这段逻辑必须执行完，资源也必须拿到”的场景，因为它会一直等到成功为止。

问题在于，真实业务里并不总是需要这种等待。有些任务本来就是可跳过的、可丢弃的，或者只允许一个请求先进入，后来的请求没必要排队。对于这类场景，阻塞等待反而会拉长处理链路，甚至让协程堆积。

Go 早期标准库里没有现成的非阻塞加锁方案，这也是为什么过去会出现不少第三方实现。到了 Go 1.18，官方在 sync.Mutex{} 和 sync.RWMutex{} 中加入了 TryLock()，开发者终于可以直接使用标准库提供的尝试加锁能力。

Go 1.18 的 TryLock() 是怎么工作的

TryLock() 的语义很直接：尝试加锁，成功返回 true，失败返回 false。和 Lock() 最大的区别，不在于加锁目标变了，而在于失败后的行为变了。

它不会在失败时继续等待，而是把“拿不到锁怎么办”这个决定权交还给调用方。业务代码可以据此选择直接返回、跳过当前任务、记录状态，或者走一条降级路径。

// TryLock tries to lock m and reports whether it succeeded.
//
// See package [sync.Mutex] documentation.
func (m *Mutex) TryLock() bool {
    old := m.state
    if old&(mutexLocked|mutexStarving) != 0 {
        return false
    }

    // There may be a goroutine waiting for the mutex, but we are
    // running now and can try to grab the mutex before that
    // goroutine wakes up.
    if !atomic.CompareAndSwapInt32(&m.state, old, old|mutexLocked) {
        return false
    }

    if race.Enabled {
        race.Acquire(unsafe.Pointer(m))
    }
    return true
}

从这段实现也能看出来，TryLock() 本质上还是在尝试获得同一把锁，只是没有阻塞等待这一步。成功时照常进入临界区，失败时立刻结束本次尝试。

这里有一个很容易被忽略的点：TryLock() 一旦成功，后续的使用规则和 Lock() 没有区别，最终仍然必须调用 Unlock() 释放锁。它只是“尝试进入”的方式变了，不代表锁的生命周期管理可以放松。