1：將兩個列表合併成一個字典 假設我們在 Python 中有兩個列表，我們希望將它們合併為字典形式，其中一個列表的項作為字典的鍵，另一個作為值。這是在用 Python 編寫代碼時經常遇到的一個非常常見的問題 但是為瞭解決這個問題，我們需要考慮幾個限制，比如兩個列表的大小，兩個列表中元素的類型，以及其 ...
1、Golang中死鎖的觸發條件
1.1 書上關於死鎖的四個必要條件的講解
發生死鎖時，線程永遠不能完成，系統資源被阻礙使用，以致於阻止了其他作業開始執行。在討論處理死鎖問題的各種方法之前，我們首先深入討論一下死鎖特點。
必要條件：
如果在一個系統中以下四個條件同時成立，那麼就能引起死鎖：
- 互斥：至少有一個資源必須處於非共用模式，即一次只有一個線程可使用。如果另一線程申請該資源，那麼申請線程應等到該資源釋放為止。
- 占有並等待：—個線程應占有至少一個資源，並等待另一個資源，而該資源為其他線程所占有。
- 非搶占：資源不能被搶占，即資源只能被線程在完成任務後自願釋放。
- 迴圈等待：有一組等待線程 {P0，P1，…，Pn}，P0 等待的資源為 P1 占有，P1 等待的資源為 P2 占有，……，Pn-1 等待的資源為 Pn 占有，Pn 等待的資源為 P0 占有。
我們強調所有四個條件必須同時成立才會出現死鎖。迴圈等待條件意味著占有並等待條件，這樣四個條件並不完全獨立。
圖示例：
線程1、線程2都嘗試獲取對方未釋放的資源，從而會一直阻塞，導致死鎖發生。
1.2 Golang 死鎖的觸發條件
看完了書上關於死鎖的介紹，感覺挺清晰的，但是實際上到了使用或者看代碼時，自己去判斷是否會發生死鎖卻是模模糊糊的，難以準確判斷出來。所以特意去網上找了些資料學習，特此記錄。
golang中死鎖的觸發條件：
死鎖是當 Goroutine 被阻塞而無法解除阻塞時產生的一種狀態。註意：for 死迴圈不能算在這裡，雖然空for迴圈是實現了阻塞的效果，但是實際上goroutine是處於運行狀態的。
1.3 golang 中阻塞的場景
1.3.1 sync.Mutex、sync.RWMutex
golang中的鎖是不可重入鎖，對已經上了鎖的寫鎖，再次申請鎖是會報死鎖。上了讀鎖的鎖，再次申請寫鎖會報死鎖，而申請讀鎖不會報錯。
寫寫衝突，讀寫衝突，讀讀不衝突。
func main() {
var lock sync.Mutex
lock.Lock()
lock.Lock()
}
//報死鎖錯誤
func main() {
var lock sync.RWMutex
lock.RLock()
lock.Lock()
}
//報死鎖錯誤
func main() {
var lock sync.RWMutex
lock.RLock()
lock.RLock()
}
//正常執行
1.3.2 sync.WaitGroup
一個不會減少的 WaitGroup 會永久阻塞。
func main() {
var wg sync.WaitGroup
wg.Add(1)
wg.Wait()
//報死鎖錯誤
}
1.3.3 空 select
空 select 會一直阻塞。
package main
func main() {
select {
}
}
//報死鎖錯誤
1.3.4 channel
為 nil 的channel 發送、接受數據都會阻塞。
func main() {
var ch chan struct{}
ch <- struct{}{}
}
//報死鎖錯誤
無緩衝的channel 發送、接受數據都會阻塞。
func main() {
ch := make(chan struct{})
<- ch
}
//報死鎖錯誤
channel 緩衝區滿了的，繼續發送數據會阻塞。
2、死鎖案例講解
2.1 案例一：空 select{}
package main
func main() {
select {
}
}
以上面為例子，select 語句會 造成 當前 goroutine 阻塞，但是卻無法解除阻塞，所以會導致死鎖。
2.2 案例二：從無緩衝的channel接受、發送數據
func main() {
ch := make(chan struct{})
//ch <- struct{}{} //發送
<- ch //接受
fmt.Println("main over!")
}
發生原因：
上面創建了一個 名為：ch 的channel，沒有緩衝空間。當向無緩存空間的channel 發送或者接受數據時，都會阻塞，但是卻無法解除阻塞，所以會導致死鎖。
解決方案：邊接受邊讀取
package main
// 方式1
func recv(c chan int) {
ret := <-c
fmt.Println("接收成功", ret)
}
func main() {
ch := make(chan int)
go recv(ch) // 啟用goroutine從通道接收值
ch <- 10
fmt.Println("發送成功")
}
// 方式2
func main() {
ch := make(chan int,1)
ch<-1
println(<-ch)
}
2.3 案例三：從空的channel中讀取數據
package main
import (
"fmt"
"time"
)
func request(index int,ch chan<- string) {
time.Sleep(time.Duration(index)*time.Second)
s := fmt.Sprintf("編號%d完成",index)
ch <- s
}
func main() {
ch := make(chan string, 10)
fmt.Println(ch,len(ch))
for i := 0; i < 4; i++ {
go request(i, ch)
}
for ret := range ch{ //當 ch 中沒有數據的時候，for range ch 會發生阻塞，但是無法解除阻塞，發生死鎖
fmt.Println(len(ch))
fmt.Println(ret)
}
}
發生原因：
當 ch 中沒有數據的時候，就是從空的channel中接受數據，for range ch 會發生阻塞，但是無法解除阻塞，發生死鎖。
解決辦法：當數據發送完了過後，close channel
package main
import (
"fmt"
"sync"
"time"
)
var wg sync.WaitGroup
func request(index int,ch chan<- string) {
time.Sleep(time.Duration(index)*time.Second)
s := fmt.Sprintf("編號%d完成",index)
ch <- s
wg.Done()
}
func main() {
ch := make(chan string, 10)
for i := 0; i < 4; i++ {
wg.Add(1)
go request(i, ch)
}
go func() {
wg.Wait()
close(ch)
}()
LOOP:
for {
select {
case i,ok := <-ch: // select會一直等待，直到某個case的通信操作完成時，就會執行case分支對應的語句
if !ok {
break LOOP
}
println(i)
default:
time.Sleep(time.Second)
fmt.Println("無數據")
}
}
}
2.4 案例四：給滿了的channel發送數據
func main() {
ch := make(chan struct{}, 3)
for i := 0; i < 4; i++ {
ch <- struct{}{}
}
}
發生原因：
ch 是一個帶緩衝的channel，但是只能緩衝三個struct，當channel滿了過後，繼續往channel發送數據會阻塞，但是無法解除阻塞，發生死鎖。
解決辦法：讀取channel中的數據
package main
import (
"fmt"
"sync"
"time"
)
var wg sync.WaitGroup
func main() {
ch := make(chan struct{}, 3)
go func() {
for {
select {
case i, ok := <- ch:
wg.Done()
fmt.Println(i)
if !ok {
return
}
}
}
}()
for i := 0; i < 4; i++ {
wg.Add(1)
ch <- struct{}{}
}
wg.Wait()
}
3、總結
最重要的是記住golang中死鎖的觸發條件：當 goroutine 發生阻塞，但是無法解除阻塞狀態時，就會發生死鎖。然後在使用或者閱讀代碼時，再根據具體情況進行分析。
channel異常情況總結：
註意：對已經關閉的channel再次關閉，也會發生panic。
以上就是我對死鎖的思考，有不對的地方懇請指出，謝謝。
