用 panic-recover 做錯(cuò)誤處理？會(huì)影響 Go 程序性能的
Go 這一門編程語(yǔ)音的 if err != nil 錯(cuò)誤處理機(jī)制一直飽受爭(zhēng)議。既然爭(zhēng)議那么多，想必有很多人想出各種奇思妙計(jì)，試圖解決這個(gè)問題。
其中一個(gè)辦法是使用 panic-recover 來替代 if err != nil 來做錯(cuò)誤處理機(jī)制。
對(duì)于 Go 應(yīng)用來講，這種方式也是有一定的損耗。今天結(jié)合在網(wǎng)上看到的 The cost of Go’s panic and recover 和大家一起來看看。
Effective Java 例子
原作者 @Julien Cretel 是在閱讀經(jīng)典作品《Effective Java》中學(xué)習(xí)時(shí)，看到 Java 異常進(jìn)行控制流的示例：
try {
int i = 0;
while (true)
range[i++].climb();
} catch (ArrayIndexOutOfBoundsException e) {
}該程序的變量 i 最終會(huì)遞增到數(shù)組的長(zhǎng)度，此時(shí)如果試圖訪問索引 i 處的數(shù)組，就會(huì)引發(fā) ArrayIndexOutOfBoundsException 異常，該異常會(huì)被捕獲并立即忽略。
使用 panic/recover 做控制流
很多 Java、PHP 等其他很多編程語(yǔ)言轉(zhuǎn)過來的同學(xué)，第一次接觸 Go 時(shí)，會(huì)試圖像上述例子去尋找能做一定的 try-catch 錯(cuò)誤處理機(jī)制的例子。
而在 Go 這一門編程語(yǔ)言中，能做到的類似模式的只有 panic-recover 的機(jī)制，因此可能產(chǎn)生了一些濫用的情況。
下述是模擬 Java try-catch 示例粗略翻譯成 Go panic-recover 示例的演示，以此驗(yàn)證性能基準(zhǔn)的測(cè)試。
1、主程序：
package main
type Mountain struct {
climbed bool
}
func (m *Mountain) Climb() {
m.climbed = true
}
func main() {
mountains := make([]Mountain, 8)
ClimbAllPanicRecover(mountains)
}
func ClimbAllPanicRecover(mountains []Mountain) {
deferfunc() {
recover()
}()
for i := 0; ; i++ {
mountains[i].Climb()
}
}
func ClimbAll(mountains []Mountain) {
for i := range mountains {
mountains[i].Climb()
}
}2、基準(zhǔn)測(cè)試：
package main
import (
"fmt"
"testing"
)
var cases [][]Mountain
func init() {
for _, size := range []int{0, 1, 1e1, 1e2, 1e3, 1e4, 1e5} {
s := make([]Mountain, size)
cases = append(cases, s)
}
}
func BenchmarkClimbAll(b *testing.B) {
benchmark(b, "idiomatic", ClimbAll)
benchmark(b, "panic-recover", ClimbAllPanicRecover)
}
func benchmark(b *testing.B, impl string, climbAll func([]Mountain)) {
for _, ns := range cases {
f := func(b *testing.B) {
b.ReportAllocs()
for b.Loop() {
climbAll(ns)
}
}
desc := fmt.Sprintf("impl=%s/size=%d", impl, len(ns))
b.Run(desc, f)
}
}測(cè)試結(jié)果
從測(cè)試結(jié)果可以得知，即使是在處理小規(guī)模輸入切片時(shí)，ClimbAllPanicRecover 的性能也明顯劣于 ClimbAll 的實(shí)現(xiàn)。
如下測(cè)試報(bào)告：
? demo1 benchstat -col '/impl@(idiomatic panic-recover)' results.txt
goos: darwin
goarch: arm64
pkg: example.com/greet
cpu: Apple M3 Pro
│ idiomatic │ panic-recover │
│ sec/op │ sec/op vs base │
ClimbAll/size=0-11 1.046n ± 32% 94.320n ± 0% +8921.52% (p=0.000 n=10)
ClimbAll/size=1-11 1.612n ± 20% 94.400n ± 0% +5754.26% (p=0.000 n=10)
ClimbAll/size=10-11 4.202n ± 6% 97.565n ± 0% +2221.87% (p=0.000 n=10)
ClimbAll/size=100-11 26.69n ± 0% 120.20n ± 0% +350.36% (p=0.000 n=10)
ClimbAll/size=1000-11 255.0n ± 0% 354.8n ± 2% +39.14% (p=0.000 n=10)
ClimbAll/size=10000-11 2.479μ ± 0% 2.595μ ± 0% +4.68% (p=0.000 n=10)
ClimbAll/size=100000-11 24.72μ ± 0% 24.87μ ± 0% +0.61% (p=0.001 n=10)
geomean 60.46n 422.2n +598.25%
│ idiomatic │ panic-recover │
│ B/op │ B/op vs base │
ClimbAll/size=0-11 0.00 ± 0% 24.00 ± 0% ? (p=0.000 n=10)
ClimbAll/size=1-11 0.00 ± 0% 24.00 ± 0% ? (p=0.000 n=10)
ClimbAll/size=10-11 0.00 ± 0% 24.00 ± 0% ? (p=0.000 n=10)
ClimbAll/size=100-11 0.00 ± 0% 24.00 ± 0% ? (p=0.000 n=10)
ClimbAll/size=1000-11 0.00 ± 0% 24.00 ± 0% ? (p=0.000 n=10)
ClimbAll/size=10000-11 0.00 ± 0% 24.00 ± 0% ? (p=0.000 n=10)
ClimbAll/size=100000-11 0.00 ± 0% 24.00 ± 0% ? (p=0.000 n=10)
geomean 1 24.00 ?
1 summaries must be >0 to compute geomean
│ idiomatic │ panic-recover │
│ allocs/op │ allocs/op vs base │
ClimbAll/size=0-11 0.000 ± 0% 1.000 ± 0% ? (p=0.000 n=10)
ClimbAll/size=1-11 0.000 ± 0% 1.000 ± 0% ? (p=0.000 n=10)
ClimbAll/size=10-11 0.000 ± 0% 1.000 ± 0% ? (p=0.000 n=10)
ClimbAll/size=100-11 0.000 ± 0% 1.000 ± 0% ? (p=0.000 n=10)
ClimbAll/size=1000-11 0.000 ± 0% 1.000 ± 0% ? (p=0.000 n=10)
ClimbAll/size=10000-11 0.000 ± 0% 1.000 ± 0% ? (p=0.000 n=10)
ClimbAll/size=100000-11 0.000 ± 0% 1.000 ± 0% ? (p=0.000 n=10)
geomean 1 1.000 ?
1 summaries must be >0 to compute geomean具體差異體現(xiàn)在：
- 執(zhí)行效率差距：在小數(shù)據(jù)集場(chǎng)景下，panic/recover 的操作成本占據(jù)主導(dǎo)地位，導(dǎo)致 ClimbAllPanicRecover 運(yùn)行遲緩。在 64 位系統(tǒng)中，每次調(diào)用會(huì)產(chǎn)生 24 字節(jié)的堆內(nèi)存分配（推測(cè)源于運(yùn)行時(shí)觸發(fā)的 runtime.boundsError 邊界錯(cuò)誤）。
- 內(nèi)存管理差異：標(biāo)準(zhǔn)實(shí)現(xiàn) ClimbAll 完全避免了內(nèi)存分配，因此不會(huì)對(duì)垃圾回收機(jī)制造成額外壓力。
- 性能趨勢(shì)變化：隨著輸入切片長(zhǎng)度的增加，兩種實(shí)現(xiàn)的性能差異逐漸縮小。這是因?yàn)?panic-recover 的固定開銷被更大的計(jì)算量所稀釋，不再成為主要性能瓶頸。
為什么 Go 不支持 try-catch
Go 官方早在《Error Handling — Problem Overview[1]》提案早已明確提過，Go 官方在設(shè)計(jì)上會(huì)有意識(shí)地選擇使用顯式錯(cuò)誤結(jié)果和顯式錯(cuò)誤檢查。
結(jié)合《language: Go 2: error handling meta issue[2]》可得知，要拒絕 try-catch 關(guān)鍵字的主要原因是：
- 會(huì)涉及到額外的流程控制，因?yàn)槭褂?try 的復(fù)雜表達(dá)式，會(huì)導(dǎo)致函數(shù)意外返回。
- 在表達(dá)式層面上沒有流程控制結(jié)構(gòu)，只有 panic 關(guān)鍵字，它不只是從一個(gè)函數(shù)返回。
說白了，就是設(shè)計(jì)理念不合，加之實(shí)現(xiàn)上也不大合理。在以往的多輪討論中早已被 Go 團(tuán)隊(duì)拒絕了。
反之 Go 團(tuán)隊(duì)倒是一遍遍在回答這個(gè)問題，已經(jīng)不大耐煩了，直接都整理了 issues 版的 FAQ 了。
圖片
總結(jié)
對(duì)于 Go 這一門編程語(yǔ)言來講，if err != nil 是其提供的最基本的錯(cuò)誤處理機(jī)制。
雖然很多開發(fā)同學(xué)略感不適，但官方依然是建議在其基礎(chǔ)上做設(shè)計(jì)模式的設(shè)計(jì)和調(diào)整。這是較為推薦的。
在很多妙計(jì)中，也有像本文使用 panic-recover 的方式。但通過實(shí)際測(cè)試來講，是會(huì)明確影響性能的。
官方也明確過不推薦該類錯(cuò)誤處理機(jī)制的方式。
見仁見智了。
參考資料
[1] Error Handling — Problem Overview: https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md
[2] language: Go 2: error handling meta issue: https://github.com/golang/go/issues/40432
