您的解决方案在任何意义上都不是一个工作 goroutine 池：您的代码不限制并发 goroutine，也不会“重用”goroutine（它总是在收到新作业时启动一个新的 goroutine）。
生产者-消费者模式
正如Bruteforce MD5 Password cracker 发布的那样，您可以使用producer-consumer pattern。您可以有一个指定的 producer goroutine 来生成作业（要做/计算的事情），并将它们发送到 jobs 频道。您可以拥有一个固定的 consumer goroutine 池（例如其中 5 个），它们将循环传递作业的通道，每个都将执行/完成接收到的作业。
producer goroutine 可以在所有作业都生成并发送后简单地关闭 jobs 通道，正确地向 consumers 发出不会有更多作业的信号。通道上的for ... range 构造处理“关闭”事件并正确终止。请注意，在关闭频道之前发送的所有作业仍将被传递。
这将产生一个干净的设计，将导致固定（但任意）数量的 goroutine，并且它总是会使用 100% 的 CPU（如果 goroutines 的数量大于 CPU 核心的数量）。它还具有以下优点，即它可以使用正确选择信道容量（缓冲信道）和消费者 EM> Goroutines的数量。
请注意，此模型具有指定的生产者 goroutine 不是强制性的。您也可以有多个 goroutine 来生成作业，但是您也必须同步它们，以便仅在所有生产者 goroutine 完成生成作业时关闭 jobs 通道 - 否则尝试在 jobs 通道上发送另一个作业时已经完成已关闭会导致运行时恐慌。通常生产作业很便宜，并且可以以比执行速度快得多的速度生产，因此这种在 1 个 goroutine 中生产它们而许多人正在消费/执行它们的模型在实践中是很好的。
处理结果：
如果作业有结果，您可以选择指定的 result 渠道，在该渠道上可以交付（“发回”）结果，或者您可以选择在消费者处理结果时工作完成/完成。后者甚至可以通过处理结果的“回调”函数来实现。重要的是结果是可以独立处理还是需要合并（例如 map-reduce 框架）或聚合。
如果你使用results 通道，你还需要一个从它接收值的goroutine，防止消费者被阻塞（如果results 的缓冲区被填满，就会发生这种情况）。
与results 频道
我不会发送简单的string 值作为作业和结果，而是创建一个可以保存任何附加信息的包装器类型，因此它更加灵活：
type Job struct {
Id int
Work string
Result string
}
请注意，Job 结构也包装了结果，所以当我们发回结果时，它还包含原始的 Job 作为上下文 - 通常非常有用。另请注意，仅在通道上发送指针（*Job）而不是Job 值是有利可图的，因此无需制作Jobs 的“无数”副本，以及Job 结构值的大小变得无关紧要。
以下是这个生产者-消费者的样子：
我会使用 2 个sync.WaitGroup 值，它们的作用如下：
var wg, wg2 sync.WaitGroup
生产者负责生成要执行的作业：
func produce(jobs chan<- *Job) {
// Generate jobs:
id := 0
for c := 'a'; c <= 'z'; c++ {
id++
jobs <- &Job{Id: id, Work: fmt.Sprintf("%c", c)}
}
close(jobs)
}
完成后（不再有作业），jobs 频道将关闭，这向消费者发出信号，表示不会再有作业到达。
请注意，produce() 将jobs 频道视为仅发送，因为生产者只需要这样做：在其上发送作业（除了关闭它，但在仅发送频道上也允许这样做）。生产者中的意外接收将是编译时错误（在编译时早期检测到）。
消费者的职责是接收作业，只要可以接收到作业，并执行它们：
func consume(id int, jobs <-chan *Job, results chan<- *Job) {
defer wg.Done()
for job := range jobs {
sleepMs := rand.Intn(1000)
fmt.Printf("worker #%d received: '%s', sleep %dms\n", id, job.Work, sleepMs)
time.Sleep(time.Duration(sleepMs) * time.Millisecond)
job.Result = job.Work + fmt.Sprintf("-%dms", sleepMs)
results <- job
}
}
注意consume() 将jobs 频道视为仅接收；消费者只需要从中接收。同样，results 频道对于消费者只发送。
还要注意，results 频道不能在此处关闭，因为有多个消费者 goroutine，只有第一次尝试关闭它才会成功，更多的会导致运行时恐慌！ results 通道可以（必须）在所有消费者 goroutine 结束后关闭，因为这样我们就可以确定不会在 results 通道上发送更多值（结果）。
我们有需要分析的结果：
func analyze(results <-chan *Job) {
defer wg2.Done()
for job := range results {
fmt.Printf("result: %s\n", job.Result)
}
}
如您所见，只要结果可能会出现，这也会收到结果（直到results 频道关闭）。分析器的results 频道只接收。
请注意通道类型的使用：只要足够，就只使用 单向 通道类型，以便在编译时及早检测和防止错误。如果确实需要两个方向，请仅使用 双向 通道类型。
这就是将所有这些粘合在一起的方式：
func main() {
jobs := make(chan *Job, 100) // Buffered channel
results := make(chan *Job, 100) // Buffered channel
// Start consumers:
for i := 0; i < 5; i++ { // 5 consumers
wg.Add(1)
go consume(i, jobs, results)
}
// Start producing
go produce(jobs)
// Start analyzing:
wg2.Add(1)
go analyze(results)
wg.Wait() // Wait all consumers to finish processing jobs
// All jobs are processed, no more values will be sent on results:
close(results)
wg2.Wait() // Wait analyzer to analyze all results
}
示例输出：
这是一个示例输出：
如您所见，在所有作业入队之前，结果已经出来并得到分析：
worker #4 received: 'e', sleep 81ms
worker #0 received: 'a', sleep 887ms
worker #1 received: 'b', sleep 847ms
worker #2 received: 'c', sleep 59ms
worker #3 received: 'd', sleep 81ms
worker #2 received: 'f', sleep 318ms
result: c-59ms
worker #4 received: 'g', sleep 425ms
result: e-81ms
worker #3 received: 'h', sleep 540ms
result: d-81ms
worker #2 received: 'i', sleep 456ms
result: f-318ms
worker #4 received: 'j', sleep 300ms
result: g-425ms
worker #3 received: 'k', sleep 694ms
result: h-540ms
worker #4 received: 'l', sleep 511ms
result: j-300ms
worker #2 received: 'm', sleep 162ms
result: i-456ms
worker #1 received: 'n', sleep 89ms
result: b-847ms
worker #0 received: 'o', sleep 728ms
result: a-887ms
worker #1 received: 'p', sleep 274ms
result: n-89ms
worker #2 received: 'q', sleep 211ms
result: m-162ms
worker #2 received: 'r', sleep 445ms
result: q-211ms
worker #1 received: 's', sleep 237ms
result: p-274ms
worker #3 received: 't', sleep 106ms
result: k-694ms
worker #4 received: 'u', sleep 495ms
result: l-511ms
worker #3 received: 'v', sleep 466ms
result: t-106ms
worker #1 received: 'w', sleep 528ms
result: s-237ms
worker #0 received: 'x', sleep 258ms
result: o-728ms
worker #2 received: 'y', sleep 47ms
result: r-445ms
worker #2 received: 'z', sleep 947ms
result: y-47ms
result: u-495ms
result: x-258ms
result: v-466ms
result: w-528ms
result: z-947ms
在Go Playground 上试用完整的应用程序。
没有results 频道
如果我们不使用results 通道，但消费者 goroutine 会立即处理结果（在我们的例子中打印），代码会显着简化。在这种情况下，我们不需要 2 个 sync.WaitGroup 值（第二个只需要等待分析器完成）。
如果没有results 频道，完整的解决方案是这样的：
var wg sync.WaitGroup
type Job struct {
Id int
Work string
}
func produce(jobs chan<- *Job) {
// Generate jobs:
id := 0
for c := 'a'; c <= 'z'; c++ {
id++
jobs <- &Job{Id: id, Work: fmt.Sprintf("%c", c)}
}
close(jobs)
}
func consume(id int, jobs <-chan *Job) {
defer wg.Done()
for job := range jobs {
sleepMs := rand.Intn(1000)
fmt.Printf("worker #%d received: '%s', sleep %dms\n", id, job.Work, sleepMs)
time.Sleep(time.Duration(sleepMs) * time.Millisecond)
fmt.Printf("result: %s\n", job.Work+fmt.Sprintf("-%dms", sleepMs))
}
}
func main() {
jobs := make(chan *Job, 100) // Buffered channel
// Start consumers:
for i := 0; i < 5; i++ { // 5 consumers
wg.Add(1)
go consume(i, jobs)
}
// Start producing
go produce(jobs)
wg.Wait() // Wait all consumers to finish processing jobs
}
输出“类似于”results 频道的输出（当然执行/完成顺序是随机的）。
在Go Playground 上试试这个变体。