Go語言死鎖與goroutine泄露問題的解決

Posted on by

什麼時候會導致死鎖

在計算機組成原理裡說過 死鎖有三個必要條件他們分別是 循環等待、資源共享、非搶占式，在並發中出現通道死鎖隻有兩種情況：

  • 數據要發送，但是沒有人接收
  • 數據要接收，但是沒有人發送

發送單個值時的死鎖

牢記這兩點問題就很清晰瞭，復習下之前的例子，會死鎖 

a := make(chan int)
a <- 1   //將數據寫入channel
z := <-a //從channel中讀取數據
  • 有且隻有一個協程時，無緩沖的通道
  • 先發送會阻塞在發送，先接收會阻塞在接收處。
  • 發送操作在接收者準備好之前是阻塞的，接收操作在發送之前是阻塞的，

解決辦法就是改為緩沖通道，或者使用協程配對

解決方法一,協程配對，先發送還是先接收無所謂隻要配對就好 

chanInt := make(chan int)
go func() {
    chanInt <- 1
}()

res := <-chanInt

解決方法二，緩沖通道 

chanInt := make(chan int,1)
chanInt <- 2
res := <-chanInt
  • 緩沖通道內部的消息數量用len()函數可以測試出來
  • 緩沖通道的容量可以用cap()測試出來
  • 在滿足cap>len時候，因為沒有滿，發送不會阻塞
  • 在len>0時，因為不為空，所以接收不會阻塞

使用緩沖通道可以讓生產者和消費者減少阻塞的可能性，對異步操作更友好，不用等待對方準備，但是容量不應設置過大，不然會占用較多內存。

多個值發送的死鎖

配對可以讓死鎖消失，但發送多個值的時候又無法配對瞭，又會死鎖 

func multipleDeathLock() {
 chanInt := make(chan int)
 defer close(chanInt)
    go func() {
  res := <-chanInt
  fmt.Println(res)
 }()
 chanInt <- 1
 chanInt <- 1
}

不出所料死鎖瞭 

fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan send]:
main.multipleDeathLock()

在工作中隻有通知信號是一對一的情況，通知一次以後就不再使用瞭，其他這種要求多次讀寫配對的情況根本不會存在。

解決多值發送死鎖

更常見的是用循環來不斷接收值，接受一個處理一個，如下： 

func multipleLoop() {
 chanInt := make(chan int)
 defer close(chanInt)
 go func() {
  for {
   //不使用ok會goroutine泄漏
   //res := <-chanInt
   res,ok := <-chanInt
   if !ok {
                 break
            }
   fmt.Println(res)
  }
 }()
 chanInt <- 1
 chanInt <- 1
}

輸出：

1
1

  • 給通道的接收加上二值，ok 代表通道是否正常，如果是關閉則為false值
  • 可以刪掉那段邏輯試試，會輸出1 2 0 0 0這樣的數列，因為關閉是需要時間的，而循環接收關閉的通道拿到的是0
  • 關於goroutine泄漏稍後會講到

應該先發送還是先接收

假如我們調換一下位置，把接收放外面，寫入放裡面會發生什麼 

func multipleDeathLock2() {
 chanInt := make(chan int)
 defer close(chanInt)
 go func() {
  chanInt <- 1
  chanInt <- 2
 }()
 for {
  res, ok := <-chanInt
  if !ok {
   break
  }
  fmt.Println(res)
 }
}

輸出死鎖
1
2
fatal error: all goroutines are asleep – deadlock!

goroutine 1 [chan receive]:
main.multipleDeathLock2()

  • 出現上面的結果是因為for循環一直在獲取通道中的值，但是在讀取完1 2後，通道中沒有新的值傳入，這樣接收者就阻塞瞭。
  • 為什麼先接收再發送可以，因為發送提前結束後會觸發函數的defer自動關閉通道
  • 所以我們應該總是先接收後發送，並由發送端來關閉

goroutine 泄漏

goroutine 終止的場景有三個：

  • 當一個 goroutine 完成瞭它的工作
  • 由於發生瞭沒有處理的錯誤
  • 有其他的協程告訴它終止

當三個條件都沒有滿足，goroutine 就會一直運行下去 

func goroutineLeak() {
 chanInt := make(chan int)
 defer close(chanInt)
 go func() {
  for {
            res := <-chanInt
   //res,ok := <-chanInt
   //if !ok {
            //     break
            //}
   fmt.Println(res)
  }
 }()
 chanInt <- 1
 chanInt <- 1
}

上面的goroutineLeak()函數結束後觸發defer close(chanInt)關閉瞭通道
但是匿名函數中goroutine並沒有關閉，而是一直在循環取值，並且取到是的關閉後的通道值（這裡是int的默認值 0）
goroutine會永遠運行下去，如果以後再次使用又會出現新的泄漏！導致內存、cpu占用越來越多

輸出，如果程序不停止就會一直輸出0
1
1
0
0
0
…

假如不關閉且外部沒有寫入值，那接收處就會永遠阻塞在那裡，連輸出都不會有 

func goroutineLeakNoClosed() {
 chanInt := make(chan int)
 go func() {
  for {
            res := <-chanInt
   fmt.Println(res)
  }
 }()
}
  • 無任何輸出的阻塞
  • 換成寫入也是一樣的
  • 如果是有緩沖的通道，換成已滿的通道寫沒有讀；或者換成向空的通道讀沒有寫也是同樣的情況
  • 除瞭阻塞，goroutine進入死循環也是泄露的原因

如何發現泄露

  • 使用 golang 自帶的pprof監控工具，可以發現內存上漲情況，這個後續會講
  • 還可以監控進程的內存使用情況，比如prometheus提供的process-exporter
  • 如果你有內存泄露/goroutine 泄露代碼掃描的工具，歡迎留言，感恩！

小結

今天我們學習瞭一些細節，但是相當重要的知識點，也是未來面試高頻問題哦！

  • 如果是信號通知，應該保證一一對應，不然會死鎖
  • 除瞭信號通知外，通常我們使用循環處理通道，在工作中不斷的處理數據
  • 應該總是先接收後發送，並由發送端來關閉，不然容易死鎖或者泄露
  • 在接收處，應該對通道是否關閉做好判斷，已關閉應該退出接收，不然會泄露
  • 小心 goroutine 泄漏，應該在通道關閉的時候及時檢查通道並退出
  • 除瞭阻塞，goroutine進入死循環也是泄露的原因

本節源碼地址  

到此這篇關於Go語言死鎖與goroutine泄露問題談論的文章就介紹到這瞭,更多相關Go語言死鎖與goroutine泄露內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：