设备上哪个网站做外贸推广ai怎么做网站用海报
1.Mutex
互斥锁是并发程序中对共享资源进行访问控制的主要手段，对此Go语言提供了Mutex，对外暴露Lock()和Unlock两个方法，分别用于加锁和解锁。
1.1 Mutex的数据结构
源码如下：
type Mutex struct{state int32//代表互斥锁的状态sema uint32//表示信号量，协程阻塞等待该信号量。解锁的协程释放信号量从而唤醒等待信号量的协程
}
state表面上看起来是32位的整型变量，实际上内部分成了4部分。
- Locked：表示该Mutex是否已被锁定，0表示没有锁定，1表示已被锁定
- Woken：表示是否有协程已被唤醒，0表示没有协程唤醒，1表示已有协程唤醒，正在加锁过程中
- Starving：表示该Mutex是否处于饥饿状态，0表示没有饥饿，1表示饥饿状态，说明有协程阻塞了超过1ms
- Waiter：表示阻塞等待锁的协程个数，协程解锁时根据此值来判断是否需要释放信号量
抢锁实际上是抢给Locked赋值的权利，抢不到就阻塞等待信号量sema，一旦持有锁的协程解锁，等待的协程就会依次被唤醒。
1.2 加/解锁过程
- 简单加锁
- locked置为1即可
- 加锁被阻塞
- waiter+1
- 简单解锁
- locked置为0即可
- 解锁并唤醒协程
- locked置为0
- 查看waiter>0
- 释放一个信号量，唤醒一个阻塞的协程
- 被唤醒的协程吧locked置为1
1.3 自旋过程
加锁时，如果当前Locked位为1，尝试加锁的协程不是马上转入阻塞，而是会持续地探测Locked位是否变为0，这个过程为自旋过程。
自旋时间很短，如果在自旋过程中发现锁已被释放，那么协程可以立即获取锁。此时即便有协程被唤醒也无法获取锁，只能再次阻塞（像极了被插队的情况）
1.3.1 什么是自旋
自旋对应于CPU的PAUSE指令，CPU对该指令什么也不做，相当于CPU空转，对于程序来说相当于”sleep“了一小段时间，时间很短，30个时针周期。不同于sleep，自旋不会将协程转换为睡眠状态。
1.3.2 自旋条件
加锁时程序会自动判断是否可以自旋，无限制的自旋会给CPU带来巨大压力，所以判断是否可以自旋就很重要了。
自旋必须满足以下所有的条件：
- 自旋次数要足够小，通常为4
- CPU核数要大于1，否则自旋没有意义
- 协程调度机制中的Processor数量要大于1
- 协程调度机制中的可运行队列必须为空，否则会延迟协程调用
自旋的条件很苛刻，总而言之就是不忙的时候才会启动自旋。
1.3.3 自旋的优势
自旋的优势就是更充分地利用CPU，尽量避免协程切换。经过短时间的自旋可以获得锁，就不必进入阻塞状态。
1.3.4 自旋的问题
如果自旋过程中获得锁，那么之前被阻塞的协程将无法获得锁。如果加锁的协程特别多，每次都通过自旋获得锁，那么之前被阻塞的进程将很难获得锁，从而进入了Starving状态。
1.4 Mutex模式
1.4.1 Normal模式
在该模式下，如果协程加锁不成功不会立即转入阻塞队列，而是先判断是否满足自旋状态，如果满足则会启动自旋过程，尝试加锁。
1.4.2 Starving模式（饥饿模式）
被唤醒的协程尝试加锁时发现已经被抢占了，只好再次阻塞，不过阻塞前会判断上一次阻塞距离这次阻塞的时长，如果超过1ms，则会将Mutex标记为Starving模式，然后阻塞。
在Starving模式下，不会启动自旋。
1.5 Woken状态
加锁的程序在自旋的过程中会把woken标记为1，用于通知解锁协程不需要释放信号量。
1.6 为什么重复解锁要触发panic
如果多次Unlock()，那么可能每次都释放一个信号量，这样会唤醒多个协程，多个协程被唤醒后会继续在Lock()的逻辑中抢锁，会增加Lock()实现的复杂度，也会引起不必要的协程切换。
1.7 编程Tips
- 使用defer避免死锁
- 加锁后立即使用defer对其解锁，可以有效避免死锁
- 加锁和解锁应该成对出现
- 加锁和解锁最好出现在同一层次的代码块中
2. RWMutex
读写互斥锁，在读取数据频率远远大于写数据频率的场景会有更好的性能。
需要解决的问题：
- 写锁阻塞写锁
- 写锁阻塞读锁
- 读锁阻塞写锁
- 读锁不阻塞读锁
2.1 读写锁的数据结构
2.1.1 数据结构
源码：
type RWMutex struct{w Mutex //用于控制多个写锁，获得写锁首先要获取该锁writerSem uint32 //写阻塞等待的信号量，最后一个读者释放锁时会释放信号量readerSem uint32 //读阻塞的协程等待的信号量，持有写锁的协程释放锁后会释放信号量readerCount int32 //记录读者个数readerWait int32 //记录写阻塞时读者个数
}
2.1.2 接口的定义
RWMutex提供了以下几个简单的接口：
- RLock()：读锁定
- 增加读操作计数，readerCount++
- 阻塞等待写操作结束（如果有）
- RUnlock()：解除读锁定
- 减少读操作计数，readerCount–
- 最后一个解除读锁定的协程唤醒等待写操作的协程（如果有）
- Lock()：写锁定
- 获取互斥锁
- 阻塞等待所有读操作结束
- Unlock()：解除写锁定
- 唤醒因读锁定而被阻塞的协程（如果有）
- 解除互斥锁
- TryLock()：以非阻塞方式尝试写锁定
- TryRLock()：以非阻塞方式尝试读锁定
2.2 场景分析
写操作需要等待读操作结束，写操作等待期间可能还有新的读操作持续到来。但在RWMutex中为什么写锁定不会被“饿死”？
- 因为写操作到来时，会把RWMutex.readerCount值拷贝到RWMutex.readerWait中，用于标记排在写操作前面的读者个数。
- 写操作结束后，会递减readerWait，这个值为0时唤醒写操作。