引言

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

到此這篇關於詳解Go多協程併發環境下的錯誤處理的文章就介紹到這了,更多相關Go多協程併發錯誤處理內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！