问题描述:
以下Go代码意图模拟一个场景:两个读操作goroutine和一个写操作goroutine并发执行。然而,实际运行结果常常显示第二个读操作goroutine必须等待第一个读操作goroutine完成后才能开始执行。
package main import ( "fmt" "sync" "time" ) type Stu struct { Name string mu *sync.RWMutex } func read1(stu *Stu) { stu.mu.RLock() stu.Name = "aa" //此处存在问题,读锁下不应该修改数据 fmt.Println("read1 start") time.Sleep(time.Second * 5) stu.mu.RUnlock() fmt.Println("read1 end") } func read2(stu *Stu) { stu.mu.RLock() fmt.Println("read2 start") time.Sleep(time.Second * 5) stu.mu.RUnlock() fmt.Println("read2 end") } func write1(stu *Stu) { stu.mu.Lock() fmt.Println("write1 start") time.Sleep(time.Second * 5) stu.mu.Unlock() fmt.Println("write1 end") } func main() { stu := &Stu{mu: &sync.RWMutex{}} go read1(stu) go read2(stu) go write1(stu) time.Sleep(time.Second * 40) }
问题分析:
关键问题在于sync.RWMutex的内部锁机制。当一个写操作请求锁时,所有后续的读操作和写操作都会被阻塞,直到写操作释放锁。这并非bug,而是RWMutex的设计特性,旨在避免死锁和数据竞争。 此外,read1 函数中 stu.Name = "aa" 的操作是不正确的,因为在读锁 RLock 下修改数据会造成数据竞争。
立即学习“go语言免费学习笔记(深入)”;
因此,即使读操作之间没有直接的依赖关系,由于写操作的存在,读操作的执行顺序可能会受到影响。
解决方案:
如果需要允许多个读操作并发执行,并且写操作不频繁,sync.RWMutex 是合适的。但如果写操作频繁,则应考虑使用其他并发控制机制,例如通道或其他更精细的锁机制,以优化并发性能。 更重要的是,确保在读锁下不修改共享数据。
总结:
sync.RWMutex 的行为符合其设计目的,并非错误。理解其内部锁机制对于编写高效且正确的并发程序至关重要。 需要根据实际应用场景选择合适的并发控制策略。
以上就是Go语言RWMutex并发问题:为什么多个读操作会阻塞在写操作之后?的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号