什么時候會導致死鎖

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

• 數(shù)據(jù)要發(fā)送，但是沒有人接收
• 數(shù)據(jù)要接收，但是沒有人發(fā)送

發(fā)送單個值時的死鎖

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

a := make(chan int)
a <- 1   //將數(shù)據(jù)寫入channel
z := <-a //從channel中讀取數(shù)據(jù)

• 有且只有一個協(xié)程時，無緩沖的通道
• 先發(fā)送會阻塞在發(fā)送，先接收會阻塞在接收處。
• 發(fā)送操作在接收者準備好之前是阻塞的，接收操作在發(fā)送之前是阻塞的，

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

解決方法一,協(xié)程配對，先發(fā)送還是先接收無所謂只要配對就好

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

res := <-chanInt

解決方法二，緩沖通道

chanInt := make(chan int,1)
chanInt <- 2
res := <-chanInt

• 緩沖通道內(nèi)部的消息數(shù)量用len()函數(shù)可以測試出來
• 緩沖通道的容量可以用cap()測試出來
• 在滿足cap>len時候，因為沒有滿，發(fā)送不會阻塞
• 在len>0時，因為不為空，所以接收不會阻塞

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

多個值發(fā)送的死鎖

配對可以讓死鎖消失，但發(fā)送多個值的時候又無法配對了，又會死鎖

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()

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

解決多值發(fā)送死鎖

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

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這樣的數(shù)列，因為關閉是需要時間的，而循環(huán)接收關閉的通道拿到的是0
• 關于goroutine泄漏稍后會講到

應該先發(fā)送還是先接收

假如我們調(diào)換一下位置，把接收放外面，寫入放里面會發(fā)生什么

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()

• 出現(xiàn)上面的結果是因為for循環(huán)一直在獲取通道中的值，但是在讀取完1 2后，通道中沒有新的值傳入，這樣接收者就阻塞了。
• 為什么先接收再發(fā)送可以，因為發(fā)送提前結束后會觸發(fā)函數(shù)的defer自動關閉通道
• 所以我們應該總是先接收后發(fā)送，并由發(fā)送端來關閉

goroutine 泄漏

goroutine 終止的場景有三個：

• 當一個 goroutine 完成了它的工作
• 由于發(fā)生了沒有處理的錯誤
• 有其他的協(xié)程告訴它終止

當三個條件都沒有滿足，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()函數(shù)結束后觸發(fā)defer close(chanInt)關閉了通道
但是匿名函數(shù)中goroutine并沒有關閉，而是一直在循環(huán)取值，并且取到是的關閉后的通道值（這里是int的默認值 0）
goroutine會永遠運行下去，如果以后再次使用又會出現(xiàn)新的泄漏！導致內(nèi)存、cpu占用越來越多

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

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

func goroutineLeakNoClosed() {
 chanInt := make(chan int)
 go func() {
  for {
            res := <-chanInt
   fmt.Println(res)
  }
 }()
}

• 無任何輸出的阻塞
• 換成寫入也是一樣的
• 如果是有緩沖的通道，換成已滿的通道寫沒有讀；或者換成向空的通道讀沒有寫也是同樣的情況
• 除了阻塞，goroutine進入死循環(huán)也是泄露的原因

如何發(fā)現(xiàn)泄露

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

小結

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

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

本節(jié)源碼地址  

到此這篇關于Go語言死鎖與goroutine泄露問題談論的文章就介紹到這了,更多相關Go語言死鎖與goroutine泄露內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論