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 协程的数量
欢迎点赞，关注，收藏
朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力
好了，本次就到这里
技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。
我是阿兵云原生，欢迎点赞关注收藏，下次见~
