golang工作池

在golang编写服务程序过程中，如果每次来斗启动一个goroutine去处理任务，处理一个任务后就退出，这样势必会造成资源浪费。构建一个工作goroutine池来处理任务相对资源利用会少些，具体的情况需对比测试。

首先定义工作goroutine池，内部定义了两个变量，一个是任务队列，一个是需启动goroutine的数量

type WorkerPool struct {
    tasks    <-chan *string //任务队列长度
    poolSize int            //启动goroutine的数目
}

实现工作函数

func (p *WorkerPool) Run() {
    var wg sync.WaitGroup
    for i := 0; i < p.poolSize; i++ {
        wg.Add(1)
        go func() {
            for task := range p.tasks {
                fmt.Println("Consume Task", *task)
            }
            wg.Done()
        }()
    }

    wg.Wait()
    fmt.Println("WorkerPool | Pool exit.")
}

以下是测试代码

func main() {
    taskNum := 100
    projects := make(chan *string, taskNum)
    //启动生产任务goroutine
    go func() {
        for i := 0; ; i++ {
            s := "Project " + fmt.Sprintf("%d", i)
            fmt.Println("Produce task", s)
            projects <- &s
            time.Sleep(5 * time.Millisecond)
        }
    }()

    p := WorkerPool{
        tasks:    projects,
        poolSize: 10,
    }
    p.Run()
}

为什么需要工作池？

一般情况下，goroutine在操作系统上只要你的硬件资源够它是可以无限启动的。但是如果出现大规模的启动goroutine的情况会造成大量占用系统资源，我们知道普通的部署一个golang应用的时候操作系统不仅仅会运行golang程序还有其他辅助的程序运行，所以理论上讲工作池的目的就是为了限制golang的启动数量，保证不会出现硬件计算资源溢出的情况。

实际我们真的需要工作池吗？

理论上来讲，我们其实不需要在golang层面设置工作池的。如果是网络请求大部分时候我们会使用nginx或者其他网关，中间件作为golang程序的代理，我们可以在请求访问流量进入到golang程序之前使用nginx或者其他中间件限制流量或者使用熔断机制来保证我们的golang程序不会开满goroutine造成硬件计算资源溢出的情况。 如果流量小完全没必要限制goroutine 如果流量大没有熔断机制对整个服务都是很危险的。

工作池性能的讨论

我在编写自己的工作池之前使用了很多其他的工作池，我发现工作池本身并不会提升执行效率，反而会拖慢效率，使用工作池程序执行时间大概是原来的2/3,但是有一些pool会在一定程度上节省内存，比如ants，但内存的节省我觉得更多的是在于数据结构的复用，没有大量的重复创建数据对象导致的内存节省。

理论上来说，我们是不需要工作池的，但是实际应用场景，硬件资源有限，所以需要工作池来限制goroutine的个数。

这里看到一个应用工作池的应用场景，大家参考下：

Golang 实现工作池，处理每分钟百万请求数