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

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

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

尝试开辟尽可能多的 协程

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

func main() {goroutineNum := math.MaxInt32for 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.MaxInt32ch := 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 := 10ch := make(chan struct{}, 5)for i := 0; i < goroutineNum; i++ {ch <- struct{}{}go processGo(i, ch)}
}

执行程序看效果

# go run main.goi ==  4 func ==  6i ==  5 func ==  6i ==  6 func ==  6i ==  7 func ==  6i ==  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())<-chwg.Done()
}var wg = sync.WaitGroup{}func main() {goroutineNum := 10ch := 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.goi ==  4 func ==  6i ==  5 func ==  6i ==  6 func ==  6i ==  7 func ==  6i ==  8 func ==  6i ==  9 func ==  6i ==  0 func ==  5i ==  1 func ==  4i ==  2 func ==  3i ==  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 := 2taskNum := math.MaxInt32ch := 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 协程的数量

欢迎点赞，关注，收藏

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

好了，本次就到这里

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

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