什么時(shí)候會導(dǎo)致死鎖

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

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

發(fā)送單個(gè)值時(shí)的死鎖

牢記這兩點(diǎn)問題就很清晰了，復(fù)習(xí)下之前的例子，會死鎖

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

• 有且只有一個(gè)協(xié)程時(shí)，無緩沖的通道
• 先發(fā)送會阻塞在發(fā)送，先接收會阻塞在接收處。
• 發(fā)送操作在接收者準(zhǔn)備好之前是阻塞的，接收操作在發(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時(shí)候，因?yàn)闆]有滿，發(fā)送不會阻塞
• 在len>0時(shí)，因?yàn)椴粸榭?，所以接收不會阻?/li>

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

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

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

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)來不斷接收值，接受一個(gè)處理一個(gè)，如下：

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 代表通道是否正常，如果是關(guān)閉則為false值
• 可以刪掉那段邏輯試試，會輸出1 2 0 0 0這樣的數(shù)列，因?yàn)殛P(guān)閉是需要時(shí)間的，而循環(huán)接收關(guān)閉的通道拿到的是0
• 關(guān)于goroutine泄漏稍后會講到

應(yīng)該先發(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)上面的結(jié)果是因?yàn)閒or循環(huán)一直在獲取通道中的值，但是在讀取完1 2后，通道中沒有新的值傳入，這樣接收者就阻塞了。
• 為什么先接收再發(fā)送可以，因?yàn)榘l(fā)送提前結(jié)束后會觸發(fā)函數(shù)的defer自動關(guān)閉通道
• 所以我們應(yīng)該總是先接收后發(fā)送，并由發(fā)送端來關(guān)閉

goroutine 泄漏

goroutine 終止的場景有三個(gè)：

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

當(dāng)三個(gè)條件都沒有滿足，goroutine 就會一直運(yùn)行下去

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

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

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

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

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

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

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

小結(jié)

今天我們學(xué)習(xí)了一些細(xì)節(jié)，但是相當(dāng)重要的知識點(diǎn)，也是未來面試高頻問題哦！

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

本節(jié)源碼地址  

到此這篇關(guān)于Go語言死鎖與goroutine泄露問題談?wù)摰奈恼戮徒榻B到這了,更多相關(guān)Go語言死鎖與goroutine泄露內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論