Go 語言中 panic 和 recover 搭配使用

作者：小魔童哪吒 2023-10-09 07:14:42

開發前端

當我們在同一個協程中出現了 panic，且在同一個協程中去使用 defer 來配合 recover 來進行捕獲異常和處理異常，就可以得以實現，看到這里，有沒有覺得還是蠻簡單的，不就是去對一個 p.recovered 進行配合處理嗎？

本次主要聊聊 Go 語言中關于 panic 和 recover 搭配使用，以及 panic 的基本原理

最近工作中審查代碼的時候發現一段代碼，類似于如下這樣，將 recover 放到一個子協程里面，期望去捕獲主協程的程序異常

圖片

看到此處，是否會想這段代碼在項目中是想當然寫出來的吧，然而平日中，大多問題是出現在認知偏差上，那么本次，我們就來消除一下這個認知偏差

關于 Go 語言中顯示的使用 panic 的地方不多，一般 panic ，基本上會出現在咱們程序出現異常退出的時候

例如訪問了空指針里面的值，則會 panic 報錯無效的內存地址，又例如訪問量數組中不存在的數組所索引，或者切片索引，那么會報錯 panic 數組越界等等

可是碰到這些 panic 的時候，實際上我們并不期望當前的服務直接掛掉，而是期望這個異常能夠被識別，且不影響程序其他部分的模塊運行

正常捕獲異常

在 Go 中可以將 defer 和 recover 進行搭配使用，可以捕獲和處理大部分的異常情況，例如可以這樣

圖片

這里可以看到，recover 捕獲異常和發生異常的部分是在同一個協程中，實驗證明是可以正常捕獲并且處理異常

并沒有捕獲到異常

直接不做顯示的 recover，自然 panic 程序崩潰會如期而至，此處我們顯示的使用 panic 函數來制造恐慌

func main() {
   log.SetFlags(log.Lshortfile)

   panic("panic coming...")

}

圖片

不使用 defer 來進行處理

func main() {
   log.SetFlags(log.Lshortfile)
    if err := recover(); err != nil {
     log.Println("recover panic : ", err)
    }
   panic("panic coming...")

}

圖片

自然 recover 函數是在 panic 調用之前就已經執行，此時是還沒有異常需要捕獲和恢復的，待程序運行到 panic 處的時候，實際上并沒有沒有處理程序崩潰的異常

結果，仍然是程序崩潰

當然，還有文章開頭提到的出現 panic 的位置和捕獲和處理程序崩潰異常的位置不在同一個協程，自然也是沒法捕獲到的，這一點需要注意，其他的語言可能不是這樣，但是 Go 中是這樣的

panic 基本原理

看了上述現象，實際上還是對知識點理解得不夠，使用的時候想當然了，就像使用 defer 一樣，如果對他不夠了解的話，使用的時候，確實會出現一些奇奇怪怪的現象，對于 defer 的使用可以查看文末的文章地址

panic 函數和 recover 函數，Go 源碼builtin\builtin.go中可以看到注釋

圖片

注釋中有說關于 panic 和 recover 的使用是作用于當前協程的，因此我們使用的時候，如果跨協程教程使用，自然不會達到我們期望的效果

繼續查看關于 panic 的源碼，實際上是一個結構，放到 defer 結構里面的一個指針，源碼位置：runtime\runtime2.go

圖片

_panic 的結構如下：

type _panic struct {
   argp      unsafe.Pointer
   arg       interface{}
   link      *_panic
   pc        uintptr
   sp        unsafe.Pointer
   recovered bool
   aborted   bool
   goexit    bool
}

上述兩個結構表達的意思是，程序中出現 panic 的時候，實際上都會創建一個 _panic 結構，這個 _panic 結構里面存儲了當前程序崩潰的一些必要信息，如下：

argp

是一個 unsafe.Pointer 類型的成員，指向 defer 調用參數的指針

出現 panic 的原因，如果我們顯示調用 panic，那么就是我們填入 panic 函數中的參數，例如上述的 panic coming ...

link

是一個指針，指向上一個，最近的一個 _panic 結構的地址，實際上此處就可以看到這個指針對應的是一個鏈表，一個又多個 _panic 結構組成的鏈表

圖片

recovered

panic 是否已經處理完畢，即當前的這個 panic 是否是已經被 recover 了

aborted

表示當前的 panic 是否被中止

對于 pc 和 sp 自然就是我們熟知的 pc 通用寄存器，在匯編中是指向當前運行指令的下一條指令，sp 則是棧指針 stack pointer，用于入棧和出棧的

我們知道運行函數的時候需要入棧，運行完畢之后需要出棧

源碼中的 runtime.gopanic

那么我們繼續來閱讀源碼，上述看到 sp 和 pc ，那么我們就簡單寫一個 panic 的代碼來看看匯編到底是怎么執行的，不用擔心看不懂，我們只需要看關鍵詞就行

還是上面的程序

圖片

程序運行的時候可以執行 go tool compile -S main.go

可以看到匯編代碼，可能其他的看不懂，但是我們可以看到如下關鍵詞

圖片

log.(*Logger).SetFlags(SB) 即是執行到我們調用 log 去設置參數
程序走到 panic 函數的時候，實際上是執行了 runtime.gopanic 函數，我們一起看看源碼

圖片

代碼中可以看到 p.recovered 邏輯下的關于 recover 的邏輯被刪除掉了，在文章的后面會繼續說到，當前我們先關注 panic 的事項

runtime.gopanic 程序的邏輯大體是這樣的

獲取當前協程的指針
初始化一個 _panic 結構 p，并將當前協程上對應的數據賦值給到 p 上，且將當前協程 _panic 掛到 link 上
進入循環后，拿到當前協程的 _defer 數據
查看 _defer 指針數據中是否有 defer 調用，如果有則執行
處理完基本邏輯之后，打印 panic 信息，例如我們 demo 中的 panic coming ... 信息
最終退出程序

Xdm 可以看上圖，自己捋一捋邏輯就清晰了

接著，我們來看

fatalpanic

圖片

通過 runtime.gopanic 我們可以看到 fatalpanic 函數基本上就是做一個收尾工作了，如果上述程序處理完畢之后， fatalpanic 校驗到 panic 是需要 recover 的，那么就打印 [recovered]

打印的這個信息是由上圖中 printpanics 完成的

圖片

這下知道 panic 是如何去執行的了，那么對于現在來研究 recover 是如何落實的

recover

還是同一個例子，咱們將 defer 部分的代碼注打開，來繼續看看效果

func main() {
   log.SetFlags(log.Lshortfile)

   defer func() {
      if err := recover(); err != nil {
         log.Println("recover panic : ", err)
      }
   }()

   panic("panic coming...")

}

自然效果是我們期望的，捕獲到了異常，且處理了

圖片