Go Mutex 死锁排查：一次忘记 Unlock 的请求卡住问题

Go 服务里最让人不舒服的问题之一，是请求没有报错，但一直卡住。日志没有明显异常，CPU 不高，接口也没有返回。这个时候如果代码里有 sync.Mutex，就要优先怀疑锁路径。

本文用一个最小例子还原问题：某个分支提前返回时忘记 Unlock，后续请求全部等在同一把锁上。我们按“看到现象 -> 提出猜测 -> 动手验证 -> 定位原因 -> 修复方案 -> 再次验证”的顺序排查。

问题现场：请求卡住但没有错误日志

假设有一个内存计数器，多个请求会同时更新它。为了避免并发读写冲突，我们给更新逻辑加了互斥锁。上线后出现一个现象：某次异常输入之后，后面的请求全部变慢，最后像是被挂住。

这种现场有几个特征：

• 请求没有快速失败，而是一直等待。
• 服务进程还在，CPU 和内存没有明显飙升。
• 重启服务后短暂恢复，但再次遇到异常输入又复现。

这不像普通 panic，也不像数据库慢查询。更像某个共享资源被占住后没有释放。

初步判断：先确认是不是锁等待

先不要直接改代码。我们先问两个问题：卡住前是否进入过临界区？进入之后有没有所有分支都释放锁？如果代码里有多个 return，尤其要检查提前返回的分支。

下面是一个有问题的写法。为了突出锁路径，示例把逻辑压缩在一个文件里。

package main

import (
    "fmt"
    "sync"
)

type Counter struct {
    mu    sync.Mutex
    value int
}

func (c *Counter) Add(delta int) error {
    c.mu.Lock()

    if delta 

这段代码的问题不在 sync.Mutex 本身，而是 delta 这个分支直接返回了。它拿到了锁，却没有释放锁。

动手验证：用最小代码复现卡住路径

把上面的代码保存为 main.go，然后运行：

go run main.go

你会看到第一行错误输出之后，程序停在第二次调用上。因为第一次调用返回错误时没有解锁，第二次调用进入 c.mu.Lock() 就会一直等待。

如果程序里有多个 goroutine，同类问题不一定马上报出死锁提示，而是表现为接口等待、队列积压或定时任务不再推进。最小复现的价值在于：它把“线上卡住”变成了“某条锁路径没有释放”的可验证结论。

定位原因：提前返回绕过了 Unlock

现在可以定位到根因：锁释放动作写在了正常分支后面，而不是和加锁动作绑定在一起。只要中间有错误分支、参数校验分支或业务拒绝分支，就可能绕过释放动作。

检查这类代码时，可以按下面的路径看：

• 找到所有 mu.Lock()。
• 确认同一个函数里是否存在多个 return。
• 确认每条返回路径前是否都会调用 mu.Unlock()。
• 优先修复“加锁后马上可能返回”的分支。

修复方案：用 defer 固定释放动作

Go 里更稳的写法，是加锁后立刻用 defer 绑定释放动作。这样函数从任何分支返回，都会先释放锁。

func (c *Counter) Add(delta int) error {
    c.mu.Lock()
    defer c.mu.Unlock()

    if delta 

修复后的关键变化只有一处：Unlock 不再依赖正常分支，而是和函数返回绑定。这样错误分支可以保留，临界区也能正确退出。

如果临界区很大，也可以先把参数校验放在加锁之前，减少锁持有时间：

func (c *Counter) Add(delta int) error {
    if delta 

这个版本更推荐：无效输入不需要进入临界区，锁的等待范围也更小。

验证结果和总结

重新运行：

go run main.go

预期结果是第一行返回参数错误，第二行正常结束，不再卡住。你也可以连续调用多次 Add，确认后续请求不会因为第一次错误输入而等待。

最后总结三条排查原则：

• 看到请求卡住但没有错误时，优先看共享资源等待，包括锁、通道、连接池。
• Lock 后如果函数里有多个返回路径，应优先使用 defer Unlock。
• 能在加锁前完成的参数校验，就不要放进临界区。

Mutex 本身不复杂，真正容易出错的是锁路径分散。把加锁、释放、返回分支放在同一张脑图里看，很多“偶发卡住”的问题就会变得清楚。