前言

有这样一段代码:

func main() {
    // 捕捉异常
    defer func() {
        if err := recover(); err != nil {
            fmt.Println(err)
        }
    }()
    go func() {
        fmt.Println("start goroutine")
        panic("error")
    }()
    // 等待
    time.Sleep(time.Second * 100)
}

浅猜一下结果? 没错, 进程崩溃了, defer没有捕捉到异常.

面对这个问题, 可能有的人想的是: "哦, defer不能处理其他goroutine的异常". 但我正巧闲得慌, 索性研究一下Go中异常是如何处理的.

探究

Go语言现在已经实现自举了, 所以其源码也是Go, 不用去看C了. 源码地址: https://github.com/golang/go. 以下源码基于分支release-branch.go1.18

因为当前主要研究的是异常的处理, 所以对协程的原理及defer的调用不做过多探究.

结构体

在Go中, 每个协程都有一个结构体来记录其运行信息, 这个结构体的名字是g. 内容大致如下(定义在文件runtime.runtime2.go):

type g struct {
    // ...
  // 当前协程已出发的异常链
  _panic    *_panic
    // 记录当前协程的所有 defer 的链表
    _defer    *_defer
    // ...
}

其他的字段都跳过, 只看_defer字段, 也就是说在Go中defer和异常是记录在当前协程中的. 再回到开头的问题, 新启动的协程是没有defer函数的, 自然也就无法捕捉到异常.

既然是研究异常处理, _panic这个结构体自然也得瞅瞅了.

type _panic struct {
    // defer 函数用的, 具体等到研究 defer的时候再看
    argp      unsafe.Pointer
    // 调用 panic 函数时的参数
    arg       any
    // 指向上一个 panic, 组成一个 panic 链表
    // 因为在 panic 处理时, 可能再次发生异常
    // 比如在 defer 函数中发生 panic
    link      *_panic
    // 当前异常是否已经被 recover 处理
    recovered bool
    // 是否被强制终止
    aborted   bool
    goexit    bool
    pc        uintptr
    sp        unsafe.Pointer
}

其中pc sp goexit三个字段, 在defer中发生panic, 然后上层defer对异常进行了recover时使用的, 具体作用我也没整太明白, 可看这次commit 以及这个 issuse

OK, 到这里, 我们和异常的结构体见了一面了, 但异常触发时是如何处理的呢?

处理流程

先上一张流程图来对异常的处理流程进行较为形象的表达.

从上图中, 可以基本看出处理的流程. 不过还是康一下源码吧(为了不影响篇幅, 只保留了部分内容).

你问我怎么知道调用了源码中的哪个函数? 使用命令go tool compile -N -l -S main.go看一下咯.

// 处理异常的函数
func gopanic(e any) {
    gp := getg()
    // ...
    // 创建新的异常并添加到协程的 panic 链表头
    var p _panic
    p.arg = e
    p.link = gp._panic
    gp._panic = (*_panic)(noescape(unsafe.Pointer(&p)))
    //...
    for {
        d := gp._defer
        //...
        done := true
        // 调用 defer 函数
        // 关于 openDefer, 在这里先按下不表
        if d.openDefer {
            done = runOpenDeferFrame(gp, d)
            if done && !d._panic.recovered {
                addOneOpenDeferFrame(gp, 0, nil)
            }
        } else {
            p.argp = unsafe.Pointer(getargp())
            d.fn()
        }
        //...
        if done {
            //...
            // 将当前 defer 从协程的 defer 链中去掉
            freedefer(d)
        }
        // 异常已经被处理啦
        if p.recovered {
            //...
            // 恢复协程运行. 这里恢复的 recovery 方法不返回
            mcall(recovery)
            throw("recovery failed")
        }
    }
    // 打印 panic 信息
    preprintpanics(gp._panic)
    // 进程终止
    fatalpanic(gp._panic)
    *(*int)(nil) = 0
}
// 当调用 recover 时触发
// 逻辑很简单, 就是从异常链表的头部将异常取出来
// 因为新的异常会放到 _panic 链表头, 所以这里拿到的是最新的异常
func gorecover(argp uintptr) any {
    gp := getg()
    p := gp._panic
    if p != nil && !p.goexit && !p.recovered && argp == uintptr(p.argp) {
        // 标记当前异常已经被处理
        p.recovered = true
        return p.arg
    }
    // 当前没有异常
    return nil
}

从gopanic函数的异常处理流程来看, 异常在gorecover中一旦被处理, 就会将p.recovered标记为true. 而外层一旦检测到其值为true就会恢复运行. 看着貌似没什么问题哈, 但是还记不记得_panic是一个链表呀? 这不是才处理了一个异常么? 如果有其他异常不就丢了么? 比如下面这种情况:

func main() {
    defer func() {
        if err := recover(); err != nil {
            fmt.Println(err)
        }
    }()
    defer func() {
        panic("error 2")
    }()
    panic("error")
}

没错, 我们在先调用的defer中再次抛出异常, 此时, error这个异常就没有啦. 现象是符合我们前面的分析的.

系统级异常

在运行时有一些异常是无法通过recover捕获的. 比如调用throw函数的错误, throw函数源码如下:

func throw(s string) {
    systemstack(func() {
        print("fatal error: ", s, "\n")
    })
    gp := getg()
    if gp.m.throwing == 0 {
        gp.m.throwing = 1
    }
    //  直接强制停止
    fatalthrow()
    *(*int)(nil) = 0 // not reached
}

那么哪些操作会触发无法捕获的异常呢? 在系统实现上到处有调用throw函数的, 比如:

map的并发读写
占内存耗尽, 比如递归太深
go启动的函数为nil

OK, 至此, 虽然在源码层面没有分析的特别细致, 但是对异常的处理流程基本能做到心中有数啦

原文地址 https://hujingnb.com/archives/853

转载请保留原文连接: Go 异常处理流程 | 烟草的香味