golang panic关键词执行原理与代码分析

使用的go版本为 go1.21.2

首先我们写一个简单的panic调度与捕获代码

package mainfunc main() {defer func() {recover()}()panic("panic test")
}

通过go build -gcflags -S main.go获取到对应的汇编代码

可以看到当我们调度panic时，Go的编译器会将这段代码翻译为CALL runtime.gopanic(SB)
我们先来看一下panic构造体的底层源码

panic源码与解读

//代码位置 $GOROOT/src/runtime/runtime2.go L:1035type _panic struct {argp      unsafe.Pointer // 指向在 panic 运行期间执行的延迟调用参数的指针，不可移动 - liblink 工具已知其位置arg       any            // 参数link      *_panic        // panic链表pc        uintptr        // 返回到运行时的位置sp        unsafe.Pointer // 返回到运行时的栈指针位置recovered bool           // 是否已被恢复aborted   bool           // 是否已被中止goexit    bool           // 是否执行了 Goexit 函数
}

gopanic源码与解读

//代码位置 $GOROOT/src/runtime/panic.go L:826
// 实现预声明函数 panic
func gopanic(e any) {// 处理异常参数为 nil 的情况if e == nil {// 如果 debug.panicnil 不等于 1，将e设置为PanicNilError类型//if debug.panicnil.Load() != 1 {e = new(PanicNilError)} else {panicnil.IncNonDefault()}}// 获取当前的Ggp := getg()// 判断当前M上运行的G是不是当前Gif gp.m.curg != gp {print("panic: ")printany(e)print("\n")throw("panic on system stack")}// malloc过程中出现panicif gp.m.mallocing != 0 {print("panic: ")printany(e)print("\n")throw("panic during malloc")}// 禁止抢占的情况下执行 panic (!="" 保持当前G在这M运行)if gp.m.preemptoff != "" {print("panic: ")printany(e)print("\n")print("preempt off reason: ")print(gp.m.preemptoff)print("\n")throw("panic during preemptoff")}//  当初M处于锁的状态if gp.m.locks != 0 {print("panic: ")printany(e)print("\n")throw("panic holding locks")}// 定义一个panic变量var p _panicp.arg = e //这个e 就是我们panic("xxxx") 里面写的东西//将这个panic加入到G的_panic链表中去p.link = gp._panic gp._panic = (*_panic)(noescape(unsafe.Pointer(&p))) // 增加运行panic延迟计数runningPanicDefers.Add(1)// 计算 getcallerpc/getcallersp，以避免扫描 gopanic 帧addOneOpenDeferFrame(gp, getcallerpc(), unsafe.Pointer(getcallersp()))for {//逐步获取当前G中的defer调用d := gp._defer// 如果获取到的构造体为空，直接返回。if d == nil {break}// 如果当前_defer运行，将_defer从G的延迟链表移除，释放对应的_defer构造体资源，防止重复执行if d.started {if d._panic != nil {d._panic.aborted = true}d._panic = nilif !d.openDefer {d.fn = nilgp._defer = d.linkfreedefer(d)continue}}// 标记当前_defer为运行状态d.started = true// 记录_defer的panicd._panic = (*_panic)(noescape(unsafe.Pointer(&p)))done := trueif d.openDefer { //如果_defer使用了 open-coded defers（编码的延迟调用）// 运行open-coded defer函数done = runOpenDeferFrame(d) //如果当前栈下面没有其他延迟函数，则返回trueif done && !d._panic.recovered { //panic没有recoveraddOneOpenDeferFrame(gp, 0, nil)}} else {//执行对应方法//getargp返回其caller的保存callee参数的地址p.argp = unsafe.Pointer(getargp()) d.fn()}p.argp = nilif gp._defer != d {throw("bad defer entry in panic")}d._panic = nilpc := d.pcsp := unsafe.Pointer(d.sp)if done { //将_defer从G的延迟链表移除，释放对应的_defer构造体资源d.fn = nilgp._defer = d.linkfreedefer(d)}if p.recovered { //panic已经恢复gp._panic = p.link if gp._panic != nil && gp._panic.goexit && gp._panic.aborted {// A normal recover would bypass/abort the Goexit.  Instead,// we return to the processing loop of the Goexit.gp.sigcode0 = uintptr(gp._panic.sp)gp.sigcode1 = uintptr(gp._panic.pc)mcall(recovery)throw("bypassed recovery failed") // mcall should not return}runningPanicDefers.Add(-1)// 从G中获取一个_defer构造体d := gp._defervar prev *_deferif !done { //如果未执行完毕，跳过当前的帧直接执行下一个prev = dd = d.link}for d != nil {if d.started { //如果启动退出循环break}if d.openDefer { //如果使用了 open-coded defersif prev == nil { //将_defer从G的延迟链表移除释放_defergp._defer = d.link} else {prev.link = d.link}newd := d.linkfreedefer(d)d = newd} else {prev = dd = d.link}}gp._panic = p.link //上面有对应的赋值，又重新赋了一遍没啥用for gp._panic != nil && gp._panic.aborted { //循环G中的_panic链表，去掉已经被标记中止的_panicgp._panic = gp._panic.link}if gp._panic == nil { // 如果当前G没有panic, 重置信号为0gp.sig = 0}// 将恢复帧发送给recovery.gp.sigcode0 = uintptr(sp)gp.sigcode1 = pcmcall(recovery)throw("recovery failed") // mcall should not return}}// 没有更多的延迟调用，现在采用传统的 panic 方式// 由于在冻结世界之后调用任意用户代码是不安全的，// 我们调用 preprintpanics 来调用所有必要的 Error// 和 String 方法，以在 startpanic 之前准备好 panic 字符串。preprintpanics(gp._panic)fatalpanic(gp._panic) //触发致命的 panic*(*int)(nil) = 0 //为了消除编译器的错误提示
}

 当我们调度recover时，Go的编译器会将这段代码翻译为CALL runtime.gorecover(SB)

gorecover源码与解读

//代码位置 $GOROOT/src/runtime/panic.go L:1045
func gorecover(argp uintptr) any {gp := getg() //获取当前Gp := gp._panic // 从当前G中获取一个_panic// 如果G存在panic，它的状态不为中止，还未进行painc捕获，函数调用参数相同if p != nil && !p.goexit && !p.recovered && argp == uintptr(p.argp) {p.recovered = truereturn p.arg}return nil
}

总结

从上面的源码我们可以了解到panic的大致逻辑，当使用panic关键词时，将painc加入到G的_panic链表中去. 调度时 defer func() {recover()}()，会改写_painc中的recovered字段，可恢复的panic必须要recover的配合。 而且这个recover必须位于同一goroutine的直接调用链上，否则无法对 panic 进行恢复，未写完有些细节点还是没读懂，后续查阅资料补充。