Go语言 go程释放操作(退出/销毁)

情况1：

Go语言中，若在子go程中创建一个新 go程，子go程释放（销毁），新创建的go程不会随着子go程的销毁而销毁。

原因：

go程共享堆，不共享栈，go程由程序员在go的代码里显示调度（释放）。

实例：

package main
import (
"fmt"
"time"
"runtime"
)
func test()  {
for i:=0;i<10;i++{
fmt.Printf("执行第％d次go程\n",i)
time.Sleep(time.Second)
}
fmt.Println("go程执行完毕！")
}
func main() {
go func() {
go test()
fmt.Println("------aaaaaaaa-------")
time.Sleep(time.Second)
fmt.Println("------go程结束--------------")
/*
  不管是return  还是  runtime.Goexit()，效果一样
*/
//return
runtime.Goexit()
}()
for{
runtime.GC()
}
}

从以上实例来看，虽然子go程已经退出，但是在子go程中新建的go程还在执行！原因：go程不共享栈，有自己独立的栈空间。子go程有自己的栈，在子go程中创建的新go程也有自己的栈。

子go程的栈被释放（回收），由于栈独立，因此新创建的go程的栈不会被释放。

情况2：

Go语言中，若在主go程中创建一个新 go程，主go程释放（销毁），新创建的go程随着主go程的销毁而销毁。

原因：

go程共享堆，不共享栈，go程由程序员在go的代码里显示调度（释放）。

实例：

package main
import (
"fmt"
"time"
)
func main() {
go func() {
for i:=0;i<10;i++{
fmt.Printf("子go程：执行第％d次操作！\n",i)
time.Sleep(time.Second)
}
}()
for i:=0;i<3;i++{
fmt.Println("--------aaaa------")
time.Sleep(time.Second)
}
}

从以上实例来看，虽然主go程退出，子go程马上退出。原因：go程共享堆。主go程和新创建的子go程共享一个堆。主go程退出，执行main对应的{ }，堆退出。由于是共享堆，所以对应的子go程也会被销毁。

补充：go基础之服务退出问题

最近学习公司微服务的代码，看到每一个微服务的main函数都阻塞在那里，然后里面起的goroutine一直在哪里运行。

package main
import(
   "fmt"
   "os"
   "os/signal"
   "syscall"
   "log"
   "time"
)
func testFunc() error {
   go func(){
       for{
          fmt.Printf("testing....\n")
          time.Sleep(time.Minute)
       }
   }()
   return nil
}
func exitFunc(){
   fmt.Println("i am exiting!")
}
func main(){
   logger := log.New(os.Stdout, "[TestGoroutine]", log.Lshortfile | log.Ldate | log.Ltime) //初始化日志
   exit := make(chan os.Signal,10) //初始化一个channel
   signal.Notify(exit, syscall.SIGINT, syscall.SIGTERM) //notify方法用来监听收到的信号
   testFunc()
   sig := <-exit
   logger.Printf("％s",sig.String())
   exitFunc()
}

代码输出

[root@localhost demoproject]# go run test.go

testing....

^C[TestGoroutine]2018/07/31 19:26:14 test.go:36: interrupt

i am exiting!

可以看到知道按了ctrl+c之后才退出main函数的运行。然后goroutine随之停止运行。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持

来源：https://blog.csdn.net/weixin_42117918/article/details/82318508