1.sync.Mutex
在Go语言的sync包中，sync.Mutex是不可重入的互斥锁。这与Java可重入锁改变不同。
也就是说,当一个goroutine获得了Mutex的锁后，在释放锁之前它不能再次获取同一个Mutex。
2.sync.RWMutex
写锁重入导致死锁：
var lock sync.RWMutex
func test1() {
lock.Lock()
lock.Lock()
lock.Unlock()
lock.Unlock()
}
func main() {
//写锁重入死锁
test1()
}
结果：fatal error: all goroutines are asleep - deadlock!
读锁写锁重入死锁
var lock sync.RWMutex
func test2() {
lock.RLock()
lock.Lock()
lock.Unlock()
lock.RUnlock()
}
func main() {
//读写锁重入死锁
test2()
}
输出结果：
fatal error: all goroutines are asleep - deadlock!
写锁对重入的读锁的影响，可能会出现死锁，当有写锁申请时会阻塞掉新的读锁申请，也就是说当同时有读锁和写锁同时申请获得同一个锁对象时，优先写锁获取（即写锁优先）。
var lock sync.RWMutex
func main() {
go func() {
ReadRLock()
}()
//sleep 1秒后，ReadRLock正处于第二次获取锁的时机和WriteLock同时也在等ReadLock释放第一次获取的读锁，
//二者竞争，写锁优先，导致ReadLock第二次获取读锁失败
time.Sleep(time.Second)
WriteLock()
}
func ReadRLock() {
lock.RLock()
defer lock.RUnlock()
time.Sleep(time.Second * 2)
lock.RLock()
defer lock.RUnlock()
}
func WriteLock() {
lock.Lock()
defer lock.Unlock()
}
输出：fatal error: all goroutines are asleep - deadlock!
3.channel相关的死锁
同一个协程读写死锁：
func main() {
ch := make(chan int, 0)
ch <- 3
result := <-ch
fmt.Println(result)
}
输出：fatal error: all goroutines are asleep - deadlock!
缓存为0 channel读取在后面导致死锁
一句话总结：无缓存的channel只有在receiver准备好后send才被执行。
func main() {
ch := make(chan int, 0)
ch <- 8
go func() {
result := <-ch
fmt.Println(result)
}()
}
输出：fatal error: all goroutines are asleep - deadlock!
读取协程放在前面就不会死锁：
func main() {
ch := make(chan int, 0)
go func() {
result := <-ch
fmt.Println(result)
}()
ch <- 8
}
输出：8
chan读写时，相互要求对方先读或者先写
func main() {
teacher := make(chan string, 0)
student := make(chan string, 0)
go func() {
select {
case <-teacher:
student <- "yes,do over"
}
}()
select {
case <-student:
teacher <- "HomeWork do over?"
}
}
输出：fatal error: all goroutines are asleep - deadlock!
4.死锁发生的条件
不可剥夺。线程已经获得的资源，在未使用完之前，不能被其他线程剥夺，只能在使用完后自己释放。
请求保持。线程 T1 保持了一个资源 R1 占用，但是又提出另外一个资源 R2 请求，此时，资源 R2 被线程 T2 占用，于是 T1 线程必须等待，但又对自己保持的 R1 资源不释放。
循环等待。死锁发生时，必然存在一个 “进程-资源环形链”，例如 进程p0 等待 p1 占用资源，p1 等待 p2 占用的资源， p2 等待 p0 占用的资源，形成了一个环形链。
互斥。线程对资源访问是排斥的，如果一个线程占用了资源，那么其他线程必须处于等待状态，直到资源释放。
