Go 有哪幾種無法恢復(fù)的致命場(chǎng)景？
大家好，我是煎魚。
有一次事故現(xiàn)場(chǎng)，在緊急恢復(fù)后，他正在排查代碼，查了好一會(huì)。我回頭一看，這錯(cuò)誤提醒很明顯就是致命錯(cuò)誤，較好定位。
但此時(shí)，他竟然在查 panic-recover 是不是哪里漏了，我表示大受震驚...
今天就由煎魚給大家分享一下錯(cuò)誤類型有哪幾種，又在什么場(chǎng)景下會(huì)觸發(fā)。
錯(cuò)誤類型
error
第一種是 Go 中最標(biāo)準(zhǔn)的 error 錯(cuò)誤，其真身是一個(gè) interface{}。
如下：
- type error interface {
- Error() string
- }
在日常工程中，我們只需要?jiǎng)?chuàng)建任意結(jié)構(gòu)體，實(shí)現(xiàn)了 Error 方法，就可以認(rèn)為是 error 錯(cuò)誤類型。
如下：
- type errorString struct {
- s string
- }
- func (e *errorString) Error() string {
- return e.s
- }
在外部調(diào)用標(biāo)準(zhǔn)庫(kù) API，一般如下：
- f, err := os.Open("filename.ext")
- if err != nil {
- log.Fatal(err)
- }
- // do something with the open *File f
我們會(huì)約定最后一個(gè)參數(shù)為 error 類型，一般常見于第二個(gè)參數(shù)，可以有個(gè)約定俗成的習(xí)慣。
panic
第二種是 Go 中的異常處理 panic，能夠產(chǎn)生異常錯(cuò)誤，結(jié)合 panic+recover 可以扭轉(zhuǎn)程序的運(yùn)行狀態(tài)。
如下：
- package main
- import "os"
- func main() {
- panic("a problem")
- _, err := os.Create("/tmp/file")
- if err != nil {
- panic(err)
- }
- }
輸出結(jié)果：
- $ go run panic.go
- panic: a problem
- goroutine 1 [running]:
- main.main()
- /.../panic.go:12 +0x47
- ...
- exit status 2
如果沒有使用 recover 作為捕獲，就會(huì)導(dǎo)致程序中斷。也因此經(jīng)常被人誤以為程序中斷，就 100% 是 panic 導(dǎo)致的。
這是一個(gè)誤區(qū)。
throw
第三種是 Go 初學(xué)者經(jīng)常踩坑，也不知道的錯(cuò)誤類型，那就是致命錯(cuò)誤 throw。
這個(gè)錯(cuò)誤類型，在用戶側(cè)是沒法主動(dòng)調(diào)用的，均為 Go 底層自行調(diào)用的，像是大家常見的 map 并發(fā)讀寫，就是由此觸發(fā)。
其源碼如下：
- 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
- }
根據(jù)上述程序，會(huì)獲取當(dāng)前 G 的實(shí)例，并設(shè)置其 M 的 throwing 狀態(tài)為 1。
狀態(tài)設(shè)置好后，會(huì)調(diào)用 fatalthrow 方法進(jìn)行真正的 crash 相關(guān)操作：
- 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
- }
主體邏輯是發(fā)送 _SIGABRT 信號(hào)量，最后調(diào)用 exit 方法退出，所以你會(huì)發(fā)現(xiàn)這是攔也攔不住的 “致命” 錯(cuò)誤。
致命場(chǎng)景
為此，作為一名 “成熟” 的 Go 工程師，除了保障自己程序的健壯性外，我也在網(wǎng)上收集了一些致命的錯(cuò)誤場(chǎng)景，分享給大家。
一起學(xué)習(xí)和規(guī)避這些致命場(chǎng)景，年底爭(zhēng)取拿個(gè) A，不要背上 P0 事故。
并發(fā)讀寫 map
- func foo() {
- m := map[string]int{}
- go func() {
- for {
- m["煎魚1"] = 1
- }
- }()
- for {
- _ = m["煎魚2"]
- }
- }
輸出結(jié)果：
- fatal error: concurrent map read and map write
- goroutine 1 [running]:
- runtime.throw(0x1078103, 0x21)
- ...
堆棧內(nèi)存耗盡
- func foo() {
- var f func(a [1000]int64)
- f = func(a [1000]int64) {
- f(a)
- }
- f([1000]int64{})
- }
輸出結(jié)果：
- 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 函數(shù)作為 goroutine 啟動(dòng)
- func foo() {
- var f func()
- go f()
- }
輸出結(jié)果：
- fatal error: go of nil func value
- goroutine 1 [running]:
- main.foo()
- ...
goroutines 死鎖
- func foo() {
- select {}
- }
輸出結(jié)果：
- fatal error: all goroutines are asleep - deadlock!
- goroutine 1 [select (no cases)]:
- main.foo()
- ...
線程限制耗盡
如果你的 goroutines 被 IO 操作阻塞了，新的線程可能會(huì)被啟動(dòng)來執(zhí)行你的其他 goroutines。
Go 的最大的線程數(shù)是有默認(rèn)限制的，如果達(dá)到了這個(gè)限制，你的應(yīng)用程序就會(huì)崩潰。
會(huì)出現(xiàn)如下輸出結(jié)果：
- fatal error: thread exhaustion
- ...
可以通過調(diào)用 runtime.SetMaxThreads 方法增大線程數(shù)，不過也需要考量是否程序有問題。
超出可用內(nèi)存
如果你執(zhí)行的操作，例如：下載大文件等。導(dǎo)致應(yīng)用程序占用內(nèi)存過大，程序上漲，導(dǎo)致 OOM。
會(huì)出現(xiàn)如下輸出結(jié)果：
- fatal error: runtime: out of memory
- ...
建議處理掉一些程序，或者換新電腦了。
總結(jié)
在今天這篇文章中，我們介紹了 Go 語(yǔ)言的三種錯(cuò)誤類型。其中針對(duì)大家最少見，但一碰到就很容易翻車的致命錯(cuò)誤 fatal error 進(jìn)行了介紹，給出了一些經(jīng)典案例。
希望大家后續(xù)能夠規(guī)避，你有沒有遇到過其中的場(chǎng)景?
歡迎在評(píng)論區(qū)交流和留言：)
參考
Are all runtime errors recoverable in Go?
