利用dlv调试高并发下发生锁死锁的Go协程-Golang-PHP中文网

死锁定位需用dlv冻结现场：先goroutines -t列出全部协程，再goroutine bt查栈，重点看sync.(mutex).lock或sync.(rwmutex).rlock等阻塞锚点。

利用dlv调试高并发下发生锁死锁的go协程

dlv attach 无法看到 goroutine 阻塞在锁上？

直接 dlv attach 到运行中的 Go 进程，默认不会自动加载 runtime 符号，goroutine 栈可能只显示 runtime.futex 或 runtime.park，看不出具体在等哪个 sync.Mutex 或 sync.RWMutex。这不是 dlv 的 bug，而是 Go 编译器对锁的内联和优化导致符号信息丢失。

必须确保二进制是用 -gcflags="all=-l"（禁用内联）和 -ldflags="-s -w" 之外的完整调试信息编译的；线上环境若已部署，可临时用 dlv exec ./myapp --headless --api-version=2 --accept-multiclient 启动新实例并复现问题，避免 attach 失效。

怎么快速定位死锁时卡在哪几个 goroutine 和哪把锁？

进入 dlv 后，先执行 goroutines 查看全部协程状态，再用 goroutines -u（显示用户代码栈）过滤掉 runtime 内部 goroutine。重点关注状态为 chan receive、semacquire、sync.runtime_SemacquireMutex 的条目。

对疑似阻塞的 goroutine 执行 goroutine <id> bt</id>，看栈顶是否出现 sync.(*Mutex).Lock 或 sync.(*RWMutex).RLock
若栈里只有 runtime.semacquire1，说明锁已被其他 goroutine 持有，需交叉比对：找出所有持有该 mutex 的 goroutine（通常它正停在 defer mu.Unlock() 前、panic 中断、或被信号中断）
用 ps -T -p <pid></pid> 对照系统线程 ID 和 dlv 中 thread 输出，确认是否发生 OS 级线程饥饿（如大量 goroutine 争抢同一个 M）

为什么 pprof mutex profile 抓不到死锁现场？

go tool pprof http://localhost:6060/debug/pprof/mutex?debug=1 只统计「曾被阻塞过且已释放」的锁竞争，死锁一旦形成，阻塞 goroutine 永远不会释放锁，因此该 profile 是空的或数据陈旧。它适合查竞争热点，不适用于死锁诊断。

真正有用的组合是：

dlv 实时抓栈 + goroutines -s blocked（dlv 1.22+ 支持）快速筛选阻塞态
go tool trace 录制运行时事件，用 view trace 查看 goroutine 状态跃迁，定位最后执行的 lock/unlock 操作
在关键锁操作前后插入 log.Printf("mu.Lock at %s", debug.PrintStack())（仅调试期），配合 dlv trace 设置条件断点：trace sync.(*Mutex).Lock /path/to/file.go:123

在线上环境用 dlv 调试高并发服务要避开哪些坑？

dlv 本身会启动一个调试 server，占用额外内存与 goroutine，高并发下可能加剧调度压力甚至触发新的死锁。别在生产流量高峰期 attach。

务必限制 dlv 的最大连接数：--accept-multiclient --api-version=2 --headless --listen=:2345 --log --log-output=gdbwire,rpc，避免被未授权客户端连入
不要用 continue 让程序继续运行——dlv 在 headless 模式下 continue 后可能无法再次中断，建议用 ctrl+c 中断后手动 step 或 next 探查
如果服务用了 CGO_ENABLED=1，dlv 可能无法正确解析 C 栈帧，此时 bt 显示不全，需改用 runtime.Stack 手动 dump 到文件再分析