Swift CLI并行处理数千文件时命令行运行卡住 仅Xcode测试正常

• 线程池耗尽：CLI环境下GCD的默认线程池上限远低于Xcode单元测试环境。你的原有代码中，concurrentPerform虽然控制了并行处理的线程数，但短时间内向串行队列提交数千个异步写任务时，如果processFile执行速度快，会快速占满有限的线程池资源，导致后续写任务无法被调度，DispatchGroup计数永远无法归零，主线程阻塞在group.wait()永久卡住。XCTest环境预分配了更多线程资源，所以不会触发该问题。
• 冗余的队列嵌套：你将concurrentPerform套在了一层自定义并发队列的异步块中，属于完全多余的操作，额外增加了线程调度开销，也进一步加剧了线程资源的占用。
• 缺少自动释放池：CLI环境默认没有全局自动释放池，处理数千个文件过程中产生的大量临时对象无法及时释放，内存占用过高也会导致程序运行异常，而XCTest环境会自动维护全局自动释放池，不会出现该问题。

直接优化原有逻辑，去掉冗余代码，增加自动释放池，也可以简化掉DispatchGroup的使用，用串行队列同步等待的方式更简单可靠：

let filePaths: [String] = // 数千个待处理的文件路径数组
let serialWriteQueue = DispatchQueue(label: "my.serial.queue", qos: .userInitiated)

// concurrentPerform本身是同步方法，会自动匹配CPU核心数控制并行度，不需要额外套并发队列
DispatchQueue.concurrentPerform(iterations: filePaths.count) { fileIndex in
    // 增加自动释放池，及时释放每个文件处理过程中产生的临时对象
    autoreleasepool {
        let filePath = filePaths[fileIndex]
        let result = processFile(path: filePath)
        serialWriteQueue.async {
            writeResult(result)
        }
    }
}

// 同步等待串行写入队列的所有任务执行完成，不需要额外维护DispatchGroup
serialWriteQueue.sync {}

• 如果文件总量超过1万，可以将文件数组拆分为和CPU核心数匹配的批次处理，避免CPU占用过高影响系统其他任务运行。
• 提前打开统一写入的目标文件句柄，不要每次调用writeResult都重复打开、关闭文件，可大幅提升写入速度，降低IO资源占用。

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