如何在Golang中实现可重入锁Recursive Mutex Go语言GoroutineID获取-Golang-PHP中文网

go不支持递归锁，因sync.mutex非重入且goroutine id不可靠；应重构逻辑、用sync.once或rwmutex替代；需调试时优先用-race和mutexprofile而非记录goroutine id。

如何在golang中实现可重入锁recursive mutex go语言goroutineid获取

Go 里没有原生 `RecursiveMutex`，别硬套 pthread 思路

Go 的 sync.Mutex 明确不支持重入——同一个 goroutine 连续两次 Lock() 就会死锁。这不是 bug，是设计选择：Go 鼓励用更清晰的控制流（比如提前 return、拆函数）替代“我在自己代码里再进一次锁”这种隐式依赖。

强行模拟递归锁，容易掩盖设计问题，还可能在 defer 场景下漏 unlock。真需要“可重入语义”，优先考虑：

把临界区逻辑抽成无锁函数，由上层统一加锁调用
用 sync.Once 替代“首次初始化才加锁”的场景
改用 sync.RWMutex + 状态标记，避免嵌套写锁

想记录谁持有了锁？别依赖 goroutine ID

Go 运行时**不提供稳定、可用的 goroutine ID 获取方式**。runtime.Stack() 解析出来的数字只是 debug 信息，不同版本行为不一致；goroutine id 也不是公开 API，任何第三方包（比如 goid）都是靠解析 panic 或 stack trace 字符串实现的，脆弱且开销大。

如果你是为了调试锁竞争或排查死锁：

用 go run -race 检测数据竞争，比记 goroutine ID 有用得多
启用 GODEBUG=mutexprofile=1 后跑程序，再用 go tool pprof 分析锁持有热点
在 Lock() / Unlock() 前后打日志，用 runtime.Caller(1) 记位置，比记 goroutine ID 更可靠

非要实现带持有者检查的互斥锁？用 `sync.Map` + `unsafe.Pointer` 不如用 `map[uintptr]struct{}`

有人用 goroutine id 作 key 存 map 来判断是否已持有锁，但 id 不稳定，map 本身又需额外锁保护，反而引入新竞争点。更务实的做法是：用 uintptr 记录当前持有者的栈帧地址（比如 &someLocalVar），配合 sync.Mutex 自身做外层保护：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

type RecursiveMutex struct {
    mu      sync.Mutex
    owner   uintptr
    counter int
}
<p>func (m *RecursiveMutex) Lock() {
me := getGoroutinePtr() // 用 runtime.Caller(0) 取一个稳定地址
m.mu.Lock()
if m.owner == me {
m.counter++
m.mu.Unlock()
return
}
m.owner = me
m.counter = 1
}</p><p>func (m *RecursiveMutex) Unlock() {
m.mu.Lock()
m.counter--
if m.counter == 0 {
m.owner = 0
}
m.mu.Unlock()
}
</p>

注意：getGoroutinePtr() 不能返回 goroutine id，只能取当前栈上某个变量地址——它在单次调用中稳定，但跨 goroutine 不可比，所以只适合“本 goroutine 是否已持锁”这种简单判断。