深度细节 | Go panic 的三种触发方式-技术圈

坚持思考，就会很酷

为什么 panic 值得思考？

初学 Go 的时候，心里常常很多疑问，有时候看似懂了的问题，其实是是而非。

panic 究竟是啥？看似显而易见的问题，但是却回答不出个所以然来。奇伢分两个章节来彻底搞懂 panic 的知识：

姿势篇：摸清楚 panic 的诞生，它不是石头里蹦出来的，总结有三种姿势；
原理篇：彻底搞明白 panic 的内部原理，理解 panic 的深层原理；

panic 的三种姿势

什么时候会产生 panic ？

我们先从“形”来学习。从程序猿的角度来看，可以分为主动和被动方式，被动的方式有两种，如下：

主动方式：

程序猿主动调用 panic( ) 函数；

被动的方式：

编译器的隐藏代码触发；
内核发送给进程信号触发；

编译器的隐藏代码

Go 之所以简单又强大，编译器居功至伟。非常多的事情是编译器帮程序猿做了的，逻辑补充，内存的逃逸分析等等。

包括 panic 的抛出！

举个非常典型的例子：整数算法除零会发生 panic，怎么做到的？

看一段极简代码：

func divzero(a, b int) int {
    c := a/b
    return c
}

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

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 ，你就能看到秘密了。奇伢截取部分汇编，并备注了下：

 (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 的代码。

如果 b == 0 ，那么跳转执行函数 runtime.panicdivide ；

再来看一眼 panicdivide 函数，这是一段极简的封装：

// runtime/panic.go
func panicdivide() {
    panicCheck2("integer divide by zero")
    panic(divideError)
}

看到了不，这里面调用的就是 panic() 函数。

除零触发的 panic 就是这样来的，它不是石头里蹦出来的，而是编译器多加的逻辑判断保证了除数为 0 的时候，触发 panic 函数。

划重点：编译器加的隐藏逻辑，调用了抛出 panic 的函数。Go 的编译器才是真大佬！

进程信号触发

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

看一个极简的例子：

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

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

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 函数：

// 信号处理函数回调
sigtramp （纯汇编代码）
  -> sigtrampgo （ signal_unix.go ）
    -> sighandler  （ signal_sighandler.go ）
       -> preparePanic （ signal_amd64x.go ）

          -> sigpanic （ signal_unix.go ）
            -> panicmem 
              -> panic (内存段错误)

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

panicmem 和 panicdivide 类似，都是对 panic( ) 的极简封装：

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

划重点：这种方式是通过信号软中断的方式来走到 Go 注册的信号处理逻辑，从而调用到 panic( ) 的函数。

童鞋可能会好奇，信号处理的逻辑什么时候注册进去的？

在进程初始化的时候，创建 M0（线程）的时候用系统调用 sigaction 给信号注册处理函数为 sigtramp ，调用栈如下：

mstartm0 （proc.go）
    -> initsig (signal_unix.go:113)
        -> setsig （os_linux.go）

这样的话，以后触发了信号软中断，就能调用到 Go 的信号处理函数，从而进行语言层面的 panic 处理。

总的来说，这个是从系统层面到特定语言层面的处理转变。

程序猿主动

第三种方式，就是程序猿自己主动调用 panic 抛出来的。

func main() {
    panic("panic test")
}

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

聊聊 panic 到底是什么？

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

panic 发生之后，如果 Go 不做任何特殊处理，默认行为是打印堆栈，退出程序。

现在回到最本源的问题：panic 到底是什么？

这里不纠结概念，只描述几个简单的事实：

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

什么叫做 panic( ) 的对应的处理？

循环执行 goroutine 上面的 _defer 函数链，如果执行完了都还没有恢复 _panic 的状态，那就没得办法了，退出进程，打印堆栈。

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

所以，panic 是什么？

小奇伢认为，它就是个特殊函数调用，仅此而已。

有多特殊？

限于篇幅，此处不表，下篇剖析其深度原理。

给读者朋友先思考几个小问题，下次我们一起揭秘：

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

总结

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

后记

本篇姿势篇，下篇原理篇。更多干货在路上，敬请期待。点赞、在看 是对奇伢最大的支持，感谢大家！

~完～

往期推荐

Go 存储基础 — “文件”被偷偷修改？来，给它装个监控！

Go 并发编程 — 结构体多字段的原子操作

Golang 最细节篇 — 解密 defer 原理，究竟背着程序猿做了多少事情？

深入剖析 defer 原理篇 —— 函数调用的原理？

坚持思考，方向比努力更重要。关注我：奇伢云存储