go panic 和 recover

https://draveness.me/golang/docs/part2-foundation/ch05-keyword/golang-panic-recover/

func test(){
   fmt.Println("run......")

   defer func() {
      if err:=recover();err != nil{
         fmt.Println(err)
      }

   }()
   panic("test")
  // 往下不会执行


}





func main() {

   test()
   fmt.Println("fsdfsdf")







}
//

run......
test
fsdfsdf

进程 已完成，退出代码为 0

 

 

package main

import (
   "fmt"
   "zap/logger"
)







func main() {

   defer func() {
      if err:=recover();err != nil{
         fmt.Println(err)
      }

   }()
   panic("test")  
    fmt.Println("fdsf")   //stop run




}

test

进程 已完成，退出代码为 0

 

 

func Demoreset(path string) {
   f, err := os.Create(path)
   
   defer f.Close()
   defer func() {
      if r := recover(); r != nil {
             logger.Error("join template parse failed:", err)

         //log.Fatalln(r)   //不要使用log.fatelln莫名问题,可能本身就记录失败  退出代码为1

      }
   }()
   if err != nil {
      panic（"1"）
      fmt.Errorf("create file error is %s", err)
   }

   fmt.Println(f.Name()) //我是不会被执行到
}
func main() {

   Demoreset("/data") //is exits
   fmt.Println("err") //不加recover()我是不会被执行的，会panic

}


-------------------------
//即使返回error也会继续往下面走，除非panic，不加recover()
func Demoreset(path string) error {
   f, err := os.Open(path)

   defer f.Close()
   //defer func() {
   // if r := recover(); r != nil {
   //    fmt.Println(r)
   //logger.Error("join template parse failed:", err)
   //log.Fatalln(r) //不要使用log.fatelln莫名问题,可能本身就记录失败,

   // }
   //}()

   if err != nil {
      //panic("1")
      return fmt.Errorf("is a panic errors %v", err)  //即使返回error也会继续往下面走,除非panic，不加recover()


   }
   fmt.Println(f.Name()) //我是不会被执行到
   return nil
}
func main() {

   if err := Demoreset("/dataxxx"); err != nil {
      fmt.Println(err)
   }
   fmt.Println("is a err") //即使是return err也是继续往这里执行，除非panic

}

 


-----------
func JoinTemplateFromTemplateContent(templateContent, ip, cgroup string) []byte {
   setKubeadmAPI(Version)
   tmpl, err := template.New("text").Parse(templateContent)
   defer func() {
      if r := recover(); r != nil {
         logger.Error("join template parse failed:", err)
      }
   }()
   if err != nil {
      panic(1)
   }
   var envMap = make(map[string]interface{})
   envMap["Master0"] = IPFormat(MasterIPs[0])
   envMap["Master"] = ip
   envMap["TokenDiscovery"] = JoinToken
   envMap["TokenDiscoveryCAHash"] = TokenCaCertHash
   envMap["VIP"] = VIP
   envMap["KubeadmApi"] = KubeadmAPI
   envMap["CriSocket"] = CriSocket
   envMap["CgroupDriver"] = cgroup
   var buffer bytes.Buffer
   _ = tmpl.Execute(&buffer, envMap)
   return buffer.Bytes()
}

本节将分析 Go 语言中两个经常成对出现的两个关键字 — panic 和 recover。这两个关键字与上一节提到的 defer 有紧密的联系，它们都是 Go 语言中的内置函数，也提供了互补的功能。

golang-panic

图 5-12 panic 触发的递归延迟调用

  • panic 能够改变程序的控制流，调用 panic 后会立刻停止执行当前函数的剩余代码，并在当前 Goroutine 中递归执行调用方的 defer；
  • recover 可以中止 panic 造成的程序崩溃。它是一个只能在 defer 中发挥作用的函数，在其他作用域中调用不会发挥作用；

5.4.1 现象 #

我们先通过几个例子了解一下使用 panic 和 recover 关键字时遇到的现象，部分现象也与上一节分析的 defer 关键字有关：

  • panic 只会触发当前 Goroutine 的 defer；
  • recover 只有在 defer 中调用才会生效；
  • panic 允许在 defer 中嵌套多次调用；

跨协程失效 #

首先要介绍的现象是 panic 只会触发当前 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:
...
Go

当我们运行这段代码时会发现 main 函数中的 defer 语句并没有执行，执行的只有当前 Goroutine 中的 defer。

前面我们曾经介绍过 defer 关键字对应的 runtime.deferproc 会将延迟调用函数与调用方所在 Goroutine 进行关联。所以当程序发生崩溃时只会调用当前 Goroutine 的延迟调用函数也是非常合理的。

golang-panic-and-defers

图 5-13 panic 触发当前 Goroutine 的延迟调用

如上图所示，多个 Goroutine 之间没有太多的关联，一个 Goroutine 在 panic 时也不应该执行其他 Goroutine 的延迟函数。

失效的崩溃恢复 #

初学 Go 语言的读者可能会写出下面的代码，在主程序中调用 recover 试图中止程序的崩溃，但是从运行的结果中我们也能看出，下面的程序没有正常退出。

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
Go

仔细分析一下这个过程就能理解这种现象背后的原因，recover 只有在发生 panic 之后调用才会生效。然而在上面的控制流中，recover 是在 panic 之前调用的，并不满足生效的条件，所以我们需要在 defer 中使用 recover 关键字。

嵌套崩溃 #

Go 语言中的 panic 是可以多次嵌套调用的。一些熟悉 Go 语言的读者很可能也不知道这个知识点，如下所示的代码就展示了如何在 defer 函数中多次调用 panic：

func main() {
	defer fmt.Println("in main")
	defer func() {
		defer func() {
			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]:
...
exit status 2
Go

从上述程序输出的结果，我们可以确定程序多次调用 panic 也不会影响 defer 函数的正常执行，所以使用 defer 进行收尾工作一般来说都是安全的。

5.4.2 数据结构 #

panic 关键字在 Go 语言的源代码是由数据结构 runtime._panic 表示的。每当我们调用 panic 都会创建一个如下所示的数据结构存储相关信息：

type _panic struct {
	argp      unsafe.Pointer
	arg       interface{}
	link      *_panic
	recovered bool
	aborted   bool
	pc        uintptr
	sp        unsafe.Pointer
	goexit    bool
}
Go
  1. argp 是指向 defer 调用时参数的指针；
  2. arg 是调用 panic 时传入的参数；
  3. link 指向了更早调用的 runtime._panic 结构；
  4. recovered 表示当前 runtime._panic 是否被 recover 恢复；
  5. aborted 表示当前的 panic 是否被强行终止；

从数据结构中的 link 字段我们就可以推测出以下的结论：panic 函数可以被连续多次调用，它们之间通过 link 可以组成链表。

结构体中的 pc、sp 和 goexit 三个字段都是为了修复 runtime.Goexit 带来的问题引入的1。runtime.Goexit 能够只结束调用该函数的 Goroutine 而不影响其他的 Goroutine，但是该函数会被 defer 中的 panic 和 recover 取消2，引入这三个字段就是为了保证该函数的一定会生效。

5.4.3 程序崩溃 #

这里先介绍分析 panic 函数是终止程序的实现原理。编译器会将关键字 panic 转换成 runtime.gopanic，该函数的执行过程包含以下几个步骤：

  1. 创建新的 runtime._panic 并添加到所在 Goroutine 的 _panic 链表的最前面；
  2. 在循环中不断从当前 Goroutine 的 _defer 中链表获取 runtime._defer 并调用 runtime.reflectcall 运行延迟调用函数；
  3. 调用 runtime.fatalpanic 中止整个程序；
func gopanic(e interface{}) {
	gp := getg()
	...
	var p _panic
	p.arg = e
	p.link = gp._panic
	gp._panic = (*_panic)(noescape(unsafe.Pointer(&p)))

	for {
		d := gp._defer
		if d == nil {
			break
		}

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

		reflectcall(nil, unsafe.Pointer(d.fn), deferArgs(d), uint32(d.siz), uint32(d.siz))

		d._panic = nil
		d.fn = nil
		gp._defer = d.link

		freedefer(d)
		if p.recovered {
			...
		}
	}

	fatalpanic(gp._panic)
	*(*int)(nil) = 0
}
Go

需要注意的是，我们在上述函数中省略了三部分比较重要的代码：

  1. 恢复程序的 recover 分支中的代码；
  2. 通过内联优化 defer 调用性能的代码3；
  3. 修复 runtime.Goexit 异常情况的代码；

Go 语言在 1.14 通过 runtime: ensure that Goexit cannot be aborted by a recursive panic/recover 提交解决了递归 panic 和 recover 与 runtime.Goexit 的冲突。

runtime.fatalpanic 实现了无法被恢复的程序崩溃，它在中止程序之前会通过 runtime.printpanics 打印出全部的 panic 消息以及调用时传入的参数：

func fatalpanic(msgs *_panic) {
	pc := getcallerpc()
	sp := getcallersp()
	gp := getg()

	if startpanic_m() && msgs != nil {
		atomic.Xadd(&runningPanicDefers, -1)
		printpanics(msgs)
	}
	if dopanic_m(gp, pc, sp) {
		crash()
	}

	exit(2)
}
Go

打印崩溃消息后会调用 runtime.exit 退出当前程序并返回错误码 2，程序的正常退出也是通过 runtime.exit 实现的。

5.4.4 崩溃恢复 #

到这里我们已经掌握了 panic 退出程序的过程，接下来将分析 defer 中的 recover 是如何中止程序崩溃的。编译器会将关键字 recover 转换成 runtime.gorecover：

func gorecover(argp uintptr) interface{} {
	gp := getg()
	p := gp._panic
	if p != nil && !p.recovered && argp == uintptr(p.argp) {
		p.recovered = true
		return p.arg
	}
	return nil
}
Go

该函数的实现很简单，如果当前 Goroutine 没有调用 panic，那么该函数会直接返回 nil，这也是崩溃恢复在非 defer 中调用会失效的原因。在正常情况下，它会修改 runtime._panic 的 recovered 字段，runtime.gorecover 函数中并不包含恢复程序的逻辑，程序的恢复是由 runtime.gopanic 函数负责的：

func gopanic(e interface{}) {
	...

	for {
		// 执行延迟调用函数，可能会设置 p.recovered = true
		...

		pc := d.pc
		sp := unsafe.Pointer(d.sp)

		...
		if p.recovered {
			gp._panic = p.link
			for gp._panic != nil && gp._panic.aborted {
				gp._panic = gp._panic.link
			}
			if gp._panic == nil {
				gp.sig = 0
			}
			gp.sigcode0 = uintptr(sp)
			gp.sigcode1 = pc
			mcall(recovery)
			throw("recovery failed")
		}
	}
	...
}
Go

上述这段代码也省略了 defer 的内联优化，它从 runtime._defer 中取出了程序计数器 pc 和栈指针 sp 并调用 runtime.recovery 函数触发 Goroutine 的调度，调度之前会准备好 sp、pc 以及函数的返回值：

func recovery(gp *g) {
	sp := gp.sigcode0
	pc := gp.sigcode1

	gp.sched.sp = sp
	gp.sched.pc = pc
	gp.sched.lr = 0
	gp.sched.ret = 1
	gogo(&gp.sched)
}
Go

当我们在调用 defer 关键字时，调用时的栈指针 sp 和程序计数器 pc 就已经存储到了 runtime._defer 结构体中，这里的 runtime.gogo 函数会跳回 defer 关键字调用的位置。

runtime.recovery 在调度过程中会将函数的返回值设置成 1。从 runtime.deferproc 的注释中我们会发现，当 runtime.deferproc 函数的返回值是 1 时，编译器生成的代码会直接跳转到调用方函数返回之前并执行 runtime.deferreturn：

func deferproc(siz int32, fn *funcval) {
	...
	return0()
}
Go

跳转到 runtime.deferreturn 函数之后，程序就已经从 panic 中恢复了并执行正常的逻辑，而 runtime.gorecover 函数也能从 runtime._panic 结构中取出了调用 panic 时传入的 arg 参数并返回给调用方。

5.4.5 小结 #

  1. panic() 会退出进程，是因为调用了 exit 的系统调用；
  2. recover() 并不是说只能在 defer 里面调用，而是只能在 defer 函数中才能生效，只有在 defer 函数里面，才有可能遇到 _panic 结构；
  3. recover() 所在的 defer 函数必须和 panic 都是挂在同一个 goroutine 上，不能跨协程，因为 gopanic 只会执行当前 goroutine 的延迟函数；
  4. panic 的恢复，就是重置 pc 寄存器，直接跳转程序执行的指令，跳转到原本 defer 函数执行完该跳转的位置（deferreturn 执行），从 gopanic 函数中跳出，不再回来，自然就不会再 fatalpanic ；
  5. panic 为啥能嵌套？这个问题就像是在问为什么函数调用可以嵌套一样，因为这个本质是一样的。

 

分析程序的崩溃和恢复过程比较棘手，代码不是特别容易理解。我们在本节的最后还是简单总结一下程序崩溃和恢复的过程：

  1. 编译器会负责做转换关键字的工作；
    1. 将 panic 和 recover 分别转换成 runtime.gopanic 和 runtime.gorecover；
    2. 将 defer 转换成 runtime.deferproc 函数；
    3. 在调用 defer 的函数末尾调用 runtime.deferreturn 函数；
  2. 在运行过程中遇到 runtime.gopanic 方法时，会从 Goroutine 的链表依次取出 runtime._defer 结构体并执行；
  3. 如果调用延迟执行函数时遇到了 runtime.gorecover 就会将 _panic.recovered 标记成 true 并返回 panic 的参数；
    1. 在这次调用结束之后，runtime.gopanic 会从 runtime._defer 结构体中取出程序计数器 pc 和栈指针 sp 并调用 runtime.recovery 函数进行恢复程序；
    2. runtime.recovery 会根据传入的 pc 和 sp 跳转回 runtime.deferproc；
    3. 编译器自动生成的代码会发现 runtime.deferproc 的返回值不为 0，这时会跳回 runtime.deferreturn 并恢复到正常的执行流程；
  4. 如果没有遇到 runtime.gorecover 就会依次遍历所有的 runtime._defer，并在最后调用 runtime.fatalpanic 中止程序、打印 panic 的参数并返回错误码 2；

分析的过程涉及了很多语言底层的知识，源代码阅读起来也比较晦涩，其中充斥着反常规的控制流程，通过程序计数器来回跳转，不过对于我们理解程序的执行流程还是很有帮助。

posted @   技术颜良  阅读(124)  评论(0)  编辑  收藏  举报
相关博文：
· 探究 Go 源码中 panic & recover 有哪些坑？
· go panic 和 recover（重要）
· 通过示例学习-Go-语言-2023-二十五-
· Go 函数的健壮性、panic异常处理、defer 机制
· go编译器以及defer实现
阅读排行：
· 全网最简单！3分钟用满血DeepSeek R1开发一款AI智能客服，零代码轻松接入微信、公众号、小程
· .NET 10 首个预览版发布，跨平台开发与性能全面提升
· 《HelloGitHub》第 107 期
· 全程使用 AI 从 0 到 1 写了个小工具
· 从文本到图像：SSE 如何助力 AI 内容实时呈现？（Typescript篇）
历史上的今天：
2019-02-18 ansible小结常用模块
点击右上角即可分享
微信分享提示