深圳幻海软件技术有限公司 欢迎您!

为什么Go搞了协程GoFrame还要搞协程池?怎么用?什么时候用?

2023-02-28

最近收到「程序员升级打怪」知识星球[1]的提问:“go协程本来就是轻量级线程,还有必要做复用增加工作量吗,性能可以提升多少呢?”先说结论Go的协程goroutine非常轻量级,这也是Go天生支持高并发的主要原因。但是协程goroutine频繁的创建销毁对GC的压力比较大,会影响性能。grpool的作

最近收到「程序员升级打怪」知识星球[1]的提问:“go协程本来就是轻量级线程,还有必要做复用增加工作量吗,性能可以提升多少呢?”

先说结论

  • Go的协程goroutine非常轻量级,这也是Go天生支持高并发的主要原因。
  • 但是协程goroutine频繁的创建销毁对GC的压力比较大,会影响性能。
  • grpool的作用就是复用goroutine,减少频繁创建销毁的性能损耗。grpool相比于goroutine更节省内存,但是耗时更长;
  • 原因也很简单:grpool复用了协程,减少了协程的创建和销毁,减少了内存消耗;也因为协程的复用,总的协程数量减少,导致耗时变长。(一起干活的同事变少了,项目不就延期了嘛,很好理解。)
  • 所以:GoFrame的grpool通过协程复用,能够节省内存。结合我们的需求:如果你的服务器内存不高或者业务场景对内存占用的要求更高,那就使用grpool。如果服务器的内存足够,但是对耗时有较高的要求,就用原生的goroutine。

名词解释

Pool: goroutine池,用于管理若干可复用的goroutine协程资源

Worker: 池对象中参与任务执行的goroutine,一个worker可以执行若干个job,直到队列中再无等待的job

Job:添加到池对象的任务队列中等待执行的任务,是一个func()方法,一个job同时只能被一个worker获取并执行。

使用示例

使用默认的协程池,限制100个协程执行1000个任务

pool.Size() 获得当前工作的协程数量

pool.Jobs() 获得当前池中待处理的任务数量

package main

import (
   "fmt"
   "github.com/gogf/gf/os/grpool"
   "github.com/gogf/gf/os/gtimer"
   "sync"
   "time"
)

func main() {
   pool := grpool.New(100)

   //添加1千个任务
   for i := 0; i < 1000; i++ {
      _ = pool.Add(job)
   }

   fmt.Println("worker:", pool.Size()) //当前工作的协程数量
   fmt.Println("jobs:", pool.Jobs())   //当前池中待处理的任务数量

   gtimer.SetInterval(time.Second, func() {
      fmt.Println("worker:", pool.Size()) //当前工作的协程数
      fmt.Println("jobs:", pool.Jobs())   //当前池中待处理的任务数
   })

   //阻止进程结束
   select {}
}

//任务方法
func job() {
   time.Sleep(time.Second)
}
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
  • 18.
  • 19.
  • 20.
  • 21.
  • 22.
  • 23.
  • 24.
  • 25.
  • 26.
  • 27.
  • 28.
  • 29.
  • 30.
  • 31.
  • 32.
  • 33.
  • 34.

打印结果

是不是灰常简单~

踩坑之旅

一个简单的场景,请使用协程打印0~9。

常犯的错误

大家看下面的代码有没有问题,请预测一下打印结果。

wg := sync.WaitGroup{}
for i := 0; i < 9; i++ {
   wg.Add(1)
   go func() {
      fmt.Println(i)
      wg.Done()
   }()
}
wg.Wait()
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.

不用着急看答案

.

.

.

猜一下打印结果是什么。

打印结果

分析原因

对于异步线程/协程来讲,函数进行异步执行注册时,该函数并未真正开始执行。

(注册时只在goroutine​的栈中保存了变量i的内存地址)

而一旦开始执行时函数才会去读取变量i​的值,而这个时候变量i​的值已经自增到了9。

正确写法

wg := sync.WaitGroup{}
for i := 0; i < 9; i++ {
   wg.Add(1)
   go func(v int) {
      fmt.Println(v)
      wg.Done()
   }(i)
}
wg.Wait()
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.

打印结果

使用grpool

使用grpool和使用go一样,都需要把当前变量i的值赋值给一个不会改变的临时变量,在函数中使用该临时变量而不是直接使用变量i。

正确代码

wg := sync.WaitGroup{}
for i := 0; i < 9; i++ {
   wg.Add(1)
   v := i //grpool.add() 的参数只能是不带参数的匿名函数 因此只能以设置临时变量的方式赋值
   _ = grpool.Add(func() {
      fmt.Println(v)
      wg.Done()
   })
}
wg.Wait()
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.

打印结果

错误代码

注意:这是错误的演示,不要这么写~

wg := sync.WaitGroup{}
for i := 0; i < 9; i++ {
   wg.Add(1)
   _ = grpool.Add(func() {
      fmt.Println(i) //打印结果都是9
      wg.Done()
   })
}
wg.Wait()
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.

打印结果

性能测试

使用for循环,开启一万个协程,分别使用原生goroutine和grpool执行。

看两者在内存占用和耗时方面的差别。

package main

import (
   "flag"
   "fmt"
   "github.com/gogf/gf/os/grpool"
   "github.com/gogf/gf/os/gtime"
   "log"
   "os"
   "runtime"
   "runtime/pprof"
   "sync"
   "time"
)

func main() {
   //接收命令行参数
   flag.Parse()
   //cpu分析
   cpuProfile()
   //主逻辑
   //demoGrpool()
   demoGoroutine()
   //内存分析
   memProfile()
}

func demoGrpool() {
   start := gtime.TimestampMilli()
   wg := sync.WaitGroup{}
   for i := 0; i < 10000; i++ {
      wg.Add(1)
      _ = grpool.Add(func() {
         var m runtime.MemStats
         runtime.ReadMemStats(&m)
         fmt.Printf("运行中占用内存:%d Kb\n", m.Alloc/1024)
         time.Sleep(time.Millisecond)
         wg.Done()
      })
      fmt.Printf("运行的协程:", grpool.Size())
   }
   wg.Wait()
   fmt.Printf("运行的时间:%v ms \n", gtime.TimestampMilli()-start)
   select {}
}

func demoGoroutine() {
   //start := gtime.TimestampMilli()
   wg := sync.WaitGroup{}
   for i := 0; i < 10000; i++ {
      wg.Add(1)
      go func() {
         //var m runtime.MemStats
         //runtime.ReadMemStats(&m)
         //fmt.Printf("运行中占用内存:%d Kb\n", m.Alloc/1024)
         time.Sleep(time.Millisecond)
         wg.Done()
      }()
   }
   wg.Wait()
   //fmt.Printf("运行的时间:%v ms \n", gtime.TimestampMilli()-start)
}

var cpuprofile = flag.String("cpuprofile", "", "write cpu profile `file`")
var memprofile = flag.String("memprofile", "", "write memory profile to `file`")

func cpuProfile() {
   if *cpuprofile != "" {
      f, err := os.Create(*cpuprofile)
      if err != nil {
         log.Fatal("could not create CPU profile: ", err)
      }
      if err := pprof.StartCPUProfile(f); err != nil { //监控cpu
         log.Fatal("could not start CPU profile: ", err)
      }
      defer pprof.StopCPUProfile()
   }
}

func memProfile() {
   if *memprofile != "" {
      f, err := os.Create(*memprofile)
      if err != nil {
         log.Fatal("could not create memory profile: ", err)
      }
      runtime.GC()                                      // GC,获取最新的数据信息
      if err := pprof.WriteHeapProfile(f); err != nil { // 写入内存信息
         log.Fatal("could not write memory profile: ", err)
      }
      f.Close()
   }
}
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
  • 18.
  • 19.
  • 20.
  • 21.
  • 22.
  • 23.
  • 24.
  • 25.
  • 26.
  • 27.
  • 28.
  • 29.
  • 30.
  • 31.
  • 32.
  • 33.
  • 34.
  • 35.
  • 36.
  • 37.
  • 38.
  • 39.
  • 40.
  • 41.
  • 42.
  • 43.
  • 44.
  • 45.
  • 46.
  • 47.
  • 48.
  • 49.
  • 50.
  • 51.
  • 52.
  • 53.
  • 54.
  • 55.
  • 56.
  • 57.
  • 58.
  • 59.
  • 60.
  • 61.
  • 62.
  • 63.
  • 64.
  • 65.
  • 66.
  • 67.
  • 68.
  • 69.
  • 70.
  • 71.
  • 72.
  • 73.
  • 74.
  • 75.
  • 76.
  • 77.
  • 78.
  • 79.
  • 80.
  • 81.
  • 82.
  • 83.
  • 84.
  • 85.
  • 86.
  • 87.
  • 88.
  • 89.
  • 90.
  • 91.
  • 92.

运行结果

组件

占用内存

耗时

grpool

2229 Kb

1679 ms

goroutine

5835 Kb

1258 ms

性能测试结果分析

通过测试结果我们能很明显的看出来,在相同的环境下执行相同的任务:

grpool相比于goroutine,内存占用更少,耗时更长;

goroutine相比于grpool占用内存更高,耗时更短。

总结

我们再来回顾一下开篇的结论,相信通过仔细阅读,你一定有了更好的理解:

  • Go的协程goroutine非常轻量级,这也是Go天生支持高并发的主要原因。
  • 但是协程goroutine频繁的创建销毁对GC的压力比较大,会影响性能。
  • grpool的作用就是复用goroutine,减少频繁创建销毁的性能损耗。grpool相比于goroutine更节省内存,但是耗时更长;
  • 原因也很简单:grpool复用了协程,减少了协程的创建和销毁,减少了内存消耗;也因为协程的复用,总的协程数量减少,导致耗时变长。(一起干活的同事变少了,项目不就延期了嘛,很好理解。)
  • 所以:goframe的grpool通过协程复用,能够节省内存。结合我们的需求:如果你的服务器内存不高或者业务场景对内存占用的要求更高,那就使用grpool。如果服务器的内存足够,但是对耗时有较高的要求,就用原生的goroutine。
  • 文中的易错代码部分可以再重点消化一下。

参考资料

[1]「程序员升级打怪」知识星球: https://wx.zsxq.com/dweb2/index/group/15528828844882

欢迎Star GoFrame:https://github.com/gogf/gf

本文转载自微信公众号「 程序员升级打怪之旅」,作者「王中阳Go」,可以通过以下二维码关注。

转载本文请联系「 程序员升级打怪之旅」公众号。