Golang并发操作中常见的读写锁详析 Golang并发操作中常见的读写锁

互斥锁简单粗暴，谁拿到谁操作。今天给大家介绍一下读写锁，读写锁比互斥锁略微复杂一些，不过我相信我们今天能够把他拿下!
【Golang并发操作中常见的读写锁详析】golang读写锁，其特征在于

读锁：可以同时进行多个协程读操作，不允许写操作
写锁：只允许同时有一个协程进行写操作，不允许其他写操作和读操作

读写锁有两种模式。没错！一种是读模式，一种是写模式。当他为写模式的话，作用和互斥锁差不多，只允许有一个协程抢到这把锁，其他协程乖乖排队。但是读模式就不一样了，他允许你多个协程读，但是不能写。总结起来就是：

仅读模式：多协程可读不可写
仅写模式：单协程可写不可读

在32位的操作系统中，针对int64类型的值的读和写操作都不可能仅由一个CPU指令来完成。如若一个写操作刚刚执行完第一个指令，就去进行另一个读的协程，这样就会读到一个错误的数据。
下面看个例子吧：
先看主函数：

func main() {for i:=0; i<5; i++{wg06.Add(1)go write(i)?wg06.Add(1)go read(i)}wg06.Wait()}

每次开辟两条协程，一条协程执行写函数，另一条执行读函数。然后放入等待组。共开辟五次。
在来看一看写函数

func write(i int){//锁定为仅写模式，其他协程被阻塞rwm.Lock()?fmt.Println(i,"writing...")<- time.After(10*time.Second)fmt.Println("write over!")?rwm.Unlock()//解锁仅写模式wg06.Done()}

这个Lock()就是执行读写锁的写模式，当这个模式进行时，只有这条协程能写，其他协程都被阻塞。Unlock()就是解锁这个仅锁模式，等待组中的其他协程不再被阻塞。
再看一看读模式：

func read(i int){rwm.RLock()?fmt.Println(i,"reading...")<-time.After(10 * time.Second)fmt.Println(i,"read over!")?rwm.RUnlock()wg06.Done()}

RLock()就是执行读写锁的读模式，执行这个模式其他协程也能读，但是都不能写。
如果程序运行，写协程先抢到锁，所有协程就不能读，只有这条写协程能写，其他人都等着。如果是读协程抢到锁，所以写协程就不可能了，但是读协程仍然可以抢。
现在你知道我们应该什么时候使用读写锁了吗？
在并发进行读写操作时，当读的次数远远超过写的次数的情况下，应该使用读写锁来进行读写并发操作。
Golang读写锁底层原理

在加读锁和写锁的工程中都使用atomic.AddInt32来进行递增，而该指令在底层是会通过LOCK来进行CPU总线加锁的，因此多个CPU同时执行readerCount其实只会有一个成功，从这上面看其实是写锁与读锁之间是相对公平的，谁先达到谁先被CPU调度执行，进行LOCK锁cache line成功，谁就加成功锁

底层实现的CPU指令

底层的2条指令，通过LOCK指令配合CPU的MESI协议，实现可见性和内存屏障，同时通过XADDL则用来保证原子性，从而解决可见性与原子性问题

// atomic/asm_amd64.s TEXT runtime∕internal∕atomic·Xadd(SB)LOCKXADDLAX, 0(BX)

可见性与内存屏障、原子性，其中可见性通常是指在cpu多级缓存下如何保证缓存的一致性，即在一个CPU上修改了了某个数据在其他的CPU上不会继续读取旧的数据，内存屏障通常是为了CPU为了提高流水线性能，而对指令进行重排序而来，而原子性则是指的执行某个操作的过程的不可分割
总结
到此这篇关于Golang并发操作中常见读写锁的文章就介绍到这了,更多相关Golang并发读写锁内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！