Go解密:panic 出现的三种原因

panic 是什么

初学 Go 的时候,心里常常很多疑问,有时候看似懂了的问题,其实是是而非。
panic 究竟是什么?看似显而易见的问题,但是却回答不出个所以然来。今天我想彻底搞懂这个问题。

panic 的三种原因

什么时候会产生 panic ? 我们先从“形”来学习。从开发者的角度来看,可以分为主动和被动方式,被动的方式有两种,如下:
主动方式

  • 开发者主动调用 panic() 函数;
    被动的方式
  • 编译器的隐藏代码触发;
  • 内核发送给进程信号触发 ;

编译器的隐藏代码

Go 之所以简单又强大,编译器居功至伟。非常多的事情是编译器帮程序猿做了的,逻辑补充,内存的逃逸分析等等。
包括 panic 的抛出!
举个非常典型的例子:整数算法除零会发生 panic,怎么做到的?
看一段极简代码:

1
2
3
4
func divzero(a, b int) int { 
c := a/b
return c
}

上面函数就会有除零的风险,当 b 等于 0 的时候,程序就会触发 panic,然后退出,如下:

1
root@ubuntu:~/code/gopher/src/panic# ./test_zero panic: runtime error: integer divide by zero goroutine 1 [running]: main.zero(0x64, 0x0, 0x0) /root/code/gopher/src/panic/test_zero.go:6 +0x52

问题来了:程序怎么触发的 panic ?
代码面前无秘密。
可代码看不出啥呀,不就是一行 c := a/b 嘛?
汇编代码因为这段隐藏起来的逻辑,是编译器帮你加的。
用 dlv 调试断点到 divzero 函数,然后执行 disassemble ,你就能看到秘密了。截取部分汇编,并备注了下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 (dlv) disassemble
TEXT main.zero(SB) /root/code/gopher/src/panic/test_zero.go
// 判断 b 是否等于 0
test_zero.go:6 0x4aa3c1 4885c9 test rcx, rcx
// 不等于 0 就跳转到 0x4aa3c8 执行指令,否则就往下执行
test_zero.go:6 0x4aa3c4 7502 jnz 0x4aa3c8
// 执行到这里,就说明 b 是 0 值,就跳转到 0x4aa3ed ,也就是 call $runtime.panicdivide
=> test_zero.go:6 0x4aa3c6 eb25 jmp 0x4aa3ed
test_zero.go:6 0x4aa3c8 4883f9ff cmp rcx, -0x1
test_zero.go:6 0x4aa3cc 7407 jz 0x4aa3d5
test_zero.go:6 0x4aa3ce 4899 cqo
test_zero.go:6 0x4aa3d0 48f7f9 idiv rcx
// ...
test_zero.go:7 0x4aa3ec c3 ret
// 看到神奇的函数了嘛 !
test_zero.go:6 0x4aa3ed e8ee27f8ff call $runtime.panicdivide

看到秘密的函数了吗?
编译器偷偷加上了一段 if/else 的判断逻辑,并且还给加了 runtime.panicdivide 的代码。

  1. 如果 b == 0 ,那么跳转执行函数 runtime.panicdivide
    再来看一眼 panicdivide 函数,这是一段极简的封装:
1
2
3
4
5
// runtime/panic.go
func panicdivide() {
panicCheck2("integer divide by zero")
panic(divideError)
}

看到了不,这里面调用的就是 panic() 函数。
除零触发的 panic 就是这样来的,它不是石头里蹦出来的,而是编译器多加的逻辑判断保证了除数为 0 的时候,触发 panic 函数。
编译器加的隐藏逻辑,调用了抛出 panic 的函数。

进程信号触发

最典型的是非法地址访问,比如, nil 指针 访问会触发 panic,怎么做到的?

看一个极简的例子:

1
func nilptr(b *int) int { c := *b return c }

当调用 nilptr( nil ) 的时候,将会导致进程异常退出:

1
root@ubuntu:~/code/gopher/src/panic# ./test_nil panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x4aa3bc] goroutine 1 [running]: main.nilptr(0x0, 0x0) /root/code/gopher/src/panic/test_nil.go:6 +0x1c

问题来了:这里的 panic 又是怎么形成的呢?

在 Go 进程启动的时候会注册默认的信号处理程序( sigtramp

在 cpu 访问到 0 地址会触发 page fault 异常,这是一个非法地址,内核会发送 SIGSEGV 信号给进程,所以当收到 SIGSEGV 信号的时候,就会让 sigtramp 函数来处理,最终调用到 panic 函数 :

1
2
3
4
5
6
7
sigtramp (纯汇编代码) 
-> sigtrampgo ( signal_unix.go )
-> sighandler ( signal_sighandler.go )
-> preparePanic ( signal_amd64x.go )
-> sigpanic ( signal_unix.go )
-> panicmem
-> panic

sigpanic 函数中会调用到 panicmem ,在这个里面就会调用 panic 函数,从而走上了 Go 自己的 panic 之路。

panicmempanicdivide 类似,都是对 panic( ) 的极简封装:

1
2
3
4
func panicmem() {
panicCheck2("invalid memory address or nil pointer dereference")
panic(memoryError)
}

这种方式是通过信号软中断的方式来走到 Go 注册的信号处理逻辑,从而调用到 panic( ) 的函数。
gophers 可能会好奇,信号处理的逻辑什么时候注册进去的?
在进程初始化的时候,创建 M0(线程)的时候用系统调用 sigaction 给信号注册处理函数为 sigtramp ,调用栈如下:

1
2
3
mstartm0 (proc.go) 
-> initsig (signal_unix.go:113)
-> setsig (os_linux.go)

这样的话,以后触发了信号软中断,就能调用到 Go 的信号处理函数,从而进行语言层面的 panic 处理 。
总的来说,这个是从系统层面到特定语言层面的处理转变。

开发者主动panic

第三种方式,就是开发者自己主动调用 panic 抛出来的。

1
2
3
func main() { 
panic("panic test")
}

简单的函数调用,这个超简单的。

聊聊 panic 到底是什么?

现在我们摸透了 panic 产生的姿势,以上三种方式,无论哪一种都归一到 panic( ) 这个函数调用。所以有一点很明确:panic 这个东西是语言层面的处理逻辑。

panic 发生之后,如果 Go 不做任何特殊处理,默认行为是打印堆栈,退出程序。
现在回到最本源的问题:panic 到底是什么?
这里不纠结概念,只描述几个简单的事实:

  1. panic() 函数内部会产生一个关键的数据结构体 _panic ,并且挂接到 goroutine 之上;
  2. panic() 函数内部会执行 _defer 函数链条,并针对 _panic 的状态进行对应的处理

什么叫做 panic() 的对应的处理?
循环执行 goroutine 上面的 _defer 函数链,如果执行完了都还没有恢复 _panic 的状态,那就没得办法了,退出进程,打印堆栈

如果在 goroutine 的 _defer 链上,有个朋友 recover 了一下,把这个 _panic 标记成恢复,那事情就到此为止,就从这个 _defer 函数执行后续正常代码即可,走 deferreturn 的逻辑。

所以,panic 是什么 ?
它就是个特殊函数调用,仅此而已。
有多特殊?我会在下篇剖析其深度原理。可以先思考几个小问题:

  • panic 究竟是啥?是一个结构体?还是一个函数?
  • 为什么 panic 会让 Go 进程退出的 ?
  • 为什么 recover 一定要放在 defer 里面才生效?
  • 为什么 recover 已经放在 defer 里面,但是进程还是没有恢复?
  • 为什么 panic 之后,还能再 panic ?有啥影响?

总结

  1. panic 产生的三大姿势:程序猿主动,编译器辅助逻辑,软中断信号触发;
  2. 无论哪一种姿势,最终都是归一到 panic() 函数的处理,panic 只是语言层面的处理逻辑;
  3. panic 发生之后,如果不做处理,默认行为是打印 panic 原因,打印堆栈,进程退出;