Golang中如何理解wg.Add()的这种行为？

这是一个典型的并发控制问题。问题的核心在于 wg.Add(1) 在循环中的位置导致了goroutine启动速度远超过系统文件描述符的限制。

在第一个版本中，wg.Add(len(xmlFiles)) 一次性设置了等待计数，然后所有goroutine几乎同时启动。虽然这也会快速消耗文件描述符，但由于 defer xmlFileOpened.Close() 的存在，文件会在每个goroutine执行完毕后及时关闭。

在第二个版本中，wg.Add(1) 在循环内部，每次迭代都会立即启动一个goroutine。当你有35万个文件时，系统会尝试同时打开大量文件，远超过操作系统对单个进程的文件描述符限制（通常是1024或4096）。

问题的关键在于：wg.Add(1) 在goroutine启动前调用，但goroutine的实际执行是异步的。这意味着循环会以极快的速度创建goroutine，而每个goroutine中的 singleRun() 函数需要时间执行。在文件关闭之前，新的文件已经被打开，导致同时打开的文件数量迅速超过系统限制。

这里有一个更清晰的示例来说明这个问题：

// 问题版本 - 会导致 "too many open files"
func problematicVersion() {
    var wg sync.WaitGroup
    
    for i := 0; i < 100000; i++ {
        wg.Add(1)  // 立即增加计数
        go func(id int) {
            defer wg.Done()
            // 模拟文件操作
            f, _ := os.Open(fmt.Sprintf("file_%d.txt", id))
            defer f.Close()
            time.Sleep(time.Millisecond * 10)  // 模拟处理时间
        }(i)
    }
    wg.Wait()
}

// 解决方案 - 使用工作池限制并发数
func fixedVersion() {
    var wg sync.WaitGroup
    maxConcurrent := 100  // 限制并发goroutine数量
    
    sem := make(chan struct{}, maxConcurrent)
    
    for i := 0; i < 100000; i++ {
        wg.Add(1)
        sem <- struct{}{}  // 获取信号量
        
        go func(id int) {
            defer wg.Done()
            defer func() { <-sem }()  // 释放信号量
            
            f, _ := os.Open(fmt.Sprintf("file_%d.txt", id))
            defer f.Close()
            time.Sleep(time.Millisecond * 10)
        }(i)
    }
    wg.Wait()
}

// 另一种解决方案 - 批量处理
func batchVersion() {
    var wg sync.WaitGroup
    batchSize := 1000
    
    files := make([]string, 100000)
    for i := range files {
        files[i] = fmt.Sprintf("file_%d.txt", i)
    }
    
    for i := 0; i < len(files); i += batchSize {
        end := i + batchSize
        if end > len(files) {
            end = len(files)
        }
        
        batch := files[i:end]
        wg.Add(len(batch))
        
        for _, file := range batch {
            go func(f string) {
                defer wg.Done()
                fp, _ := os.Open(f)
                defer fp.Close()
                time.Sleep(time.Millisecond * 10)
            }(file)
        }
        wg.Wait()  // 等待当前批次完成
    }
}

在你的具体案例中，虽然两个版本都有相同数量的goroutine，但第二个版本的goroutine启动节奏不同。第一个版本中，所有goroutine几乎同时启动和竞争执行，而第二个版本中，循环会持续快速地创建新的goroutine，导致系统资源被迅速耗尽。

要修复这个问题，你需要限制并发goroutine的数量。这里是一个适用于你场景的修正版本：

func PareseWithGoroutinesFixed() {
    files, err := os.ReadDir("data")
    if err != nil {
        log.Fatal(err)
    }

    var xmlFiles []fs.DirEntry
    for _, file := range files {
        if strings.HasSuffix(file.Name(), ".xml") {
            xmlFiles = append(xmlFiles, file)
        }
    }

    var wg sync.WaitGroup
    maxWorkers := 100  // 根据系统调整这个值
    sem := make(chan struct{}, maxWorkers)
    
    for _, xmlFile := range xmlFiles {
        wg.Add(1)
        sem <- struct{}{}  // 控制并发数
        
        go func(file fs.DirEntry) {
            defer wg.Done()
            defer func() { <-sem }()  // 释放信号量
            singleRun(file)
        }(xmlFile)
    }
    wg.Wait()
}

这个问题的根本原因是操作系统对单个进程同时打开文件数量的限制，而不是 sync.WaitGroup 本身的行为问题。wg.Add(1) 在循环内部本身没有错，但它会导致goroutine创建速度超过系统资源处理能力。