Go程序Goroutine数量异常分析：预期与实际的差异
本文分析一段Go程序的运行情况，该程序的Goroutine数量与预期不符。程序目标是生成随机数，并利用多个Goroutine并发处理。核心逻辑在getnumber_5函数中，该函数启动20个randomnum Goroutine，这些Goroutine竞争向info通道写入数据。只有生成偶数的Goroutine才向info通道写入数据并退出。
程序关键代码片段（假设其余代码与问题描述一致）：
package main
import (
"bytes"
"fmt"
"github.com/gogf/gf/util/gconv"
"github.com/gogf/gf/util/grand"
"runtime"
"runtime/pprof"
"strconv"
"sync"
"time"
)
// ... (其余代码与问题描述中相同)
getgoruntinesize函数用于获取当前运行的Goroutine数量。程序运行后，打印的Goroutine数量为2（而非预期的1，即主线程）。这主要源于randomnum函数中的select语句存在潜在问题。
randomnum函数中，当n为偶数时，进入一个看似无限循环的select语句：
for {
select {
case info <- strconv.Itoa(n): // 写入偶数到info通道
return // 退出Goroutine
default: // default分支
// ... (此处可能存在问题)
}
}
问题在于select语句的default分支。即使info通道未关闭，default分支也会立即执行，导致Goroutine写入数据并退出。虽然WaitGroup机制确保了所有20个Goroutine都执行了w.Done()，但info通道的关闭与Goroutine的实际结束时间并非完全同步。因此，即使info通道关闭，部分Goroutine可能仍处于运行状态（虽然已完成任务），导致getgoruntinesize函数返回大于1的值。
WaitGroup负责计数，但它无法精确控制Goroutine的结束时间。WaitGroup.Wait()完成时，一些Goroutine可能因运行时调度延迟而未结束。这并非程序逻辑错误，而是Goroutine生命周期与WaitGroup机制配合上的细微差异。
为了更精确地控制Goroutine数量，需要改进randomnum函数的select语句，确保info通道关闭后所有Goroutine都能正确退出。这可能需要更精细的通道控制或其他并发控制机制，例如使用上下文（context）来协调Goroutine的结束。
