在golang的官方介绍中是这么介绍Recover函数的。
Recover is a built-in function that regains control of a panicking goroutine. Recover is only useful inside deferred functions. During normal execution, a call to recover will return nil and have no other effect. If the current goroutine is panicking, a call to recover will capture the value given to panic and resume normal execution.
也就是说当一个协程发生panic时，recover函数会捕捉到panic同时恢复正常的顺序。
像如下这样的代码：
package main
import (
"fmt"
"log"
"time"
)
func main() {
ch := make(chan int, 10)
for i := 2; i > 0; i-- {
go func(i int) {
defer func() {
err := recover()
if err != nil {
log.Println(err)
}
}()
for val := range ch {
fmt.Println("---->", val, "Go", i)
if val%2 == 1 && i == 1 {
panic("BOOM BOOM")
}
time.Sleep(2 * time.Second)
}
}(i)
}
var i int
for {
ch <- i
time.Sleep(1 * time.Second)
fmt.Println(i, "<---")
i++
}
}
我们向通道中写入，两个协成在接收，同时设计一个协程在一定的时候panic。那么在panic后，再recover，那在该协程的管道还能接收么？
过去，我一直以为，recover函数会重新恢复，该协程会类似重启一般==。
$ go run recover.go
----> 0 Go 2
0 <---
----> 1 Go 1
2018/01/21 21:52:54 BOOM BOOM
1 <---
----> 2 Go 2
2 <---
3 <---
----> 3 Go 2
4 <---
----> 4 Go 2
5 <---
6 <---
----> 5 Go 2
7 <---
8 <---
----> 6 Go 2
...
但从执行的结果看：
只有一个协程在工作，另外一个还是挂了。这时，我才意识到，recover函数并没有恢复原有的协程。只是当该协程panic后会执行defer。而在defer中，recover函数将panic拦截下来了，不会向外面抛出，从而导致其他协程的执行并不受到影响。但，已经panic的协程还是挂了。