[[442134]]

 大家好，我是煎魚。

有一次事故現場，在緊急恢復后，他正在排查代碼，查了好一會。我回頭一看，這錯誤提醒很明顯就是致命錯誤，較好定位。

但此時，他竟然在查 panic-recover 是不是哪里漏了，我表示大受震驚...

今天就由煎魚給大家分享一下錯誤類型有哪幾種，又在什么場景下會觸發。

錯誤類型

error

第一種是 Go 中最標準的 error 錯誤，其真身是一個 interface{}。

如下：

type error interface { 
    Error() string 
} 

在日常工程中，我們只需要創建任意結構體，實現了 Error 方法，就可以認為是 error 錯誤類型。

如下：

type errorString struct { 
    s string 
} 
 
func (e *errorString) Error() string { 
    return e.s 
} 

在外部調用標準庫 API，一般如下：

f, err := os.Open("filename.ext") 
if err != nil { 
    log.Fatal(err) 
} 
// do something with the open *File f 

我們會約定最后一個參數為 error 類型，一般常見于第二個參數，可以有個約定俗成的習慣。

panic

第二種是 Go 中的異常處理 panic，能夠產生異常錯誤，結合 panic+recover 可以扭轉程序的運行狀態。

如下：

package main 
 
import "os" 
 
func main() { 
    panic("a problem") 
 
    _, err := os.Create("/tmp/file") 
    if err != nil { 
        panic(err) 
    } 
} 

輸出結果：

$ go run panic.go 
panic: a problem 
goroutine 1 [running]: 
main.main() 
    /.../panic.go:12 +0x47 
... 
exit status 2 

如果沒有使用 recover 作為捕獲，就會導致程序中斷。也因此經常被人誤以為程序中斷，就 100% 是 panic 導致的。

這是一個誤區。

throw

第三種是 Go 初學者經常踩坑，也不知道的錯誤類型，那就是致命錯誤 throw。

這個錯誤類型，在用戶側是沒法主動調用的，均為 Go 底層自行調用的，像是大家常見的 map 并發讀寫，就是由此觸發。

其源碼如下：

func throw(s string) { 
 systemstack(func() { 
  print("fatal error: ", s, "\n") 
 }) 
 gp := getg() 
 if gp.m.throwing == 0 { 
  gp.m.throwing = 1 
 } 
 fatalthrow() 
 *(*int)(nil) = 0 // not reached 
} 

根據上述程序，會獲取當前 G 的實例，并設置其 M 的 throwing 狀態為 1。

狀態設置好后，會調用 fatalthrow 方法進行真正的 crash 相關操作：

func fatalthrow() { 
 pc := getcallerpc() 
 sp := getcallersp() 
 gp := getg() 
  
 systemstack(func() { 
  startpanic_m() 
  if dopanic_m(gp, pc, sp) { 
   crash() 
  } 
 
  exit(2) 
 }) 
 
 *(*int)(nil) = 0 // not reached 
} 

主體邏輯是發送 _SIGABRT 信號量，最后調用 exit 方法退出，所以你會發現這是攔也攔不住的 “致命” 錯誤。

致命場景

為此，作為一名 “成熟” 的 Go 工程師，除了保障自己程序的健壯性外，我也在網上收集了一些致命的錯誤場景，分享給大家。

一起學習和規避這些致命場景，年底爭取拿個 A，不要背上 P0 事故。

并發讀寫 map

func foo() { 
 m := map[string]int{} 
 go func() { 
  for { 
   m["煎魚1"] = 1 
  } 
 }() 
 for { 
  _ = m["煎魚2"] 
 } 
} 

輸出結果：

fatal error: concurrent map read and map write 
 
goroutine 1 [running]: 
runtime.throw(0x1078103, 0x21) 
... 

堆棧內存耗盡

func foo() { 
 var f func(a [1000]int64) 
 f = func(a [1000]int64) { 
  f(a) 
 } 
 f([1000]int64{}) 
} 

輸出結果：

runtime: goroutine stack exceeds 1000000000-byte limit 
runtime: sp=0xc0200e1bf0 stack=[0xc0200e0000, 0xc0400e0000] 
fatal error: stack overflow 
 
runtime stack: 
runtime.throw(0x1074ba3, 0xe) 
        /usr/local/Cellar/go/1.16.6/libexec/src/runtime/panic.go:1117 +0x72 
runtime.newstack() 
... 

將 nil 函數作為 goroutine 啟動

func foo() { 
 var f func() 
 go f() 
} 

輸出結果：

fatal error: go of nil func value 
 
goroutine 1 [running]: 
main.foo() 
... 

goroutines 死鎖

func foo() { 
 select {} 
} 

輸出結果：

fatal error: all goroutines are asleep - deadlock! 
 
goroutine 1 [select (no cases)]: 
main.foo() 
... 

線程限制耗盡

如果你的 goroutines 被 IO 操作阻塞了，新的線程可能會被啟動來執行你的其他 goroutines。

Go 的最大的線程數是有默認限制的，如果達到了這個限制，你的應用程序就會崩潰。

會出現如下輸出結果：

fatal error: thread exhaustion 
... 

可以通過調用 runtime.SetMaxThreads 方法增大線程數，不過也需要考量是否程序有問題。

超出可用內存

如果你執行的操作，例如：下載大文件等。導致應用程序占用內存過大，程序上漲，導致 OOM。

會出現如下輸出結果：

fatal error: runtime: out of memory 
... 

建議處理掉一些程序，或者換新電腦了。

總結

在今天這篇文章中，我們介紹了 Go 語言的三種錯誤類型。其中針對大家最少見，但一碰到就很容易翻車的致命錯誤 fatal error 進行了介紹，給出了一些經典案例。

希望大家后續能夠規避，你有沒有遇到過其中的場景?

歡迎在評論區交流和留言：)

參考

Are all runtime errors recoverable in Go?