同事反馈了一个问题，一个微服务异常退出。查了许久没有发现一个是一个协程异常导致的整个进程退出了。程序的异常情况其实基本上是可控的，找到异常原因，修复问题上线是可以的。但是这里体现了两个知识点：1、golang的一个协程异常，如果没有捕获，回导致整个进程退出。
这里就不举例子说明了，自己可以写个很简单的demo，通过go func() {}里面使用panic产生恐慌试验下。
2、关于defer、panic、recover的使用理解
golang不支持java语言中的try...catch...finally这种异常，因为...此处忽略了一千字
defer的原意是推迟、延期。它的思想类似与C++的析构函数，不过go语言中的析构的不是对象，而是函数，defer就是用来添加函数结束时执行的语句。注意这里强调的是添加，而不是指定。因为不同于C++中的析构函数是静态的，Go中的defer是动态的。
func Defer() (result int) {
defer func() {
result ++
}()
return 0
}
上述函数输出值为1，因为在函数返回前执行了defer函数，修改了result值。在上面的defer函数前增加一个返回，如下：
func Defer() (resultint) {
return 0
defer func() {
result ++
}()
return 0
}
上述函数返回0，因为还没有注册执行defer，函数已经返回了。
此外，在一个函数中，defer可以添加多个，这样就形成了一个defer栈，既然说到栈，当然遵循先进后出的特性。例子如下：
func Defer() () {
defer func() {
fmt.Println("result = 1")
}()
defer func() {
fmt.Println("result = 2")
}()
defer func() {
fmt.Println("result = 3")
}()
}
上述例子输出
panic：原意为恐慌、惊慌。上面已经提到过，在程序中使用panic会让程序立马退出(除非recover)。所以，go语言的异常，是真的异常了。函数在执行panic时，函数不会再往下走了，运行时并不是立刻向上传递panic，而是到defer，等defer函数执行完，panic会继续向上传递，所以这时候defer有点类似try-catch-finally中的finally。
recover：原意重新获得、恢复。上面说到panic函数并不会立刻返回，而是先去执行defer，然后再返回。这时候如果在defer中阻止panic继续向上传递，那就异常的处理机制完善了。
go语言提供了recover内置函数，前面提到，在defer中可以使用recover来捕获panic，禁止panic向上传递，从而不会导致整个程序的退出。
那么问题来了，假如编写的程序存在N个协程，是在每个协程中的defer中recover还是可以在主协程中的defer中recover？下面通过例子来说明下：
例1:
func Recover() {
go func() {
defer func() {
if r := recover();r != nil {
fmt.Println("Recoverd in f", r)
}
}()
time.Sleep(time.Second *2)
panic(1)
}()
for ;; {
fmt.Println("sleeping...")
time.Sleep(time.Second *4)
}
}
上面的例子输出
在defer中捕获到panic为1的恐慌。是否可以在主协程中捕获到这个恐慌那？
例2:
func Recover() {
defer func() {
if r := recover();r != nil {
fmt.Println("Recoverd in f", r)
}
}()
go func() {
time.Sleep(time.Second *2)
panic(1)
}()
for ;; {
fmt.Println("sleeping...")
time.Sleep(time.Second *4)
}
}
程序会终止，并不会捕捉到上面的异常。