Go sync.Mutex 嵌套调用的解锁边界与临界区拆分方案

如果一个方法已经持有 sync.Mutex，又调用了一个会对同一把锁执行 Lock() 的方法，问题通常不是“锁偶尔失效”，而是调用链把自己堵住了。Go 的 Mutex 不提供递归加锁：锁已被占用时，当前调用会等待它可用；而当前 goroutine 又无法走到后面的 Unlock()，于是形成自阻塞。

处理这类问题的关键，是把“谁获取锁、谁释放锁、哪些代码必须在临界区内”写清楚。下面只讨论同一 goroutine 重复请求同一把锁的场景。

为什么嵌套调用会把自己堵住

先沿调用栈找锁，而不是先把锁换成 RWMutex 或加一个超时。典型结构是外层方法拿锁后调用内层方法，内层方法为了“自我保护”再次拿同一个接收者上的锁：

type Store struct {
	mu   sync.Mutex
	items map[string]string
}

func (s *Store) Save(key, value string) {
	s.mu.Lock()
	defer s.mu.Unlock() // 外层入口负责本次加锁的释放
	s.saveLocked(key, value)
}

func (s *Store) saveLocked(key, value string) {
	s.mu.Lock() // 错误：这里再次请求同一把仍未释放的锁
	defer s.mu.Unlock()
	s.items[key] = value
}

这里的 saveLocked 仍然拿锁，外层却要等它返回后才能执行延迟释放。调用链中没有另一个 goroutine 能替当前调用释放这把锁，所以等待永远不会结束。官方文档还特别说明，锁并不归属于某一个 goroutine，但这不代表可以让嵌套函数随意接管解锁责任；每次加锁都必须有明确且成对的释放边界。

先把 Lock 与 Unlock 的责任收敛到一层

最容易维护的规则是：公开方法或明确标注的带锁入口负责 Lock 和 Unlock；内部核心函数默认调用方已经持锁，函数名用 Locked 或注释把前置条件写出来。这样排查时只需要看入口，而不是猜每个方法是否会再次加锁。

func (s *Store) Save(key, value string) {
	s.mu.Lock()
	defer s.mu.Unlock() // 只有这一层拥有释放责任
	s.saveLocked(key, value)
}

// saveLocked 要求调用方已经持有 s.mu。
func (s *Store) saveLocked(key, value string) {
	s.items[key] = value // 这里只访问已被保护的共享状态
}

如果内部函数可能被多个入口调用，就不要只依赖命名。可以把带锁入口和无锁核心放在同一文件，并在注释中说明“调用方必须持有哪一把锁”。重点不是让锁越少越好，而是让锁的生命周期在一个可读的范围内闭合。

正确拆分：带锁入口 + 无锁核心

当临界区里还混着格式化、日志、回调或外部调用时，直接把所有代码包在锁里会让其他 goroutine 长时间等待。更稳妥的拆法是：锁内只读取或更新共享状态，必要时复制一份快照；解锁后再执行不需要共享锁的工作。

func (s *Store) SaveAndNotify(key, value string, notify func(string)) {
	s.mu.Lock()
	s.items[key] = value
	snapshot := s.items[key] // 在锁内取得后续所需的稳定值
	s.mu.Unlock()             // 先结束共享状态的保护范围

	if notify != nil {
		notify(snapshot) // 回调放在锁外，避免回调再次进入 Store
	}
}

这里的快照必须是不会在解锁后继续被并发修改的值；如果是切片、映射或指针，应该复制需要的内容，而不是只复制引用。若回调确实需要修改共享状态，应重新设计接口，让回调接收数据而不是拿着内部对象再回到同一把锁。

排查完成后的责任清单

可以用下面四个问题收尾：第一，调用栈里是否出现同一接收者的第二次 Lock；第二，当前方法是否清楚写出“调用方已持锁”还是“本方法自行加锁”；第三，defer Unlock 是否紧跟在获取锁之后；第四，日志、回调、网络和文件操作是否已经移出临界区。

不要用 TryLock 把必需的同步变成偶发失败，也不要仅靠换成另一种锁来掩盖调用层级混乱。Go 官方对 TryLock 的提示也是：正确用途存在，但使用它往往说明锁设计还需要重新审视。

小结：嵌套调用的核心修复不是“多解锁一次”，而是让一层函数拥有完整的锁生命周期，再通过无锁核心和明确快照缩小临界区。这样既能消除同一 goroutine 的自阻塞，也让后续代码审查有清晰的责任边界。

常见问题

问：把内层的 Unlock 删除就一定安全吗？
答：只有在内层函数被明确约定为“调用方已持锁”并且所有调用路径都满足这个前置条件时才安全；否则应拆分带锁入口与无锁核心，而不是靠删除一行碰运气。

问：为什么不直接改成 RWMutex？
答：本问题是同一把锁的嵌套加锁，换锁类型不会自动修复调用责任；先把临界区和调用层级整理清楚，再依据读写比例讨论其它同步方案。

官方文档：https://pkg.go.dev/sync