golang中關於死鎖的思考與學習

若-飞發表於2024-09-09

1、Golang中死鎖的觸發條件

1.1 書上關於死鎖的四個必要條件的講解

發生死鎖時,執行緒永遠不能完成,系統資源被阻礙使用,以致於阻止了其他作業開始執行。在討論處理死鎖問題的各種方法之前,我們首先深入討論一下死鎖特點。

必要條件:

如果在一個系統中以下四個條件同時成立,那麼就能引起死鎖:

  1. 互斥:至少有一個資源必須處於非共享模式,即一次只有一個執行緒可使用。如果另一執行緒申請該資源,那麼申請執行緒應等到該資源釋放為止。
  2. 佔有並等待:—個執行緒應占有至少一個資源,並等待另一個資源,而該資源為其他執行緒所佔有。
  3. 非搶佔:資源不能被搶佔,即資源只能被執行緒在完成任務後自願釋放。
  4. 迴圈等待:有一組等待執行緒 {P0,P1,…,Pn},P0 等待的資源為 P1 佔有,P1 等待的資源為 P2 佔有,……,Pn-1 等待的資源為 Pn 佔有,Pn 等待的資源為 P0 佔有。

我們強調所有四個條件必須同時成立才會出現死鎖。迴圈等待條件意味著佔有並等待條件,這樣四個條件並不完全獨立。

圖示例:

golang中關於死鎖的思考與學習

執行緒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異常情況總結:

golang中關於死鎖的思考與學習

注意:對已經關閉的channel再次關閉,也會發生panic

相關文章