3.panic和recover
Last updated
Last updated
编译器会将关键字 panic
转换成 ,该函数的执行过程包含以下几个步骤:
创建新的 并添加到所在 Goroutine 的 _panic
链表的最前面;
在循环中不断从当前 Goroutine 的 _defer
中链表获取 并调用 运行延迟调用函数;
调用 中止当前协程;
这段省略了 recover
分支的逻辑,这部分放到下面解析
由于 panic
和 G
是关联的,因此在主协程里的 recover
,是无法捕获到子协程里的 panic
的。
另外可以看到发生 panic
时,会遍历处理 G
的 defer
链表,因此使用 defer
进行收尾工作一般来说都是安全的。
分析程序的崩溃和恢复过程比较棘手,代码不是特别容易理解。我们在本节的最后还是简单总结一下程序崩溃和恢复的过程:
编译器会负责做转换关键字的工作;
如果调用延迟执行函数时遇到了 runtime.gorecover
就会将_panic.recovered
标记成 true
并返回 panic
的参数;
分析的过程涉及了很多语言底层的知识,源代码阅读起来也比较晦涩,其中充斥着反常规的控制流程,通过程序计数器来回跳转,不过对于我们理解程序的执行流程还是很有帮助。
https://draveness.me/golang/docs/part2-foundation/ch05-keyword/golang-panic-recover0
编译器会将关键字 recover
转换成 :
如果当前 Goroutine 没有 panic
,那么该函数会直接返回 nil
。在正常情况下,它会修改 的 recovered
字段, 函数中并不包含恢复程序的逻辑,程序的恢复是由上面的 函数负责的:
当我们在调用 defer
关键字时,调用时的栈指针 sp
和程序计数器 pc
就已经存储到了 结构体中,这里的 函数会跳回 defer
关键字调用的位置。
在调度过程中会将函数的返回值设置成 1。从 的注释中我们会发现,当 函数的返回值是 1 时,编译器生成的代码会直接跳转到调用方函数返回之前并执行 :
跳转到 函数之后,程序就已经从 panic
中恢复了并执行正常的逻辑,而 函数也能从 结构中取出了调用 panic
时传入的 arg
参数并返回给调用方。
将 panic
和 recover
分别转换成 和 ;
将 defer
转换成 函数;
在调用 defer
的函数末尾调用 函数;
在运行过程中遇到 方法时,会从 Goroutine 的链表依次取出 结构体并执行;
在这次调用结束之后, 会从 结构体中取出程序计数器 pc
和栈指针 sp
并调用 函数进行恢复程序;
会根据传入的 pc
和 sp
跳转回 ;
编译器自动生成的代码会发现 的返回值不为 0,这时会跳回 并恢复到正常的执行流程;
如果没有遇到 就会依次遍历所有的 ,并在最后调用 中止程序、打印 panic
的参数并返回错误码 2;