前言

与defer类似的是,goroutine 中也有一个_panic链表头指针指向一个_panic链,发生panic的时候也是在链表头插入_panic结构体(执行gopanic)

在执行过程中发生了panic。那么panic以后的代码不会执行,转而执行panic的逻辑,再执行defer,执行到的defer要将started标记为true,同时将其defer结构体中的_panic指针指向当前的_panic,表示这个defer是由该panic触发的。再去执行defer链表,如果defer执行中还触发了panic,panic后的代码不载执行,将这个panic插入panic链头,同时将其作为当前panic。当遇到了与当前panic不符的defer,就找到该defer上的panic,将其标记为已终止,从defer链表中移除当前执行的defer。打印panic移除信息,从链表尾开始逐步输出

流程

panic执行defer的流程:

  • 先标记started=true,_panic=&panic
  • 后释放
  • 目的是为了终止之前发生的panic

异常信息的输出方式:

  • 所有还在panic链表上的项会被输出
  • 顺序与发生panic的顺序一致

// a _panic holds information about an active panic.
//
// a _panic value must only ever live on the stack.
//
// the argp and link fields are stack pointers, but don't need special
// handling during stack growth: because they are pointer-typed and
// _panic values only live on the stack, regular stack pointer
// adjustment takes care of them.
type _panic struct {
    // argp 存储当前要执行的defer的函数参数地址
	argp      unsafe.pointer // pointer to arguments of deferred call run during panic; cannot move - known to liblink
	// arg panic函数自己的参数
    arg       interface{}    // argument to panic
    // link,链到之前发生的panic
	link      *_panic        // link to earlier 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 标识panic是否被恢复
    recovered bool           // whether this panic is over
    // aborted 标识panic是否被终止
	aborted   bool           // the panic was aborted
	goexit    bool
}

关于recover

recover只执行一件事

  • 将当前执行的panic的recovered字段置为true

在每个defer执行完以后panic处理流程都会检查当前panic是否被recover

  • 如果当前panic已经被恢复,就会将它从panic链中移除
  • 执行到的defer也会被移除,同时要保存_defer.sp和_defer.pc

利用_defer.sp和_defer.pc跳出当前panic的处理流程,通过栈指针判断,只执行当前函数中注册的defer函数

在发生recover的函数正常结束后才会进入到检测panic是否被恢复的流程

当recover的函数又发生panic时,goroutine会将该panic加入到链头,设置为当前panic,再去执行defer链表,发现当前defer是当前panic执行的,移除当前defer,继续执行下一个,直到发现不是当前panic执行的,在panic链上找到那个panic,输出异常信息

对于已经recover标记的panic在输出异常信息时会加上recovered标记