Go语言互斥锁的诡异错误及解决方案
Go语言的并发特性强大，但使用互斥锁(mutex)时，稍有不慎就会遇到棘手的bug。本文分析一个典型的“fatal error: sync: unlock of unlocked mutex”错误，并提供解决方案。
问题描述
在前端触发菜单点击事件时，使用如下代码对共享资源加锁解锁：
fmt.Println("1. 开始加锁:", key)s.Lock()fmt.Println("2. 加锁完成:", key)defer fmt.Println("4. 开始解锁:", key)defer s.Unlock()defer fmt.Println("5. 解锁完成:", key)
初始几次操作正常，但频繁点击或刷新页面后，便可能出现“fatal error: sync: unlock of unlocked mutex”错误。日志显示：前几次操作正常，之后突然报错。
问题分析
为了深入分析，提供更具体的代码示例：
立即学习“go语言免费学习笔记（深入）”；
package categoryimport ( "sync")type Sync struct { name string age int mu sync.Mutex}var ( cache *Sync cacheContainer Sync)// gettree 查询列表 (错误示例)func (s *Sync) gettree() *Sync { s.mu.Lock() defer s.mu.Unlock() cache = &Sync{ name: "abc", age: 18, } // 此处错误：cachecontainer指向cache的副本，并非cache本身 cacheContainer = *cache return &cacheContainer}// gettree2 查询列表 (正确示例)func (s *Sync) gettree2() *Sync { s.mu.Lock() defer s.mu.Unlock() cache = &Sync{ name: "abc", age: 18, } return cache}
gettree 函数多次调用后出错，而 gettree2 正常。
问题根源
关键在于 cacheContainer 的赋值。cacheContainer = *cache 创建了 cache 的一个副本，而非引用。 gettree 函数返回的是这个副本的地址。当多个 goroutine 同时调用 gettree，每个 goroutine 都持有不同副本的地址，并尝试对同一个 mutex (s.mu) 解锁，但实际上只有原始的 s.mu 被锁住，导致其他 goroutine 解锁失败，从而引发错误。
解决方案
避免此错误的关键在于正确管理 Sync 对象的生命周期和引用。 不要返回 cache 的副本，而是直接返回 cache 本身：
// gettree 修正后的版本func (s *Sync) gettree() *Sync { s.mu.Lock() defer s.mu.Unlock() cache = &Sync{ name: "abc", age: 18, } return cache}
或者，如果需要避免直接修改全局变量 cache，可以考虑使用返回值：
func gettree(s *Sync) *Sync { s.mu.Lock() defer s.mu.Unlock() newCache := &Sync{name: "abc", age: 18} return newCache}
通过以上修改，确保只有一个 Sync 对象及其对应的 mutex 被正确加锁和解锁，避免了并发访问和解锁冲突。 总而言之，要谨慎处理指针和值传递，确保所有goroutine操作的是同一个互斥锁。
以上就是Go语言中互斥锁的奇葩BUG如何解决？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1385925.html
微信扫一扫 
支付宝扫一扫 
