Go语言sync.RWMutex疑难解答：读写锁的并发行为
问题描述：
以下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 的行为符合其设计目的，并非错误。理解其内部锁机制对于编写高效且正确的并发程序至关重要。 需要根据实际应用场景选择合适的并发控制策略。
