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 协程的数量

欢迎点赞，关注，收藏

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

好了，本次就到这里

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

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

关键词： 的原因是 执行程序 全部关闭