Go開(kāi)發(fā)中有哪幾種無(wú)法恢復(fù)的致命場(chǎng)景分析
引言
有一次事故現(xiàn)場(chǎng),在緊急恢復(fù)后,他正在排查代碼,查了好一會(huì)。我回頭一看,這錯(cuò)誤提醒很明顯就是致命錯(cuò)誤,較好定位。
但此時(shí),他竟然在查 panic-recover 是不是哪里漏了,我表示大受震驚...
今天就由煎魚(yú)給大家分享一下錯(cuò)誤類(lèi)型有哪幾種,又在什么場(chǎng)景下會(huì)觸發(fā)。
錯(cuò)誤類(lèi)型
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ò)誤類(lèi)型。
如下:
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 類(lèi)型,一般常見(jiàn)于第二個(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
如果沒(méi)有使用 recover 作為捕獲,就會(huì)導(dǎo)致程序中斷。也因此經(jīng)常被人誤以為程序中斷,就 100% 是 panic 導(dǎo)致的。
這是一個(gè)誤區(qū)。
throw
第三種是 Go 初學(xué)者經(jīng)常踩坑,也不知道的錯(cuò)誤類(lèi)型,那就是致命錯(cuò)誤 throw。
這個(gè)錯(cuò)誤類(lèi)型,在用戶(hù)側(cè)是沒(méi)法主動(dòng)調(diào)用的,均為 Go 底層自行調(diào)用的,像是大家常見(jiàn)的 map 并發(fā)讀寫(xiě),就是由此觸發(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ā)讀寫(xiě) map
func?foo()?{
?m?:=?map[string]int{}
?go?func()?{
??for?{
???m["煎魚(yú)1"]?=?1
??}
?}()
?for?{
??_?=?m["煎魚(yú)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 overflowruntime 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()
...
線(xiàn)程限制耗盡
如果你的 goroutines 被 IO 操作阻塞了,新的線(xiàn)程可能會(huì)被啟動(dòng)來(lái)執(zhí)行你的其他 goroutines。
Go 的最大的線(xiàn)程數(shù)是有默認(rèn)限制的,如果達(dá)到了這個(gè)限制,你的應(yīng)用程序就會(huì)崩潰。
會(huì)出現(xiàn)如下輸出結(jié)果:
fatal error: thread exhaustion
...
可以通過(guò)調(diào)用 runtime.SetMaxThreads 方法增大線(xiàn)程數(shù),不過(guò)也需要考量是否程序有問(wèn)題。
超出可用內(nèi)存
如果你執(zhí)行的操作,例如:下載大文件等。導(dǎo)致應(yīng)用程序占用內(nèi)存過(guò)大,程序上漲,導(dǎo)致 OOM。
會(huì)出現(xiàn)如下輸出結(jié)果:
fatal error: runtime: out of memory
...
建議處理掉一些程序,或者換新電腦了。
總結(jié)
在今天這篇文章中,我們介紹了 Go 語(yǔ)言的三種錯(cuò)誤類(lèi)型。其中針對(duì)大家最少見(jiàn),但一碰到就很容易翻車(chē)的致命錯(cuò)誤 fatal error 進(jìn)行了介紹,給出了一些經(jīng)典案例。
希望大家后續(xù)能夠規(guī)避,你有沒(méi)有遇到過(guò)其中的場(chǎng)景?
歡迎在評(píng)論區(qū)交流和留言:)
參考文獻(xiàn) Are all runtime errors recoverable in Go?
以上就是Go 有哪幾種無(wú)法恢復(fù)的致命場(chǎng)景?的詳細(xì)內(nèi)容,更多關(guān)于Go 有哪幾種無(wú)法恢復(fù)的致命場(chǎng)景?的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Golang基于文件魔數(shù)判斷文件類(lèi)型的案例代碼
這篇文章主要介紹了Golang基于文件魔數(shù)判斷文件類(lèi)型,本文介紹了基于文件魔數(shù)判斷文件類(lèi)型的方法,主要涉及如何ReadSeek讀取文件指定字節(jié)內(nèi)容,然后介紹文件魔數(shù),最后給出示例基于魔數(shù)判斷文件類(lèi)型,需要的朋友可以參考下2023-02-02
go語(yǔ)言發(fā)送smtp郵件的實(shí)現(xiàn)示例
這篇文章主要介紹了go發(fā)送smtp郵件的實(shí)現(xiàn)示例,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2020-09-09
Go語(yǔ)言中new()和 make()的區(qū)別詳解
這篇文章主要介紹了Go語(yǔ)言中new()和 make()的區(qū)別詳解,本文講解了new 的主要特性、make 的主要特性,并對(duì)它們的區(qū)別做了總結(jié),需要的朋友可以參考下2014-10-10
Go高級(jí)特性探究之處理1分鐘百萬(wàn)請(qǐng)求詳解
對(duì)于大型的互聯(lián)網(wǎng)應(yīng)用程序,如電商平臺(tái)、社交網(wǎng)絡(luò)、金融交易平臺(tái)等,每秒鐘都會(huì)收到大量的請(qǐng)求,那么Go是如何處理這些百萬(wàn)請(qǐng)求的呢,下面就來(lái)和大家詳細(xì)講講2023-06-06
golang調(diào)用藍(lán)兔支付實(shí)現(xiàn)網(wǎng)上支付功能
支付寶、微信的網(wǎng)上支付需要營(yíng)業(yè)執(zhí)照個(gè)人無(wú)法直接使用,如果個(gè)人需要實(shí)現(xiàn)網(wǎng)上支付功能,目前大部分應(yīng)該是都是依賴(lài)第三方聚合支付來(lái)實(shí)現(xiàn),本文就來(lái)介紹一下如何調(diào)用藍(lán)兔支付實(shí)現(xiàn)網(wǎng)上支付功能,有需要的可以參考下2023-09-09
Golang中String,rune和byte的相互轉(zhuǎn)換
Go語(yǔ)言中,string就是只讀的采用utf8編碼的字節(jié)切片,rune是int32的別名,代表字符的Unicode編碼,這篇文章主要介紹了Golang中String,rune和byte的相互轉(zhuǎn)換,感興趣的小伙伴可以了解一下2023-10-10
基于Golang實(shí)現(xiàn)Redis分布式鎖解決秒殺問(wèn)題
這篇文章主要給大家介紹了使用Golang實(shí)現(xiàn)Redis分布式鎖解決秒殺問(wèn)題,文中有詳細(xì)的代碼示例供大家參考,具有一定的參考價(jià)值,需要的朋友可以參考下2023-08-08

