sync.WaitGroup不等待的常见原因及解决方法

本文深入剖析了Go语言中sync.WaitGroup看似调用却无法正确等待goroutine完成的常见陷阱，直击for循环内启动goroutine时因闭包捕获循环变量导致的所有协程共享同一变量副本这一根本原因，并清晰对比讲解两种安全传参方案——显式函数参数传递和循环内变量重声明，辅以可立即运行的完整示例和关键调试技巧，帮助开发者彻底规避竞态隐患，写出真正可靠、健壮的并发代码。

本文详解Go中sync.WaitGroup未按预期阻塞的典型问题，核心在于for循环中goroutine捕获变量的闭包陷阱，提供两种安全传参方案并附可运行示例。

本文详解Go中sync.WaitGroup未按预期阻塞的典型问题，核心在于for循环中goroutine捕获变量的闭包陷阱，提供两种安全传参方案并附可运行示例。

在使用 sync.WaitGroup 控制并发 goroutine 执行流程时，一个高频且隐蔽的错误是：wg.Wait() 看似被调用，但程序却立即返回，goroutine 未真正执行完毕，甚至输出全为 0 或 panic。这并非 WaitGroup 本身失效，而是典型的 变量捕获（closure capture）陷阱——尤其发生在 for range 循环中启动 goroutine 的场景。

? 问题根源：共享变量 vs 独立副本

原始代码的问题在于：

for _, myurl := range listOfUrls {
    go func() {
        body := getUrlBody(myurl) // ❌ 所有 goroutine 共享同一个 myurl 变量！
        fmt.Println(len(body))
        wg.Done()
    }()
}

Go 中 for range 的迭代变量 myurl 在整个循环中是复用的同一内存地址。当 goroutine 实际执行时（可能在循环结束后），myurl 已被更新为最后一次迭代的值，甚至超出范围（如空字符串或零值）。因此所有 goroutine 都在处理“过期”的 myurl，导致 getUrlBody("") 返回空内容，len(body) 为 0。

✅ 关键原则：每个 goroutine 必须持有其所需参数的独立副本，而非对循环变量的引用。

✅ 正确解法一：将变量作为参数传入匿名函数（推荐）

通过显式将当前迭代值作为参数传递给闭包，确保每个 goroutine 拥有专属副本：

func printSize(listOfUrls []string) {
    var wg sync.WaitGroup
    wg.Add(len(listOfUrls)) // 注意：原文 typo "listOfUrl" 已修正

    for _, myurl := range listOfUrls {
        go func(url string) { // ✅ 参数 url 是独立副本
            body := getUrlBody(url)
            fmt.Printf("URL: %s → Body length: %d\n", url, len(body))
            wg.Done()
        }(myurl) // ✅ 立即传入当前 myurl 值
    }

    wg.Wait() // ✅ 安全阻塞，直到所有 goroutine 调用 Done()
}

✅ 正确解法二：在循环内重新声明变量（等效但稍隐晦）

利用 Go 的短变量声明 := 在每次迭代中创建新变量，覆盖外层 myurl 的引用：

func printSize(listOfUrls []string) {
    var wg sync.WaitGroup
    wg.Add(len(listOfUrls))

    for _, myurl := range listOfUrls {
        myurl := myurl // ✅ 创建同名新变量，绑定当前迭代值
        go func() {
            body := getUrlBody(myurl) // ✅ 此时闭包捕获的是新变量 myurl
            fmt.Printf("URL: %s → Body length: %d\n", myurl, len(body))
            wg.Done()
        }()
    }

    wg.Wait()
}

⚠️ 注意事项与最佳实践

• wg.Add() 必须在 goroutine 启动前调用：否则存在竞态（Add 和 Done 并发修改计数器）。
• 避免 wg.Add(0) 或负数：会导致 panic；确保 Add 参数与实际启动的 goroutine 数量严格一致。
• wg.Done() 必须被调用且仅调用一次：建议用 defer wg.Done() 防止遗漏（尤其在含 error 分支的函数中）：

  go func(url string) {
      defer wg.Done() // 更健壮
      body := getUrlBody(url)
      fmt.Println(len(body))
  }(myurl)

• WaitGroup 不可复制：应作为局部变量或指针传递，切勿值拷贝。
• 调试技巧：在 goroutine 内打印 &myurl 地址，可直观验证是否所有 goroutine 共享同一地址。

? 补充：完整可运行示例（含模拟 getUrlBody）

package main

import (
    "fmt"
    "sync"
    "time"
)

func getUrlBody(url string) string {
    // 模拟网络延迟（真实场景中应加超时控制）
    time.Sleep(time.Second * 1)
    return url + "_fake_body_content"
}

func printSize(listOfUrls []string) {
    var wg sync.WaitGroup
    wg.Add(len(listOfUrls))

    for _, myurl := range listOfUrls {
        myurl := myurl
        go func() {
            defer wg.Done()
            body := getUrlBody(myurl)
            fmt.Printf("[✅] %s → %d bytes\n", myurl, len(body))
        }()
    }

    fmt.Println("[⏳] Waiting for all requests...")
    wg.Wait()
    fmt.Println("[✔️] All done!")
}

func main() {
    urls := []string{"https://example.com", "https://golang.org", "https://github.com"}
    printSize(urls)
}

运行此代码将看到三条带延迟的日志依次输出，最后打印 All done! —— 这正是 WaitGroup 正确生效的表现。

掌握这一闭包陷阱的本质，不仅能解决 WaitGroup 不等待的问题，更是写出健壮并发 Go 代码的关键基石。

本篇关于《sync.WaitGroup不等待的常见原因及解决方法》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！