17370845950

goroutine 启动后立即退出是因为主 goroutine 结束导致程序终止；应使用 sync.WaitGroup 显式等待，避免循环变量复用、慎用 time.Sleep，并对共享数据加锁或用 channel 同步。

goroutine 启动后立刻退出？检查是否缺少同步等待

Go 程启动后若主 goroutine（main）结束，整个程序立即退出，所有子 goroutine 被强制终止——这不是“泄漏”，是设计行为。常见错误是写完 go doSomething() 就直接 return 或函数结束。

• 用 sync.WaitGroup 显式等待：在启动前 wg.Add(1)，每个 goroutine 结束前调用 wg.Done()，主 goroutine 调用 wg.Wait() 阻塞直到全部完成
• 避免在循环中复用同一变量地址传参，例如 for _, v := range items { go func() { fmt.Println(v) }() } 会导致所有 goroutine 打印最后一个 v 值；应改为 go func(val string) { fmt.Println(val) }(v)
• time.Sleep 不是可靠同步手段，仅用于调试；它无法保证 goroutine 已执行完，且掩盖了真正的并发控制缺失

多个 goroutine 读写共享数据时 panic 或结果错乱？必须加锁或换通道

Go 不禁止裸共享内存，但 int、map、slice 等类型在并发读写时未加保护会触发 fatal error: concurrent map iteration and map write 或静默数据损坏。

• 简单计数场景优先用 sync/atomic：如 atomic.AddInt64(&counter, 1)，比 sync.Mutex 开销更低且无阻塞
• 结构体字段多或逻辑复杂时用 sync.Mutex 或 sync.RWMutex：注意锁的粒度——不要把 HTTP 处理逻辑整个包进 mu.Lock()，只包裹真正共享访问的几行
• 天然适合通信场景（如生产者-消费者）用 chan：发送方 ch ，接收方 item := ，底层自动同步，无需显式锁

goroutine 泄漏怎么发现和定位？关注 channel 阻塞与 WaitGroup 忘记 Done

goroutine 泄漏典型表现是程序常驻内存持续增长，pprof 查看 /debug/pprof/goroutine?debug=2 返回数百上千个处于 chan receive 或 semacquire 状态的 goroutine。

• 向已关闭的 channel 发送数据会 panic，但从已关闭 channel 接收会得到零值 + ok==false；务必确保 sender 关闭 channel 前，所有 receiver 已退出或通过其他信号（如 done chan struct{}）被通知
• WaitGroup 忘记 Done() 是最常见泄漏原因：尤其在 error 分支、defer 前 return、或 panic 恢复后遗漏调用；建议用 defer wg.Done() 放在 goroutine 函数开头
• 使用 context.Context 控制生命周期：启动 goroutine 时传入 ctx，在 select 中监听 ctx.Done()，收到信号后清理资源并退出

func worker(ctx context.Context, jobs <-chan int, results chan<- int) {
    for {
        select {
        case job, ok := <-jobs:
            if !ok {
                return
            }
            results <- job * 2
        case <-ctx.Done():
            return
        }
    }
}

要不要用 errgroup 或 semaphore 控制 goroutine 并发数？看场景再决定

无节制启动 goroutine（如为 10 万条记录起 10 万个 goroutine）会耗尽内存或文件描述符，但过度抽象（如强行套用第三方库）反而增加理解成本。

• 需要限制并发请求数（如批量调 API）：用 semaphore（基于 channel 的计数信号量）比自己写 sync.WaitGroup + sync.Mutex 更清晰；标准库暂无，可用 golang.org/x/sync/semaphore
• 需统一收集错误且任意一个出错就取消其余任务：用 errgroup.Group，它内置 context 取消传播和错误聚合，比手写更健壮
• 简单并行任务（如并发读几个文件）且数量可控（sync.WaitGroup + channel 就够用，不必引入额外依赖

实际并发控制中最容易被忽略的，是忘记给 goroutine 设置退出路径——无论是 channel 关闭、context 取消，还是明确的 done 信号，只要没有出口，它就永远卡在那儿。