在开发项目之前之所以使用go语言是因为Go天生支持高并发,只需要go func()就可以实现一个用户态的协程,占用的资源非常小仅仅2k左右(并且支持动态扩容),而正常采用java,c++等语言启用的线程一般都是内核态的占用的内存资源一般在4m左右,而假设我们的服务器CPU内存为4G,那么很明显才用的内核态线程的并发总数量也就是1024个,相反查看一下Go语言的协程则可以达到410241024/2=200w.这么一看就明白了为什么Go语言天生支持高并发;这样一看我们发现根本不需要考虑协程池的使用,直接go func一直启用就好了,但是万事难料,我们举一个很不好的例子那就是大量的协程创建销毁需要消耗cpu性能,为了减少这些不必要的性能损失,同时可以支持高并发我们必须想办法再去减少一些不必要的cup性能损耗。 例如Java为了减少这种不必要的线程创建销毁的性能损失,官方包提供相关的线程池方案一共有四种:
go语言也有相关的协程池方案,而且使用最广泛同时性能最稳定的就是ants。
示例:
var tunnel = make(chan string, 1) // 取决于函数业务的参数类型
func Test66(t *testing.T) {
go IncomingZombie()
chairPool, _ := ants.NewPoolWithFunc(3, ExecuteZombie) // 声明有几把电椅
defer chairPool.Release()
for {
select {
case a := <-tunnel:
go chairPool.Invoke(a) //将参数传输给执行函数
fmt.Println("当前执行的协程数: ", chairPool.Running())
}
}
}
// 处决僵尸
func ExecuteZombie(i interface{}) {
fmt.Printf("正在处决僵尸 %s 号,还有5秒钟....\n", i.(string))
time.Sleep(1 * time.Second)
fmt.Printf(":) %s 玩完了,下一个\n-----------------\n", i.(string))
}
// 僵尸不断进来
func IncomingZombie() {
for i := 0; i < 4; i++ {
tunnel <- strconv.Itoa(i)
}
}
执行效果:
=== RUN Test66
当前执行的协程数: 0
当前执行的协程数: 0
当前执行的协程数: 0
正在处决僵尸 1 号,还有5秒钟....
正在处决僵尸 2 号,还有5秒钟....
正在处决僵尸 0 号,还有5秒钟....
当前执行的协程数: 3
:) 2 玩完了,下一个
-----------------
:) 0 玩完了,下一个
-----------------
正在处决僵尸 3 号,还有5秒钟....
:) 1 玩完了,下一个
-----------------
:) 3 玩完了,下一个
既然Go调度器已经这么优秀了,我们为什么还要使用ants呢?优秀不代表完美,基于G-P-M的Go调度器背后,go程序的并发编程中,可以任性地起大规模的goroutine来执行任务,官方也宣称用golang写并发程序的时候随便起个成千上万的goroutine毫无压力。
然而,你起1000个goroutine没有问题,10000也没有问题,10w个可能也没问题;那,100w个呢?1000w个呢?(这里只是举个极端的例子,实际编程起这么大规模的goroutine的例子极少)这里就会出问题,什么问题呢?
首先,即便每个goroutine只分配2KB的内存,但如果是恐怖如斯的数量,聚少成多,内存暴涨,就会对GC造成极大的负担,写过java的同学应该知道jvm GC那万恶的STW(Stop The World)机制,也就是GC的时候会挂起用户程序直到垃圾回收完,虽然Go1.8之后的GC已经去掉了STW以及优化成了并行GC,性能上有了不小的提升,但是,如果太过于频繁地进行GC,依然会有性能瓶颈;
其次,还记得前面我们说的runtime和GC也都是goroutine吗?是的,如果goroutine规模太大,内存吃紧,runtime调度和垃圾回收同样会出问题,虽然G-P-M模型足够优秀,韩信点兵,多多益善,但你不能不给士兵发口粮(内存)吧?巧妇难为无米之炊,没有内存,Go调度器就会阻塞goroutine,结果就是P的Local队列积压,又导致内存溢出,这就是个死循环…,甚至极有可能程序直接Crash掉,本来是想享受golang并发带来的效益,结果却得不偿失。 ants是一个高性能的 goroutine 池,实现了对大规模 goroutine 的调度管理、goroutine 复用,允许使用者在开发并发程序的时候限制 goroutine 数量,复用资源,达到更高效执行任务的效果。
在大规模批量并发任务场景下比原生 goroutine 并发具有更高的性能
参考: https://www.cnblogs.com/beginnerzyh/p/16221005.html