詳解Go多協(xié)程并發(fā)環(huán)境下的錯誤處理
引言
在Go語言中,我們通常會用到panic和recover來拋出錯誤和捕獲錯誤,這一對操作在單協(xié)程環(huán)境下我們正常用就好了,并不會踩到什么坑。但是在多協(xié)程并發(fā)環(huán)境下,我們常常會碰到以下兩個問題。假設(shè)我們現(xiàn)在有2個協(xié)程,我們叫它們協(xié)程A和B好了:
- 如果協(xié)程A發(fā)生了panic,協(xié)程B是否會因為協(xié)程A的panic而掛掉?
- 如果協(xié)程A發(fā)生了panic,協(xié)程B是否能用recover捕獲到協(xié)程A的panic?
答案分別是:會、不能。
那么下面我們來一一驗證,并給出在具體的業(yè)務(wù)場景下的最佳實踐。
問題一
如果協(xié)程A發(fā)生了panic,協(xié)程B是否會因為協(xié)程A的panic而掛掉?
為了驗證這個問題,我們寫一段程序:
package main import ( "fmt" "time" ) func main() { // 協(xié)程A go func() { for { fmt.Println("goroutine1_print") } }() // 協(xié)程B go func() { time.Sleep(1 * time.Second) panic("goroutine2_panic") }() time.Sleep(2 * time.Second) }
首先主協(xié)程開啟兩個子協(xié)程A和B,A協(xié)程不停的循環(huán)打印goroutine1_print字符串;B協(xié)程在睡眠1s后,就會拋出panic(睡眠這一步為了確保在A跑起來開始打印了之后,B才會panic),主協(xié)程睡眠2s,等待A、B子協(xié)程全部執(zhí)行完畢,主協(xié)程退出。最終打印結(jié)果如下:
...
goroutine1_print
goroutine1_print
goroutine1_print
goroutine1_print
goroutine1_print
goroutine1_print
goroutine1_print
goroutine1_print
goroutine1_print
goroutine1_print
goroutine1_print
goroutine1_print
panic: goroutine2_panicgoroutine1_printgoroutine1_print
goroutine goroutine1_print
19goroutine1_print
goroutine1_print
goroutine1_print
goroutine1_print
[runninggoroutine1_print
]:
goroutine1_print
goroutine1_print
goroutine1_print
main.main.func2()
/Users/jiangbaiyan/go/src/awesomeProject/main.go:18 +0x46
created by main.main
/Users/jiangbaiyan/go/src/awesomeProject/main.go:16 +0x4d
我們可以看到,在協(xié)程B發(fā)生panic之前,協(xié)程A一直在打印字符串;然后協(xié)程A和panic交替打印字符串,最后主協(xié)程與協(xié)程A、B全部退出。所以我們可以看到,一個協(xié)程panic之后,是會導(dǎo)致所有的協(xié)程全部掛掉的,程序會整體退出,到這里我們就驗證了第一個問題的答案。
至于panic和協(xié)程A交替打印的原因,可能是因為panic也需要打印字符串。因為打印也是需要時間的,當(dāng)我們執(zhí)行panic這一行代碼的時候,到panic真正觸發(fā)所有協(xié)程掛掉,是需要一定的時間的(盡管這個時間很短暫),所以再這一小段時間內(nèi),我們會看到交替打印的現(xiàn)象。
問題二
如果協(xié)程A發(fā)生了panic,其他協(xié)程是否能用recover捕獲到協(xié)程A的panic?
還是類似上面那段代碼,我們還可以再精簡一下:
package main import ( "fmt" "time" ) func main() { defer func() { if e := recover(); e != nil { fmt.Println("recover_panic") } }() go func() { panic("goroutine2_panic") }() time.Sleep(2 * time.Second) }
我們這次只開啟一個協(xié)程,并在主協(xié)程中加入了recover,希望它能夠捕獲到子協(xié)程中的panic,但是結(jié)果未能如愿:
panic: goroutine2_panic goroutine 6 [running]: main.main.func2() /Users/jiangbaiyan/go/src/awesomeProject/main.go:17 +0x39 created by main.main /Users/jiangbaiyan/go/src/awesomeProject/main.go:16 +0x57 Process finished with exit code 2
我們看到,recover并沒有生效。所以,哪個協(xié)程發(fā)生了panic,我們就需要在哪個協(xié)程recover,我們改成這樣:
package main import ( "fmt" "time" ) func main() { go func() { defer func() { if e := recover(); e != nil { fmt.Println("recover_panic") } }() panic("goroutine2_panic") }() time.Sleep(2 * time.Second) }
結(jié)果成功打印recover_panic字符串:
recover_panic
Process finished with exit code 0
所以我們的答案也得到了驗證:協(xié)程A發(fā)生panic,協(xié)程B無法recover到協(xié)程A的panic,只有協(xié)程自己內(nèi)部的recover才能捕獲自己拋出的panic。
最佳實踐
我們先假設(shè)有這樣一個場景,我們要開發(fā)一個客戶端,這個客戶端需要調(diào)用2個服務(wù),這2個服務(wù)沒有任何先后順序的依賴,所以我們可以開啟2個goroutine,通過并發(fā)調(diào)用這兩個服務(wù)來獲得性能提升。那么這個時候我們剛才所談到的問題一就成了問題。
通常來講,我們不希望其中一個服務(wù)調(diào)用失敗,另一個服務(wù)調(diào)用也跟著失敗,而是要繼續(xù)執(zhí)行完其他幾個服務(wù)調(diào)用邏輯,這個時候我們該怎么辦呢?
聰明的你一定會想到,我在每個協(xié)程內(nèi)部編寫一個recover語句,讓他接住每個協(xié)程自己可能會發(fā)生的panic,就能夠解決一個協(xié)程panic而導(dǎo)致所有協(xié)程掛掉的問題了。我們編寫如下代碼,這就是在業(yè)務(wù)開發(fā)中,結(jié)合問題二解決問題一的最佳實踐:
// 并發(fā)調(diào)用服務(wù),每個handler都會傳入一個調(diào)用邏輯函數(shù) func GoroutineNotPanic(handlers ...func() error) (err error) { var wg sync.WaitGroup // 假設(shè)我們要調(diào)用handlers這么多個服務(wù) for _, f := range handlers { wg.Add(1) // 每個函數(shù)啟動一個協(xié)程 go func(handler func() error) { defer func() { // 每個協(xié)程內(nèi)部使用recover捕獲可能在調(diào)用邏輯中發(fā)生的panic if e := recover(); e != nil { // 某個服務(wù)調(diào)用協(xié)程報錯,可以在這里打印一些錯誤日志 } wg.Done() }() // 取第一個報錯的handler調(diào)用邏輯,并最終向外返回 e := handler() if err == nil && e != nil { err = e } }(f) } wg.Wait() return }
以上方法調(diào)用示例:
// 調(diào)用示例 func main() { // 調(diào)用邏輯1 aRpc := func() error { panic("rpc logic A panic") return nil } // 調(diào)用邏輯2 bRpc := func() error { fmt.Println("rpc logic B") return nil } err := GoroutineNotPanic(aRpc, bRpc) if err != nil { fmt.Println(err) } }
這樣我們就實現(xiàn)了一個通用的并發(fā)處理邏輯,每次調(diào)用我們只需要把業(yè)務(wù)邏輯的函數(shù)傳入即可,不用每次自己單獨編寫一套并發(fā)控制邏輯;同時調(diào)用邏輯2就不會因為調(diào)用邏輯1的panic而掛掉了,容錯率更高。在業(yè)務(wù)開發(fā)中我們可以參考這種實現(xiàn)方式~
到此這篇關(guān)于詳解Go多協(xié)程并發(fā)環(huán)境下的錯誤處理的文章就介紹到這了,更多相關(guān)Go多協(xié)程并發(fā)錯誤處理內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
go內(nèi)存緩存BigCache之Entry封裝源碼閱讀
這篇文章主要介紹了go內(nèi)存緩存BigCache之Entry封裝源碼閱讀2023-09-09Golang中常見的三種并發(fā)控制方式使用小結(jié)
這篇文章主要為大家詳細介紹了如何對goroutine并發(fā)行為的控制,在Go中最常見的有三種方式:sync.WaitGroup、channel和Context,下面我們就來看看他們的具體使用吧2024-01-01Golang?Gin框架獲取請求參數(shù)的幾種常見方式
在我們平常添加路由處理函數(shù)之后,就可以在路由處理函數(shù)中編寫業(yè)務(wù)處理代碼了,但在此之前我們往往需要獲取請求參數(shù),本文就詳細的講解下gin獲取請求參數(shù)常見的幾種方式,需要的朋友可以參考下2024-02-02