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

news2025/7/18 21:37:17

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()
}