想象一下这样的场景你精心构建的Go服务正在生产环境中平稳运行突然一个看似无害的协程因一个意外的空指针解引用而崩溃——不是优雅地返回错误而是像多米诺骨牌一样引发连锁反应导致整个服务进程瞬间崩溃。监控面板上的曲线断崖式下跌告警信息瞬间刷屏。这就是panic在分布式系统中的真实威力它不像错误那样温和而是系统级的“紧急状态”。在Go的世界里panic和recover是一对特殊而强大的工具它们处理的是那些“本不该发生”的异常情况。与许多其他语言通过异常处理机制不同Go的设计哲学明确区分了可预期的错误使用多返回值处理和不可恢复的异常panic。然而正是这种设计选择使得理解panic和recover的正确使用变得至关重要——用得好它们是系统的安全网用不好则会掩盖问题导致更隐蔽的bug。本篇文章将带你深入探索panic的本质与机制深入Go运行时理解panic如何在栈帧间传播以及它为何如此具有破坏性recover的正确使用姿势不只是语法更是设计哲学——何时该恢复何时该让程序崩溃go panic和recover的底层实现原理揭开runtime包的神秘面纱探究_panic结构体的内部表示、defer链与panic链的交互机制通过这篇文章你将不仅学会panic和recover的语法更将掌握在复杂工程实践中正确使用它们的心智模型和设计原则。这不仅仅关乎代码能否运行更关乎系统在极端情况下的韧性——毕竟真正考验系统可靠性的不是它能处理多少正常请求而是当意外发生时它能否优雅地失败并快速恢复。让我们开始这次深入Go异常处理机制的探索之旅学习如何在代码的悬崖边建立可靠的防护栏而不是在系统崩溃后收拾残局。1 使用规则1.1 panic - 程序异常终止panic是 Go 内置函数用于触发程序异常终止流程。当遇到无法继续执行的严重错误时可以调用 panic 中止当前 goroutine 的执行。panic可以由程序员显式调用panic()函数触发也可以由程序在执行时触发异常而自动抛出运行时错误如数组越界、空指针解引用、类型断言失败内置函数错误如channel被重复关闭。// 基本用法 panic(something went wrong) // 带自定义错误信息 panic(fmt.Errorf(database connection failed: %w, err)) // 使用任意类型 panic(42) // 不推荐但合法1.2 recover - 异常恢复recover是内置函数用于捕获并处理 panic防止程序崩溃。需要注意的是recover必须与 defer 配合使用recover 只在 defer 函数中有效其函数的返回值取决于panic无 panic 时返回 nil有 panic 时返回 panic 的值。同时recover只能捕获同一 goroutine内的 panic更具体的是只能捕获当前函数及其调用的子函数中的 panic。需要特别注意recover函数恢复后执行的代码点如果程序出现以下的异常是无法被捕获的并发读写map栈的大小超过上限1GB内存溢出堆内存不足以下的异常只要程序编写得当则是能被捕获的用户主动调用panic抛出的异常访问数组时下标越界范围空指针断言类型失败func safeFunction() { defer func() { if r : recover(); r ! nil { // 处理 panic log.Printf(Recovered from panic: %v, r) // 可选进行资源清理或错误上报 } }() // 可能触发 panic 的代码 riskyOperation() }1.3 注意事项panic只会触发当前 Goroutine 的defer执行下述代码时会发现main函数中的defer语句并没有执行执行的只有当前 Goroutine 中的defer。因为defer关键字对应的runtime.deferproc会将延迟调用函数与调用方所在 Goroutine 进行关联。所以当程序发生崩溃时只会调用当前 Goroutine 的延迟调用函数也是非常合理的。func main() { defer println(in main) go func() { defer println(in goroutine) panic() }() time.Sleep(1 * time.Second) } $ go run main.go in goroutine panic:...recover只有在defer中调用才会生效recover只有在发生panic之后调用才会生效。如果recover是在panic之前调用的并不满足生效的条件所以需要在defer中使用recover关键字。同时在调用recover时不能直接将其写在defer之后需要使用匿名函数。defer recover()这行代码的意思是在main函数退出时执行recover()的返回值注意这里并不是在延迟一个函数而是立即计算recover()并延迟其返回值。但是在main函数正常执行期间并没有发生panic所以此时recover()返回nil然后这个nil被延迟执行相当于延迟执行一个空操作。当panic(Not implemented!)发生时由于延迟执行的已经是recover()的结果即nil而不是recover函数本身因此它无法捕获后续的panic。func main() { defer fmt.Println(in main) if err : recover(); err ! nil { fmt.Println(err) } panic(unknown err) } $ go run main.go in main panic: unknown err goroutine 1 [running]: main.main()... exit status 2 // 这里还需要特别注意的是下述直接使用defer延迟注册recover函数也是无法正确捕捉异常的 // 一定要将其放在匿名空函数中使用 func main() { defer recover() // 无法生效 defer func() { if r : recover(); r ! nil { // do something } }() panic(Not implemented!) }panic被recover正常捕获之后在发生panic函数内部的后续代码不会被继续执行。而是会跳转至该函数调用者的函数栈帧并执行本函数的deferreturn执行本函数的defer链表以及调用者函数内部的后续代码。func test() { defer func() { if err : recover(); err ! nil { fmt.Println(err) } }() defer fmt.Println(defer func 1) panic(testing) fmt.Println(panic is recovered) // panic虽然被捕获但同一个函数内部的后续代码不会再执行 } func main() { test() // test函数内部的panic被正常捕获 fmt.Println(main func) // 继续执行后续代码 return } // 输出结果 defer func 1 testing main funcpanic允许在defer中嵌套多次调用Go 语言中的panic是可以多次嵌套调用的多次调用panic也不会影响defer函数的正常执行所以使用defer进行收尾工作一般来说都是安全的。需要注意的是panic信息会按照其发生的顺序进行嵌套打印func main() { defer fmt.Println(in main) // defer_0 defer func() { // defer_1 defer func() { defer_2 panic(panic again and again) }() panic(panic again) }() panic(panic once) } $ go run main.go in main panic: panic once panic: panic again panic: panic again and again goroutine 1 [running]:... /* 第一次 gopanic 取出 defer_1defer_1绑定panic once 注册defer_2此时defer链表中存在 defer_2 - defer_1 - defer_0 第二次 gopanic 新增一个panic此时panic链表中存在 panic again - panic once 取出defer_2defer_2绑定panic again执行defer_2 第三次 gopanic 新增一个panic此时panic链表中存在 panic again and again - panic again - panic once 取出defer_2defer_2已经绑定panic againstart true此时会将panic again标记为aborted释放defer_2 同理取出defer_1defer_1已经绑定panic oncestart true此时会将panic once标记为aborted释放defer_1 取出defer_0进行执行打印in main 执行panic链表 */如果panic发生多次嵌套那么recover捕获到的错误将只会显示最后一个panic抛出的消息前序的panic消息会被忽略可以使用debug.Stack进行追踪执行顺序。func test() { defer func() { if err : recover(); err ! nil { fmt.Println(err) // 只会打印panic第一个panic的testing消息会被忽略 fmt.Println(string(debug.Stack())) } }() defer func() { panic(panic) }() panic(testing) fmt.Println(panic is recovered) } func main() { t1() fmt.Println(main func) return } panic goroutine 1 [running]: runtime/debug.Stack() D:/Go/src/runtime/debug/stack.go:26 0x5e main.t1.func1() D:/Go_learning/dag/main.go:296 0x54 panic({0xb22180?, 0xb60628?}) D:/Go/src/runtime/panic.go:785 0x132 main.t1.func2() D:/Go_learning/dag/main.go:300 0x25 panic({0xb22180?, 0xb60608?}) D:/Go/src/runtime/panic.go:785 0x132 main.t1() D:/Go_learning/dag/main.go:303 0x4e main.main() D:/Go_learning/dag/main.go:308 0x13 main funcpainc沿调用堆栈向外传递直至被捕获或进程崩溃。连续引发恐慌仅最后一次可被捕获。先捕获panic恢复执行然后才返回panic的数据。recover之后可再度引发panic并再次被捕获。无论恢复与否延迟调用函数总会被执行。延时调用中引发的panic不影响后续延迟调用函数的执行。panic能够改变程序的控制流调用panic后会立刻停止执行当前函数的剩余代码并在当前 Goroutine 中递归执行调用方的deferrecover可以中止panic造成的程序崩溃。它是一个只能在defer中发挥作用的函数在其他作用域中调用不会发挥作用2 底层实现和defer类似每个goroutine会保存属于自己 的panic信息panic信息是抽象成_panic结构体该结构体成员主要包含panic参数、被恢复后的下一个指令地址等。需要特别注意的是虽然_panic也使用链表对其进行管理但是在最终打印panic信息时是按照panic发生的顺序依次打印的即先进先出。_panic结构体成员变量的具体含义如下argp是defer调用时传入的参数的指针。arg是调用panic时传入的参数。link指向的是更早调用runtime._panic结构也就是说painc可以被连续调用它们之间形成链表recovered表示当前runtime._panic是否被recover恢复aborted表示当前的panic是否被强行终止type g struct { // ... _panic *_panic // 当前 panic 链表头 _defer *_defer // defer 链表 } type _panic struct { argp unsafe.Pointer // pointer to arguments of deferred call run during panic; panic当前要执行的defer参数空间地址 arg interface{} // argument to panic panic 的参数 link *_panic // link to earlier panic 链接到更早的 panic pc uintptr // where to return to in runtime if this panic is bypassed sp unsafe.Pointer // where to return to in runtime if this panic is bypassed recovered bool // whether this panic is over 表示panic是否被恢复 aborted bool // the panic was aborted 表示panic是否被终止 goexit bool }当函数内部发生panic时程序底层会调用runtime.gopanic函数开始处理异常首先检查panic 发生的环境是否合法然后会创建一个_panic结构体插入到goroutine._panic链接的头部因为panic也可以嵌套发生随后便会遍历goroutine._defer链表依次调用defer注册的函数执行完后会立即释放defer结构体占用的内存。如果在某次defer中调用了recover函数则会将defer绑定的panic的recovered字段标记为true绑定的panic是gopanic新创建的链表首个panic如果defer链表中有调用的recovery函数则会恢复调用者的函数栈帧即恢复执行调用者调用发生panic函数后续的代码发生panic函数内部的后续代码不会再被执行并执行runtime.deferreturn将此时goroutine上绑定的defer全部执行完毕deferreturn函数详解可以参考Go defer一延迟调用的使用及其底层实现原理详解 如果遍历完整个defer链表还没有调用recovery函数则会调用fatalpanic函数来打印panic函数并退出程序2.1 gopanic函数编译器会将关键字panic转换成runtime.gopanic该函数的执行过程包含以下几个步骤获取当前 goroutine通过 getg() 获取当前 goroutine 的指针 gp。检查 panic 发生的环境是否合法检查是否在系统栈上触发 panicgp.m.curg ! gp如果是则抛出异常。检查是否在内存分配过程中gp.m.mallocing ! 0如果是则抛出异常。检查是否在禁止抢占期间gp.m.preemptoff ! 如果是则抛出异常并打印原因。检查是否持有锁gp.m.locks ! 0如果是则抛出异常。创建 panic 对象并添加到链表头部创建一个 _panic 结构体实例 p。设置 p.arg epanic 的参数。将新的 panic 插入到当前 goroutine 的 panic 链表头部gp._panic 指向新创建的 panic。增加正在处理的 panic defer 计数器通过 atomic.Xadd(runningPanicDefers, 1) 原子增加计数器。处理 open-coded defer 帧如果有调用 addOneOpenDeferFrame 记录 open-coded defer 的相关信息。循环处理 defer 函数从当前 goroutine 的 defer 链表头部开始遍历 defer 函数gp._defer。如果 defer 链表为空d nil跳出循环终止程序。如果当前 defer 已经执行过d.started 为 true说明发生了 panic 嵌套需要清理早期的panic将不会被执行如果该 defer 关联了 panic标记该 panic 为已终止aborted true。将该 defer 的 panic 关联置空d._panic nil。如果不是 open-coded defer则释放该 defer 并继续处理下一个 defer。标记当前 defer 为已开始d.started true用于标记panic是否出现了嵌套。将当前 panic 关联到 deferd._panic p。执行 defer 函数如果是 open-coded defer调用 runOpenDeferFrame 执行 defer 函数并返回是否完成。否则普通 defer设置当前 panic 的参数指针p.argp unsafe.Pointer(getargp(0))。通过 reflectcall 调用 defer 函数。执行完成后清理 defer将 defer 的 panic 关联置空d._panic nil。如果执行完成done 为 true则释放 defer 资源freedefer(d)并从链表中移除。检查 panic 是否被恢复如果 p.recovered 为 true说明在 defer 中调用了 recover 并成功恢复调用 mcall(recovery) 切换到恢复执行流程该函数会调度到m-g0进行执行且不会返回设置恢复的上下文信息gp.sigcode0 和 gp.sigcode1这里恢复执行的位置是调用者的函数栈帧信息调用方函数返回之前并执行deferreturn。清理剩余的 defer 条目特别是未开始的 open-coded defer。处理一些特殊情况如 Goexit 的恢复。从 panic 链表中移除当前 panicgp._panic p.link之前的panic也会被直接移除同时将panic链表上所有标记aborted的panic结构体删除。所有 defer 处理完毕但 panic 未被恢复调用 preprintpanics 准备 panic 的字符串信息调用 Error 或 String 方法。调用 fatalpanic 终止程序打印 panic 信息和堆栈跟踪。最后执行一个非法操作*(*int)(nil) 0确保程序崩溃实际上 fatalpanic 不会返回。// The implementation of the predeclared function panic. func gopanic(e interface{}) { gp : getg() if gp.m.curg ! gp { print(panic: ) printany(e) print(\n) throw(panic on system stack) } if gp.m.mallocing ! 0 { print(panic: ) printany(e) print(\n) throw(panic during malloc) } if gp.m.preemptoff ! { print(panic: ) printany(e) print(\n) print(preempt off reason: ) print(gp.m.preemptoff) print(\n) throw(panic during preemptoff) } if gp.m.locks ! 0 { print(panic: ) printany(e) print(\n) throw(panic holding locks) } //panic可以嵌套比如发生了panic之后运行defered函数又发生了panic。 //最新的panic会被挂入goroutine对应的g结构体对象的_panic链表的表头 var p _panic // 创建_panic结构体对象 p.arg e // panic的参数 p.link gp._panic // 保存下一个panic的地址 gp._panic (*_panic)(noescape(unsafe.Pointer(p))) // 将此panic插入链表头部 atomic.Xadd(runningPanicDefers, 1) // By calculating getcallerpc/getcallersp here, we avoid scanning the // gopanic frame (stack scanning is slow...) addOneOpenDeferFrame(gp, getcallerpc(), unsafe.Pointer(getcallersp())) for { d : gp._defer // 取出当前groutine的_defer链表头部的defered函数 if d nil { break //没有defer函数将会跳出循环然后打印栈信息然后结束程序panic没有被恢复 } // If defer was started by earlier panic or Goexit (and, since were back here, that triggered a new panic), // take defer off list. An earlier panic will not continue running, but we will make sure below that an // earlier Goexit does continue running. if d.started { //到这里一定发生了panic嵌套即在defered函数中又发生了panic //d.started true是panic嵌套的充分条件但并不是必要条件也就是说即使d.started为false也是可能发生嵌套的 //最近发生的一次panic并没有被recover所以取消上一次发生的panic if d._panic ! nil { d._panic.aborted true } d._panic nil if !d.openDefer { // For open-coded defers, we need to process the // defer again, in case there are any other defers // to call in the frame (not including the defer // call that caused the panic). d.fn nil gp._defer d.link freedefer(d) continue } } // Mark defer as started, but keep on list, so that traceback // can find and update the defers argument frame if stack growth // or a garbage collection happens before reflectcall starts executing d.fn. d.started true // 用于判断是否发生了嵌套panic // Record the panic that is running the defer. // If there is a new panic during the deferred call, that panic // will find d in the list and will mark d._panic (this panic) aborted. // 设置_defer结构体的_panic参数 d._panic (*_panic)(noescape(unsafe.Pointer(p))) done : true if d.openDefer { done runOpenDeferFrame(gp, d) if done !d._panic.recovered { addOneOpenDeferFrame(gp, 0, nil) } } else { //在panic中记录当前panic的栈顶位置用于recover判断 p.argp unsafe.Pointer(getargp(0)) //通过reflectcall函数调用defered函数 //如果defered函数再次发生panic而且并未被该defered函数recover则reflectcall永远不会返回 //如果defered函数并没有发生过panic或者发生了panic但该defered函数成功recover了新发生的panic // 则此函数会返回继续执行后面的代码。 reflectcall(nil, unsafe.Pointer(d.fn), deferArgs(d), uint32(d.siz), uint32(d.siz)) } p.argp nil // reflectcall did not panic. Remove d. if gp._defer ! d { throw(bad defer entry in panic) } d._panic nil // trigger shrinkage to test stack copy. See stack_test.go:TestStackPanic //GC() pc : d.pc sp : unsafe.Pointer(d.sp) // must be pointer so it gets adjusted during stack copy // 将执行完的defer函数释放 if done { d.fn nil gp._defer d.link freedefer(d) } //defered函数调用recover成功捕获了panic会设置p.recovered true if p.recovered { 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 } atomic.Xadd(runningPanicDefers, -1) // Remove any remaining non-started, open-coded // defer entries after a recover, since the // corresponding defers will be executed normally // (inline). Any such entry will become stale once // we run the corresponding defers inline and exit // the associated stack frame. d : gp._defer var prev *_defer if !done { // Skip our current frame, if not done. It is // needed to complete any remaining defers in // deferreturn() prev d d d.link } for d ! nil { if d.started { // This defer is started but we // are in the middle of a // defer-panic-recover inside of // it, so dont remove it or any // further defer entries break } if d.openDefer { if prev nil { gp._defer d.link } else { prev.link d.link } newd : d.link freedefer(d) d newd } else { prev d d d.link } } gp._panic p.link // Aborted panics are marked but remain on the g.panic list. // Remove them from the list. for gp._panic ! nil gp._panic.aborted { gp._panic gp._panic.link } if gp._panic nil { // must be done with signal gp.sig 0 } // Pass information about recovering frame to recovery. gp.sigcode0 uintptr(sp) gp.sigcode1 pc mcall(recovery) throw(recovery failed) // mcall should not return } } // ran out of deferred calls - old-school panic now // Because it is unsafe to call arbitrary user code after freezing // the world, we call preprintpanics to invoke all necessary Error // and String methods to prepare the panic strings before startpanic. preprintpanics(gp._panic) // 终止整个程序 fatalpanic(gp._panic) // should not return *(*int)(nil) 0 // not reached }2.2 gorecover函数该函数的实现很简单如果当前 Goroutine 没有调用panic那么该函数会直接返回nil这也是崩溃恢复在非defer中调用会失效的原因。在正常情况下它会修改runtime._panic的recovered字段recover函数仅仅改变了当前groutine第一个panic对象的recovered的值runtime.gorecover函数中并不包含恢复程序的逻辑程序的恢复是由runtime.gopanic函数负责的。// The implementation of the predeclared function recover. // Cannot split the stack because it needs to reliably // find the stack segment of its caller. // // TODO(rsc): Once we commit to CopyStackAlways, // this doesnt need to be nosplit. //go:nosplit func gorecover(argp uintptr) interface{} { // Must be in a function running as part of a deferred call during the panic. // Must be called from the topmost function of the call // (the function used in the defer statement). // p.argp is the argument pointer of that topmost deferred function call. // Compare against argp reported by caller. // If they match, the caller is the one who can recover. gp : getg() p : gp._panic if p ! nil !p.goexit !p.recovered argp uintptr(p.argp) { p.recovered true return p.arg } return nil } // Unwind the stack after a deferred function calls recover // after a panic. Then arrange to continue running as though // the caller of the deferred function returned normally. func recovery(gp *g) { // Info about defer passed in G struct. sp : gp.sigcode0 pc : gp.sigcode1 // ds arguments need to be in the stack. if sp ! 0 (sp gp.stack.lo || gp.stack.hi sp) { print(recover: , hex(sp), not in [, hex(gp.stack.lo), , , hex(gp.stack.hi), ]\n) throw(bad recovery) } // Make the deferproc for this d return again, // this time returning 1. The calling function will // jump to the standard return epilogue. gp.sched.sp sp gp.sched.pc pc gp.sched.lr 0 gp.sched.ret 1 gogo(gp.sched) }2.3 嵌套流程浅析func main() { defer fmt.Println(in main) // defer_0 defer func() { // defer_1 defer func() { // defer_2 panic(panic again and again) // panic_3 }() fmt.Println(step 2) panic(panic again) // panic_2 }() defer func() { // defer_3 recover() }() panic(panic once) // panic_0 panic(panic 1) // panic_1不会被执行 } // 上述程序执行的结果如下 step 2 in main panic: panic again panic: panic again and again /* main gopanic // 第一次panic(panic once)触发 1. 取出 defer_3设置 started 2. 执行 defer_3 - 执行 recoverpanic_0 字段被设置 recovered 3. 把 defer_3 从链表中摘掉 4. 把panic_0 从链表中摘掉 4. 执行 recovery 重置 pc 寄存器跳转到 defer_0 注册时候携带的指令一般是跳转到 deferreturn 上面几个指令 // 跳出 gopanic 的递归嵌套执行到 deferreturn 的地方 defereturn 1. 遍历 defer 函数链取出 defer_1设置 started 2. 执行 defer_1注册defer_2打印 step 2 gopanic // 第二次 1. 取出defer_1因为started已经被标记为true需要执行后摘掉 2. panic_2.aborted true 3. 遍历defer取出defer_2设置 started gopanic // 第三次 1. defer_2 已经被标记started所以执行后摘掉 2. panic_2.aborted true 3. 摘掉 defer_0打印in main链表为空跳出 for 循环 4. 执行 fatalpanic - exit(2) 退出进程 */
Go panic recover：深入Go语言的异常拯救之道
发布时间：2026/7/6 20:13:01
想象一下这样的场景你精心构建的Go服务正在生产环境中平稳运行突然一个看似无害的协程因一个意外的空指针解引用而崩溃——不是优雅地返回错误而是像多米诺骨牌一样引发连锁反应导致整个服务进程瞬间崩溃。监控面板上的曲线断崖式下跌告警信息瞬间刷屏。这就是panic在分布式系统中的真实威力它不像错误那样温和而是系统级的“紧急状态”。在Go的世界里panic和recover是一对特殊而强大的工具它们处理的是那些“本不该发生”的异常情况。与许多其他语言通过异常处理机制不同Go的设计哲学明确区分了可预期的错误使用多返回值处理和不可恢复的异常panic。然而正是这种设计选择使得理解panic和recover的正确使用变得至关重要——用得好它们是系统的安全网用不好则会掩盖问题导致更隐蔽的bug。本篇文章将带你深入探索panic的本质与机制深入Go运行时理解panic如何在栈帧间传播以及它为何如此具有破坏性recover的正确使用姿势不只是语法更是设计哲学——何时该恢复何时该让程序崩溃go panic和recover的底层实现原理揭开runtime包的神秘面纱探究_panic结构体的内部表示、defer链与panic链的交互机制通过这篇文章你将不仅学会panic和recover的语法更将掌握在复杂工程实践中正确使用它们的心智模型和设计原则。这不仅仅关乎代码能否运行更关乎系统在极端情况下的韧性——毕竟真正考验系统可靠性的不是它能处理多少正常请求而是当意外发生时它能否优雅地失败并快速恢复。让我们开始这次深入Go异常处理机制的探索之旅学习如何在代码的悬崖边建立可靠的防护栏而不是在系统崩溃后收拾残局。1 使用规则1.1 panic - 程序异常终止panic是 Go 内置函数用于触发程序异常终止流程。当遇到无法继续执行的严重错误时可以调用 panic 中止当前 goroutine 的执行。panic可以由程序员显式调用panic()函数触发也可以由程序在执行时触发异常而自动抛出运行时错误如数组越界、空指针解引用、类型断言失败内置函数错误如channel被重复关闭。// 基本用法 panic(something went wrong) // 带自定义错误信息 panic(fmt.Errorf(database connection failed: %w, err)) // 使用任意类型 panic(42) // 不推荐但合法1.2 recover - 异常恢复recover是内置函数用于捕获并处理 panic防止程序崩溃。需要注意的是recover必须与 defer 配合使用recover 只在 defer 函数中有效其函数的返回值取决于panic无 panic 时返回 nil有 panic 时返回 panic 的值。同时recover只能捕获同一 goroutine内的 panic更具体的是只能捕获当前函数及其调用的子函数中的 panic。需要特别注意recover函数恢复后执行的代码点如果程序出现以下的异常是无法被捕获的并发读写map栈的大小超过上限1GB内存溢出堆内存不足以下的异常只要程序编写得当则是能被捕获的用户主动调用panic抛出的异常访问数组时下标越界范围空指针断言类型失败func safeFunction() { defer func() { if r : recover(); r ! nil { // 处理 panic log.Printf(Recovered from panic: %v, r) // 可选进行资源清理或错误上报 } }() // 可能触发 panic 的代码 riskyOperation() }1.3 注意事项panic只会触发当前 Goroutine 的defer执行下述代码时会发现main函数中的defer语句并没有执行执行的只有当前 Goroutine 中的defer。因为defer关键字对应的runtime.deferproc会将延迟调用函数与调用方所在 Goroutine 进行关联。所以当程序发生崩溃时只会调用当前 Goroutine 的延迟调用函数也是非常合理的。func main() { defer println(in main) go func() { defer println(in goroutine) panic() }() time.Sleep(1 * time.Second) } $ go run main.go in goroutine panic:...recover只有在defer中调用才会生效recover只有在发生panic之后调用才会生效。如果recover是在panic之前调用的并不满足生效的条件所以需要在defer中使用recover关键字。同时在调用recover时不能直接将其写在defer之后需要使用匿名函数。defer recover()这行代码的意思是在main函数退出时执行recover()的返回值注意这里并不是在延迟一个函数而是立即计算recover()并延迟其返回值。但是在main函数正常执行期间并没有发生panic所以此时recover()返回nil然后这个nil被延迟执行相当于延迟执行一个空操作。当panic(Not implemented!)发生时由于延迟执行的已经是recover()的结果即nil而不是recover函数本身因此它无法捕获后续的panic。func main() { defer fmt.Println(in main) if err : recover(); err ! nil { fmt.Println(err) } panic(unknown err) } $ go run main.go in main panic: unknown err goroutine 1 [running]: main.main()... exit status 2 // 这里还需要特别注意的是下述直接使用defer延迟注册recover函数也是无法正确捕捉异常的 // 一定要将其放在匿名空函数中使用 func main() { defer recover() // 无法生效 defer func() { if r : recover(); r ! nil { // do something } }() panic(Not implemented!) }panic被recover正常捕获之后在发生panic函数内部的后续代码不会被继续执行。而是会跳转至该函数调用者的函数栈帧并执行本函数的deferreturn执行本函数的defer链表以及调用者函数内部的后续代码。func test() { defer func() { if err : recover(); err ! nil { fmt.Println(err) } }() defer fmt.Println(defer func 1) panic(testing) fmt.Println(panic is recovered) // panic虽然被捕获但同一个函数内部的后续代码不会再执行 } func main() { test() // test函数内部的panic被正常捕获 fmt.Println(main func) // 继续执行后续代码 return } // 输出结果 defer func 1 testing main funcpanic允许在defer中嵌套多次调用Go 语言中的panic是可以多次嵌套调用的多次调用panic也不会影响defer函数的正常执行所以使用defer进行收尾工作一般来说都是安全的。需要注意的是panic信息会按照其发生的顺序进行嵌套打印func main() { defer fmt.Println(in main) // defer_0 defer func() { // defer_1 defer func() { defer_2 panic(panic again and again) }() panic(panic again) }() panic(panic once) } $ go run main.go in main panic: panic once panic: panic again panic: panic again and again goroutine 1 [running]:... /* 第一次 gopanic 取出 defer_1defer_1绑定panic once 注册defer_2此时defer链表中存在 defer_2 - defer_1 - defer_0 第二次 gopanic 新增一个panic此时panic链表中存在 panic again - panic once 取出defer_2defer_2绑定panic again执行defer_2 第三次 gopanic 新增一个panic此时panic链表中存在 panic again and again - panic again - panic once 取出defer_2defer_2已经绑定panic againstart true此时会将panic again标记为aborted释放defer_2 同理取出defer_1defer_1已经绑定panic oncestart true此时会将panic once标记为aborted释放defer_1 取出defer_0进行执行打印in main 执行panic链表 */如果panic发生多次嵌套那么recover捕获到的错误将只会显示最后一个panic抛出的消息前序的panic消息会被忽略可以使用debug.Stack进行追踪执行顺序。func test() { defer func() { if err : recover(); err ! nil { fmt.Println(err) // 只会打印panic第一个panic的testing消息会被忽略 fmt.Println(string(debug.Stack())) } }() defer func() { panic(panic) }() panic(testing) fmt.Println(panic is recovered) } func main() { t1() fmt.Println(main func) return } panic goroutine 1 [running]: runtime/debug.Stack() D:/Go/src/runtime/debug/stack.go:26 0x5e main.t1.func1() D:/Go_learning/dag/main.go:296 0x54 panic({0xb22180?, 0xb60628?}) D:/Go/src/runtime/panic.go:785 0x132 main.t1.func2() D:/Go_learning/dag/main.go:300 0x25 panic({0xb22180?, 0xb60608?}) D:/Go/src/runtime/panic.go:785 0x132 main.t1() D:/Go_learning/dag/main.go:303 0x4e main.main() D:/Go_learning/dag/main.go:308 0x13 main funcpainc沿调用堆栈向外传递直至被捕获或进程崩溃。连续引发恐慌仅最后一次可被捕获。先捕获panic恢复执行然后才返回panic的数据。recover之后可再度引发panic并再次被捕获。无论恢复与否延迟调用函数总会被执行。延时调用中引发的panic不影响后续延迟调用函数的执行。panic能够改变程序的控制流调用panic后会立刻停止执行当前函数的剩余代码并在当前 Goroutine 中递归执行调用方的deferrecover可以中止panic造成的程序崩溃。它是一个只能在defer中发挥作用的函数在其他作用域中调用不会发挥作用2 底层实现和defer类似每个goroutine会保存属于自己 的panic信息panic信息是抽象成_panic结构体该结构体成员主要包含panic参数、被恢复后的下一个指令地址等。需要特别注意的是虽然_panic也使用链表对其进行管理但是在最终打印panic信息时是按照panic发生的顺序依次打印的即先进先出。_panic结构体成员变量的具体含义如下argp是defer调用时传入的参数的指针。arg是调用panic时传入的参数。link指向的是更早调用runtime._panic结构也就是说painc可以被连续调用它们之间形成链表recovered表示当前runtime._panic是否被recover恢复aborted表示当前的panic是否被强行终止type g struct { // ... _panic *_panic // 当前 panic 链表头 _defer *_defer // defer 链表 } type _panic struct { argp unsafe.Pointer // pointer to arguments of deferred call run during panic; panic当前要执行的defer参数空间地址 arg interface{} // argument to panic panic 的参数 link *_panic // link to earlier panic 链接到更早的 panic pc uintptr // where to return to in runtime if this panic is bypassed sp unsafe.Pointer // where to return to in runtime if this panic is bypassed recovered bool // whether this panic is over 表示panic是否被恢复 aborted bool // the panic was aborted 表示panic是否被终止 goexit bool }当函数内部发生panic时程序底层会调用runtime.gopanic函数开始处理异常首先检查panic 发生的环境是否合法然后会创建一个_panic结构体插入到goroutine._panic链接的头部因为panic也可以嵌套发生随后便会遍历goroutine._defer链表依次调用defer注册的函数执行完后会立即释放defer结构体占用的内存。如果在某次defer中调用了recover函数则会将defer绑定的panic的recovered字段标记为true绑定的panic是gopanic新创建的链表首个panic如果defer链表中有调用的recovery函数则会恢复调用者的函数栈帧即恢复执行调用者调用发生panic函数后续的代码发生panic函数内部的后续代码不会再被执行并执行runtime.deferreturn将此时goroutine上绑定的defer全部执行完毕deferreturn函数详解可以参考Go defer一延迟调用的使用及其底层实现原理详解 如果遍历完整个defer链表还没有调用recovery函数则会调用fatalpanic函数来打印panic函数并退出程序2.1 gopanic函数编译器会将关键字panic转换成runtime.gopanic该函数的执行过程包含以下几个步骤获取当前 goroutine通过 getg() 获取当前 goroutine 的指针 gp。检查 panic 发生的环境是否合法检查是否在系统栈上触发 panicgp.m.curg ! gp如果是则抛出异常。检查是否在内存分配过程中gp.m.mallocing ! 0如果是则抛出异常。检查是否在禁止抢占期间gp.m.preemptoff ! 如果是则抛出异常并打印原因。检查是否持有锁gp.m.locks ! 0如果是则抛出异常。创建 panic 对象并添加到链表头部创建一个 _panic 结构体实例 p。设置 p.arg epanic 的参数。将新的 panic 插入到当前 goroutine 的 panic 链表头部gp._panic 指向新创建的 panic。增加正在处理的 panic defer 计数器通过 atomic.Xadd(runningPanicDefers, 1) 原子增加计数器。处理 open-coded defer 帧如果有调用 addOneOpenDeferFrame 记录 open-coded defer 的相关信息。循环处理 defer 函数从当前 goroutine 的 defer 链表头部开始遍历 defer 函数gp._defer。如果 defer 链表为空d nil跳出循环终止程序。如果当前 defer 已经执行过d.started 为 true说明发生了 panic 嵌套需要清理早期的panic将不会被执行如果该 defer 关联了 panic标记该 panic 为已终止aborted true。将该 defer 的 panic 关联置空d._panic nil。如果不是 open-coded defer则释放该 defer 并继续处理下一个 defer。标记当前 defer 为已开始d.started true用于标记panic是否出现了嵌套。将当前 panic 关联到 deferd._panic p。执行 defer 函数如果是 open-coded defer调用 runOpenDeferFrame 执行 defer 函数并返回是否完成。否则普通 defer设置当前 panic 的参数指针p.argp unsafe.Pointer(getargp(0))。通过 reflectcall 调用 defer 函数。执行完成后清理 defer将 defer 的 panic 关联置空d._panic nil。如果执行完成done 为 true则释放 defer 资源freedefer(d)并从链表中移除。检查 panic 是否被恢复如果 p.recovered 为 true说明在 defer 中调用了 recover 并成功恢复调用 mcall(recovery) 切换到恢复执行流程该函数会调度到m-g0进行执行且不会返回设置恢复的上下文信息gp.sigcode0 和 gp.sigcode1这里恢复执行的位置是调用者的函数栈帧信息调用方函数返回之前并执行deferreturn。清理剩余的 defer 条目特别是未开始的 open-coded defer。处理一些特殊情况如 Goexit 的恢复。从 panic 链表中移除当前 panicgp._panic p.link之前的panic也会被直接移除同时将panic链表上所有标记aborted的panic结构体删除。所有 defer 处理完毕但 panic 未被恢复调用 preprintpanics 准备 panic 的字符串信息调用 Error 或 String 方法。调用 fatalpanic 终止程序打印 panic 信息和堆栈跟踪。最后执行一个非法操作*(*int)(nil) 0确保程序崩溃实际上 fatalpanic 不会返回。// The implementation of the predeclared function panic. func gopanic(e interface{}) { gp : getg() if gp.m.curg ! gp { print(panic: ) printany(e) print(\n) throw(panic on system stack) } if gp.m.mallocing ! 0 { print(panic: ) printany(e) print(\n) throw(panic during malloc) } if gp.m.preemptoff ! { print(panic: ) printany(e) print(\n) print(preempt off reason: ) print(gp.m.preemptoff) print(\n) throw(panic during preemptoff) } if gp.m.locks ! 0 { print(panic: ) printany(e) print(\n) throw(panic holding locks) } //panic可以嵌套比如发生了panic之后运行defered函数又发生了panic。 //最新的panic会被挂入goroutine对应的g结构体对象的_panic链表的表头 var p _panic // 创建_panic结构体对象 p.arg e // panic的参数 p.link gp._panic // 保存下一个panic的地址 gp._panic (*_panic)(noescape(unsafe.Pointer(p))) // 将此panic插入链表头部 atomic.Xadd(runningPanicDefers, 1) // By calculating getcallerpc/getcallersp here, we avoid scanning the // gopanic frame (stack scanning is slow...) addOneOpenDeferFrame(gp, getcallerpc(), unsafe.Pointer(getcallersp())) for { d : gp._defer // 取出当前groutine的_defer链表头部的defered函数 if d nil { break //没有defer函数将会跳出循环然后打印栈信息然后结束程序panic没有被恢复 } // If defer was started by earlier panic or Goexit (and, since were back here, that triggered a new panic), // take defer off list. An earlier panic will not continue running, but we will make sure below that an // earlier Goexit does continue running. if d.started { //到这里一定发生了panic嵌套即在defered函数中又发生了panic //d.started true是panic嵌套的充分条件但并不是必要条件也就是说即使d.started为false也是可能发生嵌套的 //最近发生的一次panic并没有被recover所以取消上一次发生的panic if d._panic ! nil { d._panic.aborted true } d._panic nil if !d.openDefer { // For open-coded defers, we need to process the // defer again, in case there are any other defers // to call in the frame (not including the defer // call that caused the panic). d.fn nil gp._defer d.link freedefer(d) continue } } // Mark defer as started, but keep on list, so that traceback // can find and update the defers argument frame if stack growth // or a garbage collection happens before reflectcall starts executing d.fn. d.started true // 用于判断是否发生了嵌套panic // Record the panic that is running the defer. // If there is a new panic during the deferred call, that panic // will find d in the list and will mark d._panic (this panic) aborted. // 设置_defer结构体的_panic参数 d._panic (*_panic)(noescape(unsafe.Pointer(p))) done : true if d.openDefer { done runOpenDeferFrame(gp, d) if done !d._panic.recovered { addOneOpenDeferFrame(gp, 0, nil) } } else { //在panic中记录当前panic的栈顶位置用于recover判断 p.argp unsafe.Pointer(getargp(0)) //通过reflectcall函数调用defered函数 //如果defered函数再次发生panic而且并未被该defered函数recover则reflectcall永远不会返回 //如果defered函数并没有发生过panic或者发生了panic但该defered函数成功recover了新发生的panic // 则此函数会返回继续执行后面的代码。 reflectcall(nil, unsafe.Pointer(d.fn), deferArgs(d), uint32(d.siz), uint32(d.siz)) } p.argp nil // reflectcall did not panic. Remove d. if gp._defer ! d { throw(bad defer entry in panic) } d._panic nil // trigger shrinkage to test stack copy. See stack_test.go:TestStackPanic //GC() pc : d.pc sp : unsafe.Pointer(d.sp) // must be pointer so it gets adjusted during stack copy // 将执行完的defer函数释放 if done { d.fn nil gp._defer d.link freedefer(d) } //defered函数调用recover成功捕获了panic会设置p.recovered true if p.recovered { 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 } atomic.Xadd(runningPanicDefers, -1) // Remove any remaining non-started, open-coded // defer entries after a recover, since the // corresponding defers will be executed normally // (inline). Any such entry will become stale once // we run the corresponding defers inline and exit // the associated stack frame. d : gp._defer var prev *_defer if !done { // Skip our current frame, if not done. It is // needed to complete any remaining defers in // deferreturn() prev d d d.link } for d ! nil { if d.started { // This defer is started but we // are in the middle of a // defer-panic-recover inside of // it, so dont remove it or any // further defer entries break } if d.openDefer { if prev nil { gp._defer d.link } else { prev.link d.link } newd : d.link freedefer(d) d newd } else { prev d d d.link } } gp._panic p.link // Aborted panics are marked but remain on the g.panic list. // Remove them from the list. for gp._panic ! nil gp._panic.aborted { gp._panic gp._panic.link } if gp._panic nil { // must be done with signal gp.sig 0 } // Pass information about recovering frame to recovery. gp.sigcode0 uintptr(sp) gp.sigcode1 pc mcall(recovery) throw(recovery failed) // mcall should not return } } // ran out of deferred calls - old-school panic now // Because it is unsafe to call arbitrary user code after freezing // the world, we call preprintpanics to invoke all necessary Error // and String methods to prepare the panic strings before startpanic. preprintpanics(gp._panic) // 终止整个程序 fatalpanic(gp._panic) // should not return *(*int)(nil) 0 // not reached }2.2 gorecover函数该函数的实现很简单如果当前 Goroutine 没有调用panic那么该函数会直接返回nil这也是崩溃恢复在非defer中调用会失效的原因。在正常情况下它会修改runtime._panic的recovered字段recover函数仅仅改变了当前groutine第一个panic对象的recovered的值runtime.gorecover函数中并不包含恢复程序的逻辑程序的恢复是由runtime.gopanic函数负责的。// The implementation of the predeclared function recover. // Cannot split the stack because it needs to reliably // find the stack segment of its caller. // // TODO(rsc): Once we commit to CopyStackAlways, // this doesnt need to be nosplit. //go:nosplit func gorecover(argp uintptr) interface{} { // Must be in a function running as part of a deferred call during the panic. // Must be called from the topmost function of the call // (the function used in the defer statement). // p.argp is the argument pointer of that topmost deferred function call. // Compare against argp reported by caller. // If they match, the caller is the one who can recover. gp : getg() p : gp._panic if p ! nil !p.goexit !p.recovered argp uintptr(p.argp) { p.recovered true return p.arg } return nil } // Unwind the stack after a deferred function calls recover // after a panic. Then arrange to continue running as though // the caller of the deferred function returned normally. func recovery(gp *g) { // Info about defer passed in G struct. sp : gp.sigcode0 pc : gp.sigcode1 // ds arguments need to be in the stack. if sp ! 0 (sp gp.stack.lo || gp.stack.hi sp) { print(recover: , hex(sp), not in [, hex(gp.stack.lo), , , hex(gp.stack.hi), ]\n) throw(bad recovery) } // Make the deferproc for this d return again, // this time returning 1. The calling function will // jump to the standard return epilogue. gp.sched.sp sp gp.sched.pc pc gp.sched.lr 0 gp.sched.ret 1 gogo(gp.sched) }2.3 嵌套流程浅析func main() { defer fmt.Println(in main) // defer_0 defer func() { // defer_1 defer func() { // defer_2 panic(panic again and again) // panic_3 }() fmt.Println(step 2) panic(panic again) // panic_2 }() defer func() { // defer_3 recover() }() panic(panic once) // panic_0 panic(panic 1) // panic_1不会被执行 } // 上述程序执行的结果如下 step 2 in main panic: panic again panic: panic again and again /* main gopanic // 第一次panic(panic once)触发 1. 取出 defer_3设置 started 2. 执行 defer_3 - 执行 recoverpanic_0 字段被设置 recovered 3. 把 defer_3 从链表中摘掉 4. 把panic_0 从链表中摘掉 4. 执行 recovery 重置 pc 寄存器跳转到 defer_0 注册时候携带的指令一般是跳转到 deferreturn 上面几个指令 // 跳出 gopanic 的递归嵌套执行到 deferreturn 的地方 defereturn 1. 遍历 defer 函数链取出 defer_1设置 started 2. 执行 defer_1注册defer_2打印 step 2 gopanic // 第二次 1. 取出defer_1因为started已经被标记为true需要执行后摘掉 2. panic_2.aborted true 3. 遍历defer取出defer_2设置 started gopanic // 第三次 1. defer_2 已经被标记started所以执行后摘掉 2. panic_2.aborted true 3. 摘掉 defer_0打印in main链表为空跳出 for 循环 4. 执行 fatalpanic - exit(2) 退出进程 */
 获取与实战)
