面試高頻：Go語言死鎖與goroutine泄露問題談?wù)?/h1>
★本節(jié)源碼位置 https://github.com/golang-minibear2333/golang/blob/master/4.concurrent/4.4-deadlock/
”
什么時候會導(dǎo)致死鎖
在計算機組成原理里說過 死鎖有三個必要條件他們分別是 循環(huán)等待、資源共享、非搶占式，在并發(fā)中出現(xiàn)通道死鎖只有兩種情況：
數(shù)據(jù)要發(fā)送，但是沒有人接收 數(shù)據(jù)要接收，但是沒有人發(fā)送
發(fā)送單個值時的死鎖
牢記這兩點問題就很清晰了，復(fù)習(xí)下之前的例子，會死鎖
a := make(chan int)
a <- 1 //將數(shù)據(jù)寫入channel
z := <-a //從channel中讀取數(shù)據(jù)
有且只有一個協(xié)程時，無緩沖的通道 先發(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時候，因為沒有滿，發(fā)送不會阻塞 在len>0時，因為不為空，所以接收不會阻塞
使用緩沖通道可以讓生產(chǎn)者和消費者減少阻塞的可能性，對異步操作更友好，不用等待對方準(zhǔn)備，但是容量不應(yīng)設(shè)置過大，不然會占用較多內(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 代表通道是否正常，如果是關(guān)閉則為false值 可以刪掉那段邏輯試試，會輸出1 2 0 0 0這樣的數(shù)列，因為關(guān)閉是需要時間的，而循環(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é)果是因為for循環(huán)一直在獲取通道中的值，但是在讀取完1 2后，通道中沒有新的值傳入，這樣接收者就阻塞了。 為什么先接收再發(fā)送可以，因為發(fā)送提前結(jié)束后會觸發(fā)函數(shù)的defer自動關(guān)閉通道 所以我們應(yīng)該總是先接收后發(fā)送，并由發(fā)送端來關(guān)閉
goroutine 泄漏
goroutine 終止的場景有三個：
當(dāng)一個 goroutine 完成了它的工作 由于發(fā)生了沒有處理的錯誤 有其他的協(xié)程告訴它終止
當(dāng)三個條件都沒有滿足，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ù)結(jié)束后觸發(fā)defer close(chanInt)關(guān)閉了通道 但是匿名函數(shù)中goroutine并沒有關(guān)閉，而是一直在循環(huán)取值，并且取到是的關(guān)閉后的通道值（這里是int的默認(rèn)值 0） goroutine會永遠(yuǎ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進入死循環(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é)
今天我們學(xué)習(xí)了一些細(xì)節(jié)，但是相當(dāng)重要的知識點，也是未來面試高頻問題哦！
如果是信號通知，應(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)閉的時候及時檢查通道并退出 除了阻塞，goroutine進入死循環(huán)也是泄露的原因
往期精彩回顧
后續(xù)文章更新請點擊閱讀原文跳轉(zhuǎn)開源書
（點擊上方卡片關(guān)注我持續(xù)更新優(yōu)質(zhì)文章）
★本節(jié)源碼位置 https://github.com/golang-minibear2333/golang/blob/master/4.concurrent/4.4-deadlock/
”
什么時候會導(dǎo)致死鎖
在計算機組成原理里說過 死鎖有三個必要條件他們分別是 循環(huán)等待、資源共享、非搶占式，在并發(fā)中出現(xiàn)通道死鎖只有兩種情況：
數(shù)據(jù)要發(fā)送，但是沒有人接收 數(shù)據(jù)要接收，但是沒有人發(fā)送
發(fā)送單個值時的死鎖
牢記這兩點問題就很清晰了，復(fù)習(xí)下之前的例子，會死鎖
a := make(chan int)
a <- 1 //將數(shù)據(jù)寫入channel
z := <-a //從channel中讀取數(shù)據(jù)
有且只有一個協(xié)程時，無緩沖的通道 先發(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時候，因為沒有滿，發(fā)送不會阻塞在 len>0時，因為不為空，所以接收不會阻塞
使用緩沖通道可以讓生產(chǎn)者和消費者減少阻塞的可能性，對異步操作更友好，不用等待對方準(zhǔn)備，但是容量不應(yīng)設(shè)置過大，不然會占用較多內(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代表通道是否正常，如果是關(guān)閉則為false值可以刪掉那段邏輯試試，會輸出 1 2 0 0 0這樣的數(shù)列，因為關(guān)閉是需要時間的，而循環(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é)果是因為 for循環(huán)一直在獲取通道中的值，但是在讀取完1 2后，通道中沒有新的值傳入，這樣接收者就阻塞了。為什么先接收再發(fā)送可以，因為發(fā)送提前結(jié)束后會觸發(fā)函數(shù)的 defer自動關(guān)閉通道所以我們應(yīng)該總是先接收后發(fā)送，并由發(fā)送端來關(guān)閉
goroutine 泄漏
goroutine 終止的場景有三個：
當(dāng)一個 goroutine完成了它的工作由于發(fā)生了沒有處理的錯誤 有其他的協(xié)程告訴它終止
當(dāng)三個條件都沒有滿足，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ù)結(jié)束后觸發(fā)defer close(chanInt)關(guān)閉了通道但是匿名函數(shù)中 goroutine并沒有關(guān)閉，而是一直在循環(huán)取值，并且取到是的關(guān)閉后的通道值（這里是int的默認(rèn)值 0）goroutine會永遠(yuǎ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進入死循環(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é)
今天我們學(xué)習(xí)了一些細(xì)節(jié)，但是相當(dāng)重要的知識點，也是未來面試高頻問題哦！
如果是信號通知，應(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)閉的時候及時檢查通道并退出 除了阻塞， goroutine進入死循環(huán)也是泄露的原因
往期精彩回顧
后續(xù)文章更新請點擊閱讀原文跳轉(zhuǎn)開源書