Go中，goroutine是否结束执行（退出）是由其自身决定，其他goroutine只能通过消息传递的方式通知其关闭，而并不能在外部强制结束一个正在执行的goroutine。
有一种特殊情况会导致正在运行的goroutine会因为其他goroutine的结束而终止，即main函数退出。
package main import ( "fmt" "time" ) func main() { go func() { time.Sleep(time.Second) fmt.Println("goroutine exit") }() fmt.Println("main exit") } // output main exit
如上所示，程序未等goroutine执行完毕，即随着main函数的退出而停止执行。
package main import ( "context" "fmt" "time" ) func main() { ctx, cancel := context.WithCancel(context.Background()) go func(ctx context.Context) { num := 0 for { select { case <-ctx.Done(): fmt.Println("goroutine exit") return case <-time.After(time.Second): num++ fmt.Printf("goroutine wait times: %d\n", num) } } }(ctx) time.Sleep(time.Second * 3) cancel() time.Sleep(time.Second) fmt.Println("main exit") } // output goroutine wait times: 1 goroutine wait times: 2 goroutine exit main exit
package main import ( "fmt" "os" "time" ) func main() { go func() { defer func() { if err := recover(); err != nil { fmt.Printf("goroutine exit by panic: %v\n", err) } }() _, err := os.Open("notExistFile.txt") if err != nil { panic(err) } fmt.Println("goroutine exit naturally") }() time.Sleep(time.Second) fmt.Println("main exit") } // output goroutine exit by panic: open notExistFile.txt: no such file or directory main exit
上面自定义函数中defer函数使用了recover来捕获panic，当panic发生时可使goroutine拿回控制权，确保程序不会将panic传递到goroutine调用栈顶部后引起崩溃。
package main import ( "fmt" "time" ) func main() { go func() { for i := 0; i < 10000; i++ { // TODO: do some thing } fmt.Println("goroutine exit") }() time.Sleep(time.Second) fmt.Println("main exit") } // output goroutine exit main exit
goroutine里的任务执行完毕，即结束。
如果启动了一个goroutine，但并没有按照预期的一样退出，等到程序结束，此goroutine才结束，这种情况就是 goroutine 泄露。
当 goroutine 泄露发生时，该 goroutine 的栈一直被占用而不能释放，goroutine 里的函数在堆上申请的空间也不能被垃圾回收器回收。这样，在程序运行期间，内存占用持续升高，可用内存越来也少，最终将导致系统崩溃。
大多数情况下，引起goroutine泄露的原因有两类：
// 从channel中读取，但是没有向channel中写入 package main import ( "fmt" "runtime" "time" ) func main() { go func() { c := make(chan int) go func() { <-c }() time.Sleep(time.Second * 2) fmt.Println("goroutine exit") }() c := time.Tick(time.Second) for range c { fmt.Printf("goroutine [nums]: %d\n", runtime.NumGoroutine()) } } // output goroutine [nums]: 3 goroutine exit goroutine [nums]: 3 goroutine [nums]: 2 goroutine [nums]: 2 goroutine [nums]: 2 ... // 向已满的channel中写入，但是没有读取 package main import ( "flag" "fmt" "runtime" "time" ) var size = flag.Int("c", 0, "define channel size") func main() { flag.Parse() go func(size int) { c := make(chan int, size) go func() { <-c }() go func() { for i := 0; i < 10; i++ { c <- i } }() fmt.Println("goroutine exit") }(*size) c := time.Tick(time.Second) for range c { fmt.Printf("goroutine [nums]: %d\n", runtime.NumGoroutine()) } } // output go run main.go -c 2 goroutine exit goroutine [nums]: 2 goroutine [nums]: 2 goroutine [nums]: 2 ... go run main.go -c 11 goroutine exit goroutine [nums]: 1 goroutine [nums]: 1 goroutine [nums]: 1 ...
当代码里循环的退出条件不可达时，会令该goroutine进入死循环中，进而导致资源一直无法释放，引起泄露。
在实际项目中，往往死循环会发生在一些后台的常驻服务中。
在创建goroutine时，就应该知道goroutine啥时能结束。
channel引起的goroutine泄露问题，主要是看在channel阻塞goroutine时，该goroutine的阻塞是正常的，还是可能会导致goroutine永远没有机会执行(极大可能会造成协程泄露)。
channel的实际使用中，常用的两种模型：生产者-消费者模型；master-worker模型。一般的解决方案是：当主线程结束时，告知worker goroutine，worker goroutine得到通知后，进行清理工作然后退出；为每个worker任务制定超时，当超时触发，返回给master超时信息，并结束该worker goroutine。
实现循环语句时必须清晰地知道退出循环的条件，避免死循环。