你知道 GO 中的 协程可以无止境的开吗？

xdm ， 不知道你们是否有使用过 defer ，这种语法在是 go 特有的，用起来真是爽的不要不要的

很多时候，我们在使用一些新东西，出现一些莫名其妙的现象或者是结果的时候，我们总会认为，这个东西不友好， 这个东西好坑，好奇怪

其实我们是要弄明白其中的注意点，原理，当出现所谓的奇怪现象的时候，处理起来就会得心应手得多

xdm，这里准备了如下注意事项，请查收

案例 1

这里先统一说明一下 defer 是干什么的？

是 GO 中的一个关键字

这个关键字，我们一般用在释放资源，在 return 前会调用他

如果程序中有多个 defer ，defer 的调用顺序是按照类似栈的方式，后进先出 LIFO的 ， 具体的 defer 实现原理可以查看我的历史文章 GO 中 defer的实现原理

先来看一个 demo，猜一猜他的输出是什么？

写一个 defer 和 defer 在一起的 输入输出顺序 demo

• 简单写 4 个函数，分别应用到 defer 上

func test1() {
    fmt.Println("test 1")
}
func test2() {
    fmt.Println("test 2")
}
func test3() {
    fmt.Println("test 3")
}
func test4() {
    fmt.Println("test 4")
}
func main() {
    defer test1()
    defer test2()
    defer test3()
    defer test4()
}

运行上述代码，我们期望的结果是什么呢？

test 1
test 2
test 3
test 4

还是

test 4
test 3
test 2
test 1

小伙伴们感兴趣的可以运行一下，结果是 第二种，defer 我们可以理解为是一个入栈操作，先进后出

入栈 ： test1()，test2()，test3()，test4()

出栈 ： test4()，test3()，test2()，test1()

案例 2

上面我们知道 defer 和 defer 的顺序是按照栈的顺序来，那么我们下面来看看 defer 和 return 的顺序又是什么样子的 ？

• 简单写 一个用于 return 的函数和 用于 defer 的函数

func testDefer() {
    fmt.Println("testDefer")
}
func testReturn() int {
    fmt.Println("testReturn")
    return 1
}
func myTest() int {
    defer testDefer()
    return testReturn()
}
func main() {
    myTest()
}

再来猜测一下上述编码会是如何执行的呢

是这样的吗？

testDefer
testReturn

还是这样的 ?

testReturn
testDefer

结果仍然是第二种，通过上述编码我们可以看出来 defer 后面的语句 是晚执行的， return 后面的语句是先执行的

那么如果是 多个 defer 和 return 放在一起呢？

xdm ，咱们举一反三了，那肯定还是 return 先执行，defer 按照栈的顺序执行

案例 3

这个案例咱们加上简单的计算，看看效果如何

• 简单些一下带有计算的 defer

func testDefer(num int)(res int){

    defer func(){
        res = num + 3
    }()

    return num
}

func main(){

    res := testDefer(5)
    fmt.Println(res)
}

上述编码运行后会是什么效果呢

是 5 吗？ 是 8 吗？反正肯定不是 3 吧

思考一下，按照上面案例 1 的逻辑，结果是 8

老铁，没毛病， num 通过 testDefer 函数传值，赋值 为 5 ，return num 的时候，返回值是 5，再执行 defer 语句， 5+3 就是 8

好了，今天就到这里，感兴趣的朋友也可以玩起来

欢迎点赞，关注，收藏

朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力

好了，本次就到这里

技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。

我是阿兵云原生，欢迎点赞关注收藏，下次见~

GO语言天生高并发的语言，那么是不是使用 go 开辟协程越多越好的，那么在 go 里面，协程是不是可以开无限多个呢？

那么我们就一起来看看尝试写写 demo 吧

尝试开辟尽可能多的 协程

写一个 demo ，循环开 1 << 31 - 1 个协程看看会是什么效果

func main() {
    goroutineNum := math.MaxInt32

    for i := 0; i < goroutineNum; i++ {
        go func(i int) {
            fmt.Println(" i == ", i, "func == ", runtime.NumGoroutine())
        }(i)
    }
}

执行后，我人都傻了，直接是没有输出，2 核 1 G 的服务器直接卡死 ， 感兴趣的 xdm 可以尝试一波

这里说一下，出现上述现象的原因是：

我们迅速的疯狂开辟协程，又不控制并发数量，那么在那段很短的时间里面，go 程序会尽可能多的占用操作系统资源，直到被操作系统主动杀掉

一旦主协程被杀掉，那么其他的协程也全部 game over ， 因为他们占用的资源是用户态的共享资源，一个协程挂掉，是会影响到其他协程的

尝试控制协程数量

咱们实现的方法是，使用 channel ，设置 channel 的缓冲个数来控制实际并发的协程个数，一起来看看是否有效果

func processGo(i int, ch chan struct{}) {
    fmt.Println(" i == ", i, "func == ", runtime.NumGoroutine())
    <-ch
}

func main() {
    goroutineNum := math.MaxInt32

    ch := make(chan struct{}, 5)

    for i := 0; i < goroutineNum; i++ {
        ch <- struct{}{}
        go processGo(i, ch)

    }
}

效果见如下截图，由于数据打印太长，如下为部分数据

这里我们可以看到，加入并发控制后，效果还是很明显的，至少我的服务器不会被卡死了

通过打印我们可以看出来，总共 6 个协程，其中有 5 个是子协程，1 个是主协程

我们这里，使用 channel 的方式来控制并发，go 协程的创建速度 依赖于 for 循环的速度，而 for 循环的速度是被 channel 控制住了 ，channel 的速度实际上又被实际处理事情的协程的处理速度控制着，因此，我们可以保证在同一个时间内，并发运行的协程总共是 6 个

但是这就够了么， nonono ， 我们可以再来看一个例子

• 我们设置在循环的个数为 10 ，比刚才的值小了很多，代码逻辑保持一致

func main() {
    goroutineNum := 10

    ch := make(chan struct{}, 5)

    for i := 0; i < goroutineNum; i++ {
        ch <- struct{}{}
        go processGo(i, ch)

    }
}

执行程序看效果

# go run main.go
 i ==  4 func ==  6
 i ==  5 func ==  6
 i ==  6 func ==  6
 i ==  7 func ==  6
 i ==  8 func ==  6

我们发现输出并不是我们想要的 ， 出现这个的原因是主协程 循环 10 次完毕之后，就会马上退出程序，进而子协程也随之退出，这个问题需要解决

尝试加入 sync 同步机制，让主协程等一下子协程

之前我们有分享到 go 中的一个知识点，可以使用 sync 来一起控制同步 ， 就是使用 sync.WaitGroup ，不知道 xdm 是否还记得，不记得没关系，咱们今天再使用一遍，看看效果

• 加入 sync 机制，循环的时候，需要开辟协程时，则 sync.Add
• 协程结束的时候，sync.Done
• 主协程循环完毕之后，等待子协程完成自己的事情，使用 sync.Wait

func processGo(i int, ch chan struct{}) {
    fmt.Println(" i == ", i, "func == ", runtime.NumGoroutine())
    <-ch
    wg.Done()
}

var wg = sync.WaitGroup{}

func main() {
    goroutineNum := 10

    ch := make(chan struct{}, 5)

    for i := 0; i < goroutineNum; i++ {
        ch <- struct{}{}
        wg.Add(1)
        go processGo(i, ch)

    }

    wg.Wait()
}

上述代码中，我们可以简单理解 sync 的使用， sync.Add 就是添加需要等待多少个子协程结束， sync.Done 就是当前的子协程结束了，减去 1 个协程， sync.Wait 就是等待 子协程的个数最终变成 0 ，则认为子协程全部关闭

运行程序来查看效果

m# go run main.go
 i ==  4 func ==  6
 i ==  5 func ==  6
 i ==  6 func ==  6
 i ==  7 func ==  6
 i ==  8 func ==  6
 i ==  9 func ==  6
 i ==  0 func ==  5
 i ==  1 func ==  4
 i ==  2 func ==  3
 i ==  3 func ==  2

尝试做的更加可控一些更加优秀一些

我们可以思考一下，上面的逻辑是不停的有协程在创建，也不停的有协程在被销毁，这样还是很耗资源的，我们是否可以固定设置具体的协程在做事情，并且将发送数据和处理数据进行一个分离呢？

就类似于生产者和消费者一样

咱们来尝试写一个 demo

• 专门写一个函数用于分发任务
• 分发任务之前先开辟好对应的协程，等待任务进来

func processGo(i int, ch chan struct{}) {
    for data := range ch {
        fmt.Println(" i == ", data, "func == ", runtime.NumGoroutine())
        wg.Done()
    }
}

func distributeTask(ch chan struct{}) {
    wg.Add(1)
    ch <- struct{}{}
}

var wg = sync.WaitGroup{}

func main() {
    goroutineNum := 2
    taskNum := math.MaxInt32

    ch := make(chan struct{})

    // 先开辟好协程 等待处理数据
    for i := 0; i < goroutineNum; i++ {
        go processGo(i, ch)
    }

    // 分发事项
    for i := 0; i < taskNum; i++ {
        distributeTask(ch)
    }

    wg.Wait()
}

此处使用 sync 控制的同步，可以说是 对应的是任务数量， 主协程是等待所有分发的任务数都被完成了，主协程才关闭程序

执行程序查看效果

 go run main.go

程序正常运行没有毛病，这样做的话，我们可以将分发任务和处理任务进行分离，还大大减少了不必要的协程切换

对于如上案例做一个比喻

channel + sync 的案例 :

最上面的第一种案例，就是相当于动态雇佣 5 个工人，有任务的时候，工人就上去做，做完了自己下岗就得了，反正我这里只容纳 5 个工人，且每个工人做完 1 个任务就得走

分发任务和处理数据的任务分离案例 ：

最后的这个案例，就是固定的雇佣 2 个工人干活，项目经理就不停的扔任务进行来，这俩人就疯狂的干

xdm ，go 里面不能滥用协程，需要控制好 go 协程的数量

欢迎点赞，关注，收藏

朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力

好了，本次就到这里

技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。

我是阿兵云原生，欢迎点赞关注收藏，下次见~

本作品采用《CC 协议》，转载必须注明作者和本文链接