Go sync.RWMutex.TryLock 怎样实现非阻塞写入尝试

在读多写少的缓存中，后台刷新经常不值得为了“一定成功”而排队。如果当前有读者或另一个写入者占着 sync.RWMutex，本轮刷新可以直接放弃，等待下一次调度。Go 提供的 TryLock 正好表达这个意图：尝试获得写锁，成功返回 true，繁忙时立即返回 false。

关键点是，TryLock 不是带超时的 Lock。它只做一次尝试；返回 true 后，当前调用方必须像使用 Lock 一样负责 Unlock。

先把一次刷新拆成输入、锁和结果

可以把刷新过程看成一条短数据链路：刷新任务提供新快照，TryLock 决定是否进入写入区，成功后更新共享缓存，最后释放写权限；失败分支不修改共享状态，只记录“本次跳过”。

最小可用写法：成功才进入写锁区域

下面的例子模拟刷新一个字符串快照。读路径使用 RLock，写路径使用 TryLock；因为写入区足够短，读者不会长期被刷新任务阻塞。

package main

import (
    "fmt"
    "sync"
)

type Snapshot struct {
    mu   sync.RWMutex
    data string
}

// TryRefresh 只尝试一次写入；锁繁忙时保留旧快照。
func (s *Snapshot) TryRefresh(next string) bool {
    if !s.mu.TryLock() {
        // 本次刷新可丢弃，避免后台任务在写锁上排队。
        return false
    }
    defer s.mu.Unlock() // 成功拿锁后，无论后续如何返回都要释放。

    s.data = next // 锁内只做共享状态替换，不放耗时 I/O。
    return true
}

// Read 返回一个锁保护下的快照副本。
func (s *Snapshot) Read() string {
    s.mu.RLock()
    defer s.mu.RUnlock() // 读完立刻释放读锁，避免阻塞后续写入。
    return s.data
}

func main() {
    var cache Snapshot
    if cache.TryRefresh("v2") {
        fmt.Println("refresh applied:", cache.Read())
    } else {
        fmt.Println("refresh skipped")
    }
}

这里最重要的不是返回值本身，而是返回值控制了写入区的入口。失败时没有获得锁，不能调用 Unlock；成功时必须成对释放。将 defer 放在成功判断之后，可以避免解锁一个并未持有的锁。

把耗时准备工作放到锁外

如果新数据来自网络、文件或数据库，先在锁外准备好不可变快照，再用 TryLock 做一次很短的替换。这样“非阻塞”才有实际意义，否则虽然没有等待获得锁，拿到锁后仍可能长时间挡住读者。

func (s *Snapshot) RefreshFrom(fetch func() (string, error)) (bool, error) {
    next, err := fetch()
    if err != nil {
        // 拉取失败不触碰旧快照，把错误交给调用方决定是否重试。
        return false, err
    }

    if !s.mu.TryLock() {
        // 新快照已经准备好，但当前策略允许本轮跳过发布。
        return false, nil
    }
    defer s.mu.Unlock()
    s.data = next // 锁内只有一次内存替换。
    return true, nil
}

这段代码把数据生命周期分成“生成候选快照”和“发布共享快照”两段。第一段可以慢，第二段应尽量短；如果业务不能丢掉这次结果，就不应把 TryLock 当成默认方案。

TryLock 和 Lock 应该怎样选择

Go 官方文档也提醒，正确使用 TryLock 的场景比较少。若每次写入都不能跳过，或者代码不断循环调用 TryLock 直到成功，通常说明调用方真正需要的是排队、通知或重新设计共享状态，而不是忙等。

三个容易忽略的边界

1. 不要把 false 当成异常。 对可丢弃刷新来说，false 是正常的调度结果；可以记录计数，避免把日志打成错误。
2. 不要在循环中无间隔重试。 连续 TryLock 会制造忙等压力。需要最终成功时，应改用 Lock、定时重试或通道通知。
3. 不要复制已经使用过的 RWMutex。 锁只保护原对象的共享状态，结构体传值可能让调用方误以为拿到了同一把锁。

func (s *Snapshot) TryRefreshWithMetric(next string, skipped *uint64) bool {
    if !s.mu.TryLock() {
        // 失败只记录一次跳过事件，具体指标实现可替换为原子计数器。
        *skipped++
        return false
    }
    defer s.mu.Unlock()
    s.data = next
    return true
}

示例中的计数器只用于表达业务分支；并发程序里应使用原子操作或专用指标库保护它。锁的职责仍然只是保护快照，不要把统计系统也塞进锁内。

结论：把 TryLock 当作一次机会，而不是缩短版 Lock

实现非阻塞写入的最小规则可以压缩成四句：先在锁外准备数据；用 TryLock 做一次尝试；只有成功后才修改共享状态；成功后无条件释放写锁。若本次写入不可丢失，就选择 Lock 或显式的任务协调机制。

这样设计后，TryLock 的 false 就有清晰含义：当前刷新机会被让给正在运行的读写操作，旧数据仍然有效，下一轮任务再决定是否重试。

相关问题

TryLock 失败后要不要立刻再试一次？

一般不要。立刻循环会变成忙等；若结果必须完成，应使用 Lock 或带节奏的调度。

TryLock 成功后可以不调用 Unlock 吗？

不可以。成功后未释放会让后续读写操作持续阻塞，推荐在成功判断后立即注册 defer Unlock。

TryLock 能不能实现超时等待？

它本身不是超时接口，只尝试一次。超时语义应交给通道、任务队列或其它可等待的协调方案。