递归函数中使用Goroutines多线程扫描文件反而更慢的原因排查

核心原因分析 #

• IO资源的串行本质：文件系统的元数据访问（比如遍历目录）大多是串行化的——哪怕机械硬盘或SSD，同一时间能处理的IO请求数量有限，多goroutine并不能让硬件并行处理这些请求，反而会增加调度开销。
• Mutex的竞争开销：用sync.Mutex保护photoPaths切片时，每个goroutine写入都要抢锁、释放锁，频繁的锁竞争会带来额外的上下文切换成本，拖慢整体速度。
• goroutine调度的冗余开销：给每个目录都启动goroutine会导致runtime频繁调度阻塞（等待IO）的goroutine，调度本身的开销会抵消理论上的并行收益。

优化方向建议 #

• 控制并发goroutine数量：用带缓冲的channel做信号量，限制并发数（比如10~20个），避免过度调度和锁竞争。
• 用channel替代Mutex收集结果：放弃Mutex保护切片，改用channel接收各个goroutine的扫描结果，在主goroutine统一收集，彻底避免锁竞争。示例代码：

  func scanDir(path string, resultChan chan<- string, wg *sync.WaitGroup, sem chan struct{}) {
      defer wg.Done()
      sem <- struct{}{} // 获取并发信号量
      defer func() { <-sem }() // 释放信号量
  
      files, err := ioutil.ReadDir(path)
      if err != nil {
          return
      }
      for _, file := range files {
          fullPath := filepath.Join(path, file.Name())
          if file.IsDir() {
              wg.Add(1)
              go scanDir(fullPath, resultChan, wg, sem)
          } else {
              resultChan <- fullPath
          }
      }
  }
  
  // 主逻辑调用
  func main() {
      rootPath := "/your/target/path"
      resultChan := make(chan string, 100)
      sem := make(chan struct{}, 10) // 限制最多10个并发goroutine
      var wg sync.WaitGroup
  
      wg.Add(1)
      go scanDir(rootPath, resultChan, &wg, sem)
  
      // 等待所有扫描goroutine完成后关闭结果通道
      go func() {
          wg.Wait()
          close(resultChan)
      }()
  
      // 收集所有结果
      var photoPaths []string
      for path := range resultChan {
          photoPaths = append(photoPaths, path)
      }
  }
  

• 利用原生优化的遍历方法：使用Go 1.16+的filepath.WalkDir，它内部做了系统调用优化，比手动递归更高效；若要并发，可以按目录树层级启动goroutine，而非每个文件/目录都开。

补充说明 #

文件扫描属于IO密集型任务，当IO资源成为瓶颈时，过多并发只会增加额外开销。只有当扫描目标分布在多个独立存储设备时，多线程才可能带来性能提升。

内容的提问来源于stack exchange，提问作者Michael