无法存储TaskGroup引用以替代DispatchGroup的技术疑问

一、替代方案：自定义任务管理器 #

由于TaskGroup的初始化是internal级别的，无法直接实例化持有，且它本身是为结构化并发的代码块绑定场景设计的，我们可以自己实现一个轻量的任务管理器，用数组存储Task实例来实现集中管理、跟踪和取消：

class SHACalculationManager {
    private var tasks: [Task<Void, Never>] = []
    private let lock = NSLock() // 保证任务数组的线程安全
    let semaphore = AsyncSemaphore(value: 8)

    private func calculateShaHash(for url: URL) async {
        await semaphore.wait()
        defer { semaphore.signal() } // 确保信号量一定会释放
        do {
            let sha256 = try url.sha256().hexStr
            print("sha256 is \(sha256 ?? "EMPTY")")
        } catch {
            print("Could not get sha256 of the file. \(error)")
        }
    }

    func kickoffShaCalculation(for url: URL) {
        let task = Task(priority: .utility) { [weak self] in
            guard let self = self else { return }
            await self.calculateShaHash(for: url)
            
            // 任务完成后从数组移除，避免内存泄漏
            self.lock.lock()
            self.tasks.removeAll { $0.id == task.id }
            self.lock.unlock()
        }
        
        lock.lock()
        tasks.append(task)
        lock.unlock()
    }

    // 统一取消所有任务
    func cancelAll() {
        lock.lock()
        tasks.forEach { $0.cancel() }
        tasks.removeAll()
        lock.unlock()
    }

    // 等待所有任务完成
    func waitForAll() async {
        lock.lock()
        let currentTasks = tasks
        lock.unlock()
        
        await withTaskGroup(of: Void.self) { group in
            for task in currentTasks {
                group.addTask { await task.value }
            }
        }
    }
}

这个方案的核心逻辑：

• 用Task数组记录所有运行/待运行的任务，通过NSLock处理多线程下的数组读写安全
• 任务完成后自动从数组移除，避免无效持有
• 利用Task原生的取消机制，实现一键取消所有任务
• 结合withTaskGroup批量等待任务完成，兼顾结构化并发的安全性

二、TaskGroup的设计考量 #

Swift的TaskGroup是结构化并发的核心组件，它的设计有明确的边界：

1. 绑定代码块的生命周期：withTaskGroup的闭包会强制等待所有子任务完成后才退出，确保任务层级清晰，不会出现游离的"僵尸任务"，从根源避免内存泄漏和状态混乱。
2. 自动取消传播：当TaskGroup所在的任务被取消时，所有子任务会自动收到取消信号。如果允许外部持有TaskGroup实例，开发者可能会在闭包外操作它，破坏这种自动传播的安全机制。
3. 内部实现的安全限制：DiscardingTaskGroup和普通TaskGroup的初始化被设为internal，就是为了防止开发者绕过结构化并发的上下文管理，直接实例化导致并发状态失控。

总结来说，TaskGroup适合已知任务范围、批量执行的场景，并不适合长期管理零散添加的任务。如果需要分散添加任务的能力，自定义任务管理器是更贴合需求的选择。

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