目錄
- 什么時(shí)候會(huì)導(dǎo)致死鎖
- 發(fā)送單個(gè)值時(shí)的死鎖
- 多個(gè)值發(fā)送的死鎖
- 解決多值發(fā)送死鎖
- 應(yīng)該先發(fā)送還是先接收
- goroutine 泄漏
- 如何發(fā)現(xiàn)泄露
- 小結(jié)
什么時(shí)候會(huì)導(dǎo)致死鎖
在計(jì)算機(jī)組成原理里說(shuō)過(guò) 死鎖有三個(gè)必要條件他們分別是 循環(huán)等待、資源共享、非搶占式,在并發(fā)中出現(xiàn)通道死鎖只有兩種情況:
- 數(shù)據(jù)要發(fā)送,但是沒(méi)有人接收
- 數(shù)據(jù)要接收,但是沒(méi)有人發(fā)送
發(fā)送單個(gè)值時(shí)的死鎖
牢記這兩點(diǎn)問(wèn)題就很清晰了,復(fù)習(xí)下之前的例子,會(huì)死鎖
a := make(chan int)
a - 1 //將數(shù)據(jù)寫(xiě)入channel
z := -a //從channel中讀取數(shù)據(jù)
- 有且只有一個(gè)協(xié)程時(shí),無(wú)緩沖的通道
- 先發(fā)送會(huì)阻塞在發(fā)送,先接收會(huì)阻塞在接收處。
- 發(fā)送操作在接收者準(zhǔn)備好之前是阻塞的,接收操作在發(fā)送之前是阻塞的,
解決辦法就是改為緩沖通道,或者使用協(xié)程配對(duì)
解決方法一,協(xié)程配對(duì),先發(fā)送還是先接收無(wú)所謂只要配對(duì)就好
chanInt := make(chan int)
go func() {
chanInt - 1
}()
res := -chanInt
解決方法二,緩沖通道
chanInt := make(chan int,1)
chanInt - 2
res := -chanInt
- 緩沖通道內(nèi)部的消息數(shù)量用len()函數(shù)可以測(cè)試出來(lái)
- 緩沖通道的容量可以用cap()測(cè)試出來(lái)
- 在滿足cap>len時(shí)候,因?yàn)闆](méi)有滿,發(fā)送不會(huì)阻塞
- 在len>0時(shí),因?yàn)椴粸榭?,所以接收不?huì)阻塞
使用緩沖通道可以讓生產(chǎn)者和消費(fèi)者減少阻塞的可能性,對(duì)異步操作更友好,不用等待對(duì)方準(zhǔn)備,但是容量不應(yīng)設(shè)置過(guò)大,不然會(huì)占用較多內(nèi)存。
多個(gè)值發(fā)送的死鎖
配對(duì)可以讓死鎖消失,但發(fā)送多個(gè)值的時(shí)候又無(wú)法配對(duì)了,又會(huì)死鎖
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()
在工作中只有通知信號(hào)是一對(duì)一的情況,通知一次以后就不再使用了,其他這種要求多次讀寫(xiě)配對(duì)的情況根本不會(huì)存在。
解決多值發(fā)送死鎖
更常見(jiàn)的是用循環(huán)來(lái)不斷接收值,接受一個(gè)處理一個(gè),如下:
func multipleLoop() {
chanInt := make(chan int)
defer close(chanInt)
go func() {
for {
//不使用ok會(huì)goroutine泄漏
//res := -chanInt
res,ok := -chanInt
if !ok {
break
}
fmt.Println(res)
}
}()
chanInt - 1
chanInt - 1
}
輸出:
1
1
- 給通道的接收加上二值,ok 代表通道是否正常,如果是關(guān)閉則為false值
- 可以刪掉那段邏輯試試,會(huì)輸出1 2 0 0 0這樣的數(shù)列,因?yàn)殛P(guān)閉是需要時(shí)間的,而循環(huán)接收關(guān)閉的通道拿到的是0
- 關(guān)于goroutine泄漏稍后會(huì)講到
應(yīng)該先發(fā)送還是先接收
假如我們調(diào)換一下位置,把接收放外面,寫(xiě)入放里面會(huì)發(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后,通道中沒(méi)有新的值傳入,這樣接收者就阻塞了。
- 為什么先接收再發(fā)送可以,因?yàn)榘l(fā)送提前結(jié)束后會(huì)觸發(fā)函數(shù)的defer自動(dòng)關(guān)閉通道
- 所以我們應(yīng)該總是先接收后發(fā)送,并由發(fā)送端來(lái)關(guān)閉
goroutine 泄漏
goroutine 終止的場(chǎng)景有三個(gè):
- 當(dāng)一個(gè) goroutine 完成了它的工作
- 由于發(fā)生了沒(méi)有處理的錯(cuò)誤
- 有其他的協(xié)程告訴它終止
當(dāng)三個(gè)條件都沒(méi)有滿足,goroutine 就會(huì)一直運(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并沒(méi)有關(guān)閉,而是一直在循環(huán)取值,并且取到是的關(guān)閉后的通道值(這里是int的默認(rèn)值 0)
goroutine會(huì)永遠(yuǎn)運(yùn)行下去,如果以后再次使用又會(huì)出現(xiàn)新的泄漏!導(dǎo)致內(nèi)存、cpu占用越來(lái)越多
輸出,如果程序不停止就會(huì)一直輸出0
1
1
0
0
0
...
假如不關(guān)閉且外部沒(méi)有寫(xiě)入值,那接收處就會(huì)永遠(yuǎn)阻塞在那里,連輸出都不會(huì)有
func goroutineLeakNoClosed() {
chanInt := make(chan int)
go func() {
for {
res := -chanInt
fmt.Println(res)
}
}()
}
- 無(wú)任何輸出的阻塞
- 換成寫(xiě)入也是一樣的
- 如果是有緩沖的通道,換成已滿的通道寫(xiě)沒(méi)有讀;或者換成向空的通道讀沒(méi)有寫(xiě)也是同樣的情況
- 除了阻塞,goroutine進(jìn)入死循環(huán)也是泄露的原因
如何發(fā)現(xiàn)泄露
- 使用 golang 自帶的pprof監(jiān)控工具,可以發(fā)現(xiàn)內(nèi)存上漲情況,這個(gè)后續(xù)會(huì)講
- 還可以監(jiān)控進(jìn)程的內(nèi)存使用情況,比如prometheus提供的process-exporter
- 如果你有內(nèi)存泄露/goroutine 泄露代碼掃描的工具,歡迎留言,感恩!
小結(jié)
今天我們學(xué)習(xí)了一些細(xì)節(jié),但是相當(dāng)重要的知識(shí)點(diǎn),也是未來(lái)面試高頻問(wèn)題哦!
- 如果是信號(hào)通知,應(yīng)該保證一一對(duì)應(yīng),不然會(huì)死鎖
- 除了信號(hào)通知外,通常我們使用循環(huán)處理通道,在工作中不斷的處理數(shù)據(jù)
- 應(yīng)該總是先接收后發(fā)送,并由發(fā)送端來(lái)關(guān)閉,不然容易死鎖或者泄露
- 在接收處,應(yīng)該對(duì)通道是否關(guān)閉做好判斷,已關(guān)閉應(yīng)該退出接收,不然會(huì)泄露
- 小心 goroutine 泄漏,應(yīng)該在通道關(guān)閉的時(shí)候及時(shí)檢查通道并退出
- 除了阻塞,goroutine進(jìn)入死循環(huán)也是泄露的原因
本節(jié)源碼地址
到此這篇關(guān)于Go語(yǔ)言死鎖與goroutine泄露問(wèn)題談?wù)摰奈恼戮徒榻B到這了,更多相關(guān)Go語(yǔ)言死鎖與goroutine泄露內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
您可能感興趣的文章:- 詳解Golang并發(fā)操作中常見(jiàn)的死鎖情形
- Go 語(yǔ)言中的死鎖問(wèn)題解決
- golang coroutine 的等待與死鎖用法
- go select編譯期的優(yōu)化處理邏輯使用場(chǎng)景分析
- Django實(shí)現(xiàn)jquery select2帶搜索的下拉框
- Go語(yǔ)言使用select{}阻塞main函數(shù)介紹
- matplotlib之多邊形選區(qū)(PolygonSelector)的使用
- golang中的select關(guān)鍵字用法總結(jié)
- Go select 死鎖的一個(gè)細(xì)節(jié)