引言
在Go語言中,我們通常會用到panic和recover來丟擲錯誤和捕獲錯誤,這一對操作在單協程環境下我們正常用就好了,並不會踩到什麼坑。但是在多協程併發環境下,我們常常會碰到以下兩個問題。假設我們現在有2個協程,我們叫它們協程A和B好了:
- 如果協程A發生了panic,協程B是否會因為協程A的panic而掛掉?
- 如果協程A發生了panic,協程B是否能用recover捕獲到協程A的panic?
答案分別是:會、不能。
那麼下面我們來一一驗證,並給出在具體的業務場景下的最佳實踐。
問題一
- 如果協程A發生了panic,協程B是否會因為協程A的panic而掛掉?
為了驗證這個問題,我們寫一段程式:
package main
import (
"fmt"
"time"
)
func main() {
// 協程A
go func() {
for {
fmt.Println("goroutine1_print")
}
}()
// 協程B
go func() {
time.Sleep(1 * time.Second)
panic("goroutine2_panic")
}()
time.Sleep(2 * time.Second)
}
首先主協程開啟兩個子協程A和B,A協程不停的迴圈列印goroutine1_print字串;B協程在睡眠1s後,就會丟擲panic(睡眠這一步為了確保在A跑起來開始列印了之後,B才會panic),主協程睡眠2s,等待A、B子協程全部執行完畢,主協程退出。最終列印結果如下:
...
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_print
goroutine1_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
我們可以看到,在協程B發生panic之前,協程A一直在列印字串;然後協程A和panic交替列印字串,最後主協程與協程A、B全部退出。所以我們可以看到,一個協程panic之後,是會導致所有的協程全部掛掉的,程式會整體退出,到這裡我們就驗證了第一個問題的答案。
至於panic和協程A交替列印的原因,可能是因為panic也需要列印字串。因為列印也是需要時間的,當我們執行panic這一行程式碼的時候,到panic真正觸發所有協程掛掉,是需要一定的時間的(儘管這個時間很短暫),所以再這一小段時間內,我們會看到交替列印的現象。
問題二
- 如果協程A發生了panic,其他協程是否能用recover捕獲到協程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)
}
我們這次只開啟一個協程,並在主協程中加入了recover,希望它能夠捕獲到子協程中的panic,但是結果未能如願:
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並沒有生效。所以,哪個協程發生了panic,我們就需要在哪個協程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)
}
結果成功列印recover_panic字串:
recover_panic
Process finished with exit code 0
所以我們的答案也得到了驗證:協程A發生panic,協程B無法recover到協程A的panic,只有協程自己內部的recover才能捕獲自己丟擲的panic。
最佳實踐
我們先假設有這樣一個場景,我們要開發一個客戶端,這個客戶端需要呼叫2個服務,這2個服務沒有任何先後順序的依賴,所以我們可以開啟2個goroutine,通過併發呼叫這兩個服務來獲得效能提升。那麼這個時候我們剛才所談到的問題一就成了問題。
通常來講,我們不希望其中一個服務呼叫失敗,另一個服務呼叫也跟著失敗,而是要繼續執行完其他幾個服務呼叫邏輯,這個時候我們該怎麼辦呢?
聰明的你一定會想到,我在每個協程內部編寫一個recover語句,讓他接住每個協程自己可能會發生的panic,就能夠解決一個協程panic而導致所有協程掛掉的問題了。我們編寫如下程式碼,這就是在業務開發中,結合問題二解決問題一的最佳實踐:
// 併發呼叫服務,每個handler都會傳入一個呼叫邏輯函式
func GoroutineNotPanic(handlers ...func() error) (err error) {
var wg sync.WaitGroup
// 假設我們要呼叫handlers這麼多個服務
for _, f := range handlers {
wg.Add(1)
// 每個函式啟動一個協程
go func(handler func() error) {
defer func() {
// 每個協程內部使用recover捕獲可能在呼叫邏輯中發生的panic
if e := recover(); e != nil {
// 某個服務呼叫協程報錯,可以在這裡列印一些錯誤日誌
}
wg.Done()
}()
// 取第一個報錯的handler呼叫邏輯,並最終向外返回
e := handler()
if err == nil && e != nil {
err = e
}
}(f)
}
wg.Wait()
return
}
以上方法呼叫示例:
// 呼叫示例
func main() {
// 呼叫邏輯1
aRpc := func() error {
panic("rpc logic A panic")
return nil
}
// 呼叫邏輯2
bRpc := func() error {
fmt.Println("rpc logic B")
return nil
}
err := GoroutineNotPanic(aRpc, bRpc)
if err != nil {
fmt.Println(err)
}
}
這樣我們就實現了一個通用的併發處理邏輯,每次呼叫我們只需要把業務邏輯的函式傳入即可,不用每次自己單獨編寫一套併發控制邏輯;同時呼叫邏輯2就不會因為呼叫邏輯1的panic而掛掉了,容錯率更高。在業務開發中我們可以參考這種實現方式~
關注我們
歡迎各位訂閱我們的公眾號,關注博主下次不迷路~