Go1-23 新特性：再開後門，可以記錄未捕獲的 panic 和 throw 日誌了！
大家好，我是煎魚。
今天繼續給大家分享 Go1.23 的新特性，這一輪裏還是有不小有意思的驚喜的。其中不得不評本文中的這個新變化。必須得來一篇獨立話題來提一下這個事！
過去學習寫 Go 時，初學者入門的教程教一定會提到在使用 panic 時，強烈建議要使用 recover。否則在 goroutine 的場景下很容易出問題，也會導致記不來日誌。
新版本後，終於有兜底 Go 程序崩潰的日誌記錄方法了！過於感人！
快速入門
panic+recover 例子
較爲標準的 panic+recover 代碼如下：
func mayPanic() {
panic("腦子進煎魚了！")
}
func main() {
defer func() {
if r := recover(); r != nil {
fmt.Println("Recovered. Error:\n", r)
}
}()
mayPanic()
fmt.Println("煎魚被燒着了")
}輸出結果：
Recovered. Error:
腦子進煎魚了！常見的錯誤場景
想法很美好，有兩個常見的錯誤的場景。很折磨人心態。
1、會有經常會有出現起了 goroutine，業務程序出現了預料之外的場景，導致出現了 panic，也沒有 recover。此時如果外部沒有統一的 recover，就會導致業務受阻。
2、更誇張的是 Go 內部源碼偶爾會有觸發使用 throw 函數，導致拋出致命錯誤的場景，最經典的是 map 併發讀寫導致的致命錯誤。
如下代碼例子：
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("煎魚收工了！")
}在運行程序結果時，會看到輸出如下結果：
煎魚收工了！只要你多運行幾次，有概率觸發以下問題：
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 所無法捕獲的。也因此在產線環境偶爾會出現這類紕漏導致的容器重啓等問題。
問題背景
在 Go 編程中，現階段很難很好地統一捕獲 Go 程序的未知崩潰輸出。崩潰會打印到 stderr，但是 Go 程序通常會將 stdout 和 stderr 用於其他目的。
雖然將其輸出到 stderr 並沒有錯，但它會將兩個輸出混合在一起，使以後的分離更加困難。排查問題也需要查看所有大量的調試信息。
因此捕獲未知的崩潰（無論是 panic 還是 thorew）對於事後調試和發送報告很有價值。
注：尤其是在 k8s 中很多是建議輸出到 stdout、stderr 中的，這樣在發生未知崩潰時，排查起來會更麻煩。
Go1.23 debug.SetCrashOutput
Go1.23 新版本中，本次在 runtime/debug 庫中新增了 debug.SetCrashOutput 方法。
函數簽名如下：
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 設置後的邏輯
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())
}
// 模擬應用程序進程，設置 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)
}
}輸出結果：
$ 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 導致的 crash 了。
總結
本次 Go1.23 在 runtime/debug 中新增了 debug.SetCrashOutput 方法來允許設置未被捕獲的錯誤、異常的日誌寫入。可用於爲所有 Go 進程意外崩潰構建自動報告機制！
這個變動雖然不大，但是對於我們日常寫 Go 業務工程的同學來講，是個很不錯的升級！終於打開了一個新的後門！
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/D16riVBbnDibLueQBIQ6Pw