
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 category
import (
"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如何解决?的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号