什么時候會導致死鎖

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

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

發送單個值時的死鎖

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

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泄露內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持腳本之家！