聊聊golang中的panic和defer

最新推荐文章于 2024-04-24 21:44:10 发布

是蛋筒啊

最新推荐文章于 2024-04-24 21:44:10 发布

阅读量5.8k

点赞数 8

分类专栏： Golang 文章标签： go 底层应用开发

本文链接：https://blog.csdn.net/shidantong/article/details/106341159

版权

Golang 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

聊聊golang中的panic和defer

当数组越界、访问非法空间或者我们直接调用panic时，panic会停掉当前正在执行的程序，包括所有协程，比起exit直接退出，panic的退出更有秩序，他会他会先处理完当前goroutine已经defer挂上去的任务，执行完毕后再退出整个程序。

而defer的存在，让我们有更多的选择，比如在defer中通过recover截取panic，从而达到try…catch的效果

panic还可以接收一个参数，通常是字符串类型错误信息，执行到panic时，他会打印这个字符串和触发他的调用战。

当然，我们在写代码时要注意，不是所有的异常都能被捕获到的，向fatal error 和runtime.throw 都是不能被recover的

情况一：程序终止的原因

func main() {
	panic("hello panic")
}

➜  learngo git:(master) ✗ go run main.go
panic: hello panic

goroutine 1 [running]:
main.main()
        /Users/luojilab/go/src/learngo/main.go:109 +0x39
exit status 2

情况二：程序未被终止的原因

func main() {
	defer func() {
		if err := recover(); err != nil {
			fmt.Printf("recover:%v\n", err)
		}
	}()
	panic("hello panic")
}

➜  learngo git:(master) ✗ go run main.go
recover:hello panic

情况三：没有defer程序会终止吗？

func main() {
	if err := recover(); err != nil {
		fmt.Printf("recover:%v\n", err)
	}
	panic("hello panic")
}

➜  learngo git:(master) ✗ go run main.go
panic: hello panic

goroutine 1 [running]:
main.main()
        /Users/luojilab/go/src/learngo/main.go:109 +0x39
exit status 2

情况四：写在goroutine里呢？

func main() {
	go func() {
		defer func() {
			if err := recover(); err != nil {
				fmt.Printf("recover:%v\n", err)
			}
		}()
	}()
	panic("hello panic")
}

➜  learngo git:(master) ✗ go run main.go
panic: hello panic

goroutine 1 [running]:
main.main()
        /Users/luojilab/go/src/learngo/main.go:109 +0x39
exit status 2

剖析panic的内部实现

首先，panic的基本单元是如下结构：

type _panic struct {
	argp      unsafe.Pointer  //一个指针，指向defer调用的参数的指针
	arg       interface{}   //panic传入的参数
	link      *_panic   //是一个链表结构，指向上一个调用的_panic
	recovered bool  //是否已被recover 恢复
	aborted   bool   //panic是否被强行中止
}

在这里插入图片描述
当panic时，系统内部发生了什么？

func main() {
	panic("hello panic")
}

➜  learngo git:(master) ✗ go tool compile -S main.go
"".main STEXT size=66 args=0x0 locals=0x18
        0x0000 00000 (main.go:108)      TEXT    "".main(SB), ABIInternal, $24-0
        0x0000 00000 (main.go:108)      MOVQ    (TLS), CX
        0x0009 00009 (main.go:108)      CMPQ    SP, 16(CX)
        ...
        0x002f 00047 (main.go:120)      PCDATA  $2, $0
        0x002f 00047 (main.go:120)      MOVQ    AX, 8(SP)
        0x0034 00052 (main.go:120)      CALL    runtime.gopanic(SB)
        0x0039 00057 (main.go:120)

显然，panic这里是调了gopanic这个函数，我们来看下该函数内部是如何实现的

// The implementation of the predeclared function panic.
func gopanic(e interface{}) {
	gp := getg() //获取指向当前goroutine的指针
	...
	//初始化一个panic的基本单元_panic
	var p _panic
	p.arg = e
	p.link = gp._panic
	gp._panic = (*_panic)(noescape(unsafe.Pointer(&p)))

	//遍历当前goroutinue的defer链表
	for {
		//获取当前goroutinue上挂的defer
		d := gp._defer
		if d == nil {
			break
		}

		//下面是一些对此defer的判断和处理，是否开放，是否可执行等
		...
		if d.started {
			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
			}
		}
		...

		
		d._panic = (*_panic)(noescape(unsafe.Pointer(&p)))

		//当前goroutinue若存在有效的defer调用，
		//就会调下面的reflectcall方法来处理defer后面的操作，
		//当然，若defer里面进行了recover处理，则会调用gorecover函数，
		p.argp = unsafe.Pointer(getargp(0))
		reflectcall(nil, unsafe.Pointer(d.fn), deferArgs(d), uint32(d.siz), uint32(d.siz))
		}
		p.argp = nil
		//在pc、sp中记录当前defer的pc、sp
		pc := d.pc
		sp := unsafe.Pointer(d.sp) // must be pointer so it gets adjusted during stack copy
		...
		
		//已经有recover被调用
		if p.recovered {
			...
			gp._panic = p.link
			...
			
			// Aborted panics are marked but remain on the g.panic list.
			// Remove them from the list.
			//移除那些被终止的panic
			for gp._panic != nil && gp._panic.aborted {
				gp._panic = gp._panic.link
			}
			...
			// Pass information about recovering frame to recovery.
			gp.sigcode0 = uintptr(sp)
			gp.sigcode1 = pc
		    // 恢复,调用recovery
			mcall(recovery)
			throw("recovery failed") // mcall should not return
		}
	}

	
	preprintpanics(gp._panic)//准备panic程序退出时要打印的参数

	//递归打印所有panic中的参数信息，并执行exit(2)来退出程序
	fatalpanic(gp._panic) // should not return
	*(*int)(nil) = 0      // not reached
}

由上，panic就是处理当前goroutinue上的panic链表，以及根据其上挂载的defer链表。

新的panic会被挂在当前goroutinue的panic链的最前面
调用reflectcall循环执行defer链上的延迟函数
没有recover的情况下执行完所有的defer会break跳出for 循环执行最后的fatalpanic来终止程序

       ...
        0x0024 00036 (main.go:111)      LEAQ    "".main.func1·f(SB), AX
        0x002b 00043 (main.go:111)      PCDATA  $2, $0
        0x002b 00043 (main.go:111)      MOVQ    AX, 8(SP)
        0x0030 00048 (main.go:111)      CALL    runtime.deferproc(SB)
        0x0035 00053 (main.go:111)      TESTL   AX, AX
        ...
        0x004b 00075 (main.go:116)      MOVQ    AX, 8(SP)
        0x0050 00080 (main.go:116)      CALL    runtime.gopanic(SB)
        0x0055 00085 (main.go:116)      UNDEF
        0x0057 00087 (main.go:111)      XCHGL   AX, AX
        0x0058 00088 (main.go:111)      CALL    runtime.deferreturn(SB)
        0x005d 00093 (main.go:111)      MOVQ    16(SP), BP
       ...
        0x0026 00038 (main.go:112)      MOVQ    AX, (SP)
        0x002a 00042 (main.go:112)      CALL    runtime.gorecover(SB)
        ... 
        0x0072 00114 ($GOROOT/src/fmt/print.go:208)     LEAQ    go.string."recovered:%v\n"(SB), AX
        ...
        0x00a3 00163 ($GOROOT/src/fmt/print.go:208)     CALL    fmt.Fprintf(SB)

看到这里，我们发现有四个关键的方法
runtime.deferproc
runtime.gopanic
runtime.deferreturn
runtime.gorecover
上面我们知道在panic时调用gopanic函数，接着遍历当前goroutinue上挂载的defer链表，在执行reflectcall时碰到recover，就执行gorecover函数处理
gorecover是如何恢复panic的呢？

// 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 doesn't need to be nosplit.
//go:nosplit
func gorecover(argp uintptr) interface{} {
	gp := getg()
	p := gp._panic
	if p != nil && !p.goexit && !p.recovered && argp == uintptr(p.argp) {
		p.recovered = true
		return p.arg
	}
	return nil
}

检查当前goroutinue是否在panic的流程中，在的话就将panic的recovered字段置微为true，否则直接返回nil，所以说recover在普通的流程被调用时时没有任何作用的。
gorecover函数仅仅改了recovered标记，那么gouroutine是怎么从panic返回的呢？

reflectcall调用完gorecover后会在pc、sp中记录defer的pc、sp，之后会调用

recovery

// 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

	// d's 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)
}

recovery更改了当前goroutinue的上下文，使它指向上面defer的位置，最后的gogo函数就直接切到了defer的上下文中

defer

//runtime/runtime2.go
type _defer struct {
    siz     int32   //参数大小
    started bool    // defer是否被调用过的标识
    sp      uintptr // sp at time of defer
    pc      uintptr
    fn      *funcval // defer 后面跟的function
    _panic  *_panic  // 指向panic链表
    link    *_defer  // 指向defer链表
    ...
}

在这里插入图片描述
defer是面向编译器的声明

编译期间，会将defer声明编译成runtime.deferproc(fn),运行时调用此方法将所有defer挂载goroutinue的defer链上
在函数return之前，增加runtime.deferreturn()调用，处理defer链上的所有defer

func deferproc(siz int32, fn *funcval) {
    ...
	sp := getcallersp()
	argp := uintptr(unsafe.Pointer(&fn)) + unsafe.Sizeof(fn)
	callerpc := getcallerpc()

	//newdefer从_defer池中找是否有可复用的_defer基本单元，若没有，就会malloc一个新的
	//并且将当前goroutinue的defer指向这个d,  新的defer总是会出现在最前面
	//这就是defer先入后出属性的原因所在，
	d := newdefer(siz)
    ...
	d.fn = fn
	d.pc = callerpc
	d.sp = sp
	switch siz {
	case 0:
		// Do nothing.
	case sys.PtrSize:
		*(*uintptr)(deferArgs(d)) = *(*uintptr)(unsafe.Pointer(argp))
	default:
		memmove(deferArgs(d), unsafe.Pointer(argp), uintptr(siz))
	}

	return0()
}

return0总是会检查返回值，若为0的话，说明deferproc成功，可以继续处理后面的逻辑，当返回值为非0的情况时（就是panic恢复时从recovery函数跳转过来的），此时就会跳转到函数的最后，return之前，继续执行deferreturn。由于调用recover的defer已经从defer链表上摘掉了，所以可以继续执行之前没完成的defer，并最终返回当前函数的调用者。

总之，deferproc这个函数就是初始化了一个defer结构，最后通过特殊的返回方式来结束函数调用，通过检查返回值为0或1使其分流至不同的流程中。

到这里，我们应该了解了panic是如何通过recover恢复的

在gopanic函数中，执行defer链中所有的延迟函数，执行时遇到recover会使得_panic.recovered=true
调用recovery通过_defer.sp和_defer.pc跳转到deferproc的上下文中来执行，同时将返回值设置为1
最后由于deferproc的返回值不为0，根据return0的特殊逻辑会跳到函数末尾直接执行deferreturn，恢复到了正常的流程

当一个 panic 被恢复后，调度并因此中断，会重新进入调度循环，进而继续执行 recover 后面的代码，包括比 recover 更早的 defer（因为已经执行过得 defer 已经被释放，而尚未执行的 defer 仍在 goroutine 的 defer 链表中），或者 recover 所在函数的调用方。

我们接着看下deferreturn函数都做了什么事情

func deferreturn(arg0 uintptr) {
	gp := getg()
	d := gp._defer
	if d == nil {
		return
	}
	sp := getcallersp()
	if d.sp != sp {
		return
	}

	switch d.siz {
	case 0:
		// Do nothing.
	case sys.PtrSize:
		*(*uintptr)(unsafe.Pointer(&arg0)) = *(*uintptr)(deferArgs(d))
	default:
		memmove(unsafe.Pointer(&arg0), deferArgs(d), uintptr(d.siz))
	}
	fn := d.fn
	d.fn = nil
	gp._defer = d.link
	freedefer(d)
	//会不断地进入 deferreturn 函数，判断链表中是否还存着 _defer。
	//若已经不存在了，则返回，结束掉它。
	//简单来讲，就是处理完全部 defer 才允许你真的离开它
	jmpdefer(fn, uintptr(unsafe.Pointer(&arg0)))
}

在一个函数中调用过 defer 关键字，那么编译器将会在结尾处插入 deferreturn 方法的调用。

清空当前节点_defer的调用信息
通过freedefer释放该defer，放入deferpool中，便于复用
调用jmpdefer跳转到defer后面的延迟函数处

defer涉及的两个关键函数deferproc和deferreturn，后者只要函数调用defer关键字，就会在结束之前插入deferreturn来完成defer后面的操作。

defer的性能问题

defer 关键字其实涉及了一系列的连锁调用，内部 runtime 函数的调用
编译期间，就需要做不少事情
deferproc中defer函数的注册阶段，_defer的生成以及初始化，链表结构的挂载，还涉及获取目标函数的地址，传入函数参数。
deferreturn时也有各种释放defer和jmpdefer的逻辑操作。

测试一下：

func HasDefer(a, b string) {
	defer func(a, b string) {
		_ = a + b
	}(a, b)
}

func NotDefer(a, b string) {
	_ = a + b
}

基准测试：

func BenchmarkHasDefer(b *testing.B) {
	for i := 0; i < b.N; i++ {
		HasDefer("has", "defer")
	}
}

func BenchmarkNotDefer(b *testing.B) {
	for i := 0; i < b.N; i++ {
		NotDefer("not", "defer")
	}
}

➜  learngo git:(master) ✗ go test -bench=. -benchmem -run=none
goos: darwin
goarch: amd64
pkg: learngo
BenchmarkHasDefer-4     20000000                81.8 ns/op             0 B/op          0 allocs/op
BenchmarkNotDefer-4     50000000                24.0 ns/op             0 B/op          0 allocs/op
PASS
ok      learngo 2.968s

可以看到，一个 defer 关键字实际上包含了不少的动作和处理，代码中使用defer，可能会给程序的性能代码几十纳秒的开销(根据运行环境的不同，数值有所不同)。

通常，我们在资源控制或者释放锁的处理后面都会加上defer + close() ，或者defer unlock，若后面的处理逻辑非常多，当并发流量很大时，资源和锁迟迟得不到释放也会有不少问题。

当然，defer 最大的功能是 Panic 后依然有效。如果没有 defer，Panic 后就会导致 unlock 丢失，最终会死锁，

所以，对于defer，我们该用就用，应该及时关闭就最好不要延迟。

Go1.13中defer的性能有所提升，

type _defer struct {
	siz     int32 // includes both arguments and results
	started bool
	heap    bool //标示defer是在堆上还是栈上分配
	openDefer bool
	sp        uintptr  // sp at time of defer
	pc        uintptr  // pc at time of defer
	fn        *funcval // can be nil for open-coded defers
	_panic    *_panic  // panic that is running defer
	link      *_defer
}

runtime.deferprocStack()存在d.heap = false的操作

runtime.deferproc()还存在

编译器会根据应用场景去选择使用 deferproc 还是 deferprocStack 方法，他们分别是针对分配在堆上和栈上的使用场景，对于有隐式循环和显式循环的场景，会分配在堆上调用前者

总之，其defer的堆栈分配规则的改变，要想享受defer带来的30%性能提升，就要避免下面两种场景的代码

defer语句外层嵌套有显式循环；
for循环，哪怕只循环了一次，都会调用runtime.deferproc()从堆上分配
defer语句有隐式循环；
在defer中存在goto关键字

Go1.14也对defer有了进一步优化，新加入了开放编码（Open-coded）defer类型，编译器在ssa过程中会把被延迟的方法直接插入到函数的尾部，避免了运行时的deferproc及deferprocStack操作
在deferreturn流程上进行了优化，之前都是通过jmpdefer一遍一遍的调用deferreturn来处理defer链上的所有延迟函数，直到处理完所有的defer会退出，1.14中改成了for循环去处理，省掉了很多函数调用，参数传参的消耗

条件是open-coded最多支持8个defer，超过则取消

是蛋筒啊

关注

8
点赞
踩
18

收藏

觉得还不错? 一键收藏
3
评论
聊聊golang中的panic和defer

聊聊golang中的panic和defer当数组越界、访问非法空间或者我们直接调用panic时，panic会停掉当前正在执行的程序，包括所有协程，比起exit直接退出，panic的退出更有秩序，他会他会先处理完当前goroutine已经defer挂上去的任务，执行完毕后再退出整个程序。而defer的存在，让我们有更多的选择，比如在defer中通过recover截取panic，从而达到try…catch的效果panic还可以接收一个参数，通常是字符串类型错误信息，执行到panic时，他会打印这个字符串和
复制链接

扫一扫