golang如何使用sync.Mutex互斥锁_golang sync.Mutex互斥锁使用方法-Golang-PHP中文网

sync.mutex是零值可用的值类型，声明即初始化；而*sync.mutex初始为nil，未初始化就调用会panic。

golang如何使用sync.mutex互斥锁_golang sync.mutex互斥锁使用方法

因为 sync.Mutex 是零值可用的值类型——内部没有指针、不依赖系统资源，声明即初始化。你写 mu sync.Mutex，它默认就是“未锁定”状态，随时能调 Lock()。

但如果你写成 mu *sync.Mutex，字段初始值是 nil；没手动赋值 &sync.Mutex{} 就调 mu.Lock()，运行时立刻报错：invalid memory address or nil pointer dereference。

✅ 正确：结构体字段直接声明为 mu sync.Mutex
❌ 错误：声明为 mu *sync.Mutex 却没初始化
⚠️ 特殊情况必须用指针（比如从外部传入锁）？务必检查非 nil：if mu == nil { panic("mutex not initialized") }

defer 只在函数返回时执行，一旦临界区逻辑变复杂，就容易失控。最典型的是：提前 return 但忘了放锁，或者 panic 发生在 defer 注册之后、Unlock() 执行之前。

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

❌ 错误模式：mu.Lock(); if err != nil { return }; defer mu.Unlock() → err 非空时锁永远不释放
❌ 更危险：mu.Lock(); json.Unmarshal(data, &v); defer mu.Unlock() → Unmarshal panic 会导致锁卡死
✅ 推荐做法：显式配对，尤其在多分支或可能 panic 的场景：mu.Lock(); defer func() { mu.Unlock() }()（配合 recover 太重，不推荐）
✅ 更干净的解法：把临界区抽成小函数，再用 defer，比如 updateValue(func() { c.value++ })

因为 sync.Mutex 不可复制——它内部有未导出字段（如 state int32），Go 编译器会静默允许赋值，但运行时一旦检测到复制行为（比如结构体赋值、作为 map value、传值参数），就会 panic：sync.Mutex is copied。

❌ 错误示例：c := Counter{}; go c.Inc() → c 被复制，每个 goroutine 操作的是自己副本里的 mu，完全没互斥效果
❌ 错误示例：m := make(map[string]Counter); m["a"] = c → map 赋值触发复制，panic
✅ 正确姿势：始终用指针：var c = &Counter{}，方法接收器必须是 *Counter，map value 类型设为 *Counter
✅ 上线前必跑：go vet -copylocks ./，它能捕获 80% 这类低级错误

不该。RWMutex 不是银弹，它只在读操作远多于写操作（比如读:写 > 4:1）、且读逻辑极轻量时才有明显收益；否则，它的额外状态管理开销反而拖慢性能。

✅ 适合 RWMutex：config.Get()（纯读字段） 被调用上千次/秒，config.Reload() 每分钟最多一次
❌ 不适合 RWMutex：cache.HitCount() 和 cache.MissCount() 频繁交替调用；或读操作本身含 DB 查询、JSON 解析等耗时逻辑
⚠️ 致命陷阱：不能在持有 RLock() 的 goroutine 中调 Lock()，否则死锁 —— 必须先 RUnlock() 再 Lock()
? 判断依据：先用 -race 跑压测，对比 go tool pprof 中锁等待时间，别凭感觉换