Go1.23 新特性：再開后門，可以記錄未捕獲的 panic 和 throw 日志了！
大家好，我是煎魚。
今天繼續(xù)給大家分享 Go1.23 的新特性，這一輪里還是有不小有意思的驚喜的。其中不得不評本文中的這個新變化。必須得來一篇獨立話題來提一下這個事！
過去學(xué)習(xí)寫 Go 時，初學(xué)者入門的教程教一定會提到在使用 panic 時，強烈建議要使用 recover。否則在 goroutine 的場景下很容易出問題，也會導(dǎo)致記不來日志。
新版本后，終于有兜底 Go 程序崩潰的日志記錄方法了！過于感人！
快速入門
panic+recover 例子
較為標(biāo)準(zhǔn)的 panic+recover 代碼如下：
func mayPanic() {
panic("腦子進煎魚了！")
}
func main() {
defer func() {
if r := recover(); r != nil {
fmt.Println("Recovered. Error:\n", r)
}
}()
mayPanic()
fmt.Println("煎魚被燒著了")
}輸出結(jié)果：
Recovered. Error:
腦子進煎魚了！常見的錯誤場景
想法很美好，有兩個常見的錯誤的場景。很折磨人心態(tài)。
1、會有經(jīng)常會有出現(xiàn)起了 goroutine，業(yè)務(wù)程序出現(xiàn)了預(yù)料之外的場景，導(dǎo)致出現(xiàn)了 panic，也沒有 recover。此時如果外部沒有統(tǒng)一的 recover，就會導(dǎo)致業(yè)務(wù)受阻。
2、更夸張的是 Go 內(nèi)部源碼偶爾會有觸發(fā)使用 throw 函數(shù)，導(dǎo)致拋出致命錯誤的場景，最經(jīng)典的是 map 并發(fā)讀寫導(dǎo)致的致命錯誤。
如下代碼例子：
func main() {
var wg sync.WaitGroup
m := make(map[int]int)
// 寫操作
wg.Add(1)
go func() {
defer wg.Done()
for i := 0; i < 1000; i++ {
m[i] = i
}
}()
// 讀操作
wg.Add(1)
go func() {
defer wg.Done()
for i := 0; i < 1000; i++ {
_ = m[i]
}
}()
wg.Wait()
fmt.Println("煎魚收工了！")
}在運行程序結(jié)果時，會看到輸出如下結(jié)果：
煎魚收工了！只要你多運行幾次，有概率觸發(fā)以下問題：
fatal error: concurrent map read and map write
goroutine 35 [running]:
main.main.func2()
/Users/eddycjy/app/go/example/demo1/main.go:26 +0x6c
created by main.main in goroutine 1
/Users/eddycjy/app/go/example/demo1/main.go:23 +0xe8
goroutine 1 [semacquire]:
sync.runtime_Semacquire(0x140000021c0?)
/opt/homebrew/Cellar/go/1.22.6/libexec/src/runtime/sema.go:62 +0x2c
...這類致命錯誤是 recover 所無法捕獲的。也因此在產(chǎn)線環(huán)境偶爾會出現(xiàn)這類紕漏導(dǎo)致的容器重啟等問題。
問題背景
在 Go 編程中，現(xiàn)階段很難很好地統(tǒng)一捕獲 Go 程序的未知崩潰輸出。崩潰會打印到 stderr，但是 Go 程序通常會將 stdout 和 stderr 用于其他目的。
雖然將其輸出到 stderr 并沒有錯，但它會將兩個輸出混合在一起，使以后的分離更加困難。排查問題也需要查看所有大量的調(diào)試信息。
因此捕獲未知的崩潰（無論是 panic 還是 thorew）對于事后調(diào)試和發(fā)送報告很有價值。
注：尤其是在 k8s 中很多是建議輸出到 stdout、stderr 中的，這樣在發(fā)生未知崩潰時，排查起來會更麻煩。
Go1.23 debug.SetCrashOutput
Go1.23 新版本中，本次在 runtime/debug 庫中新增了 debug.SetCrashOutput 方法。
圖片
函數(shù)簽名如下：
func SetCrashOutput(f *os.File, opts CrashOptions) error代碼例子：
import (
"io"
"log"
"os"
"os/exec"
"runtime/debug"
)
func main() {
monitor()
println("煎魚下午好！！！")
// 沒有被 recover 的未知錯誤
panic("oops")
}
func monitor() {
const monitorVar = "RUNTIME_DEBUG_MONITOR"
if os.Getenv(monitorVar) != "" {
// 實際演示 debug.SetCrashOutput 設(shè)置后的邏輯
log.SetFlags(0)
log.SetPrefix("monitor: ")
crash, err := io.ReadAll(os.Stdin)
if err != nil {
log.Fatalf("failed to read from input pipe: %v", err)
}
if len(crash) == 0 {
os.Exit(0)
}
f, err := os.CreateTemp("", "*.crash")
if err != nil {
log.Fatal(err)
}
if _, err := f.Write(crash); err != nil {
log.Fatal(err)
}
if err := f.Close(); err != nil {
log.Fatal(err)
}
log.Fatalf("saved crash report at %s", f.Name())
}
// 模擬應(yīng)用程序進程，設(shè)置 debug.SetCrashOutput 值
exe, err := os.Executable()
if err != nil {
log.Fatal(err)
}
cmd := exec.Command(exe, "-test.run=ExampleSetCrashOutput_monitor")
cmd.Env = append(os.Environ(), monitorVar+"=1")
cmd.Stderr = os.Stderr
cmd.Stdout = os.Stderr
pipe, err := cmd.StdinPipe()
if err != nil {
log.Fatalf("StdinPipe: %v", err)
}
debug.SetCrashOutput(pipe.(*os.File), debug.CrashOptions{})
if err := cmd.Start(); err != nil {
log.Fatalf("can't start monitor: %v", err)
}
}輸出結(jié)果：
$ go run main.go
煎魚下午好！！！
panic: oops
goroutine 1 [running]:
main.main()
/Users/eddycjy/app/go/example/demo1/main.go:15 +0x48
exit status 2
monitor: saved crash report at /var/folders/y8/whksnvd17qn8bgs17yh_y59m0000gn/T/92172971.crash崩潰后的文件記錄：
$ cat /var/folders/y8/whksnvd17qn8bgs17yh_y59m0000gn/T/92172971.crash
panic: oops
goroutine 1 [running]:
main.main()
/Users/eddycjy/app/go/example/demo1/main.go:15 +0x48非常順利的記錄到未 recover 的 panic 導(dǎo)致的 crash 了。
總結(jié)
本次 Go1.23 在 runtime/debug 中新增了 debug.SetCrashOutput 方法來允許設(shè)置未被捕獲的錯誤、異常的日志寫入。可用于為所有 Go 進程意外崩潰構(gòu)建自動報告機制！
這個變動雖然不大，但是對于我們?nèi)粘?Go 業(yè)務(wù)工程的同學(xué)來講，是個很不錯的升級！終于打開了一個新的后門！
