Go多協程併發環境下的錯誤處理

引言

在Go語言中,咱們一般會用到panic和recover來拋出錯誤和捕獲錯誤,這一對操做在單協程環境下咱們正經常使用就行了,並不會踩到什麼坑。可是在多協程併發環境下,咱們經常會碰到如下兩個問題。假設咱們如今有2個協程,咱們叫它們協程A和B好了:golang

  • 若是協程A發生了panic,協程B是否會由於協程A的panic而掛掉?
  • 若是協程A發生了panic,協程B是否能用recover捕獲到協程A的panic?

答案分別是:會、不能。
那麼下面咱們來一一驗證,並給出在具體的業務場景下的最佳實踐。segmentfault

問題一

  • 若是協程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?

仍是相似上面那段代碼,咱們還能夠再精簡一下:spa

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,咱們改爲這樣:code

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而掛掉了,容錯率更高。在業務開發中咱們能夠參考這種實現方式~

關注咱們

歡迎各位訂閱咱們的公衆號,關注博主下次不迷路~

Nosay

相關文章
相關標籤/搜索