在Swift并发模型中，TaskGroup是最常用的结构化并发工具之一。它允许开发者动态添加多个子任务，并在组的生命周期结束时自动等待所有子任务完成。听起来很安全，但一个常见的误解是：调用cancelAll()之后，子任务会立即停止并释放所有资源。实际上，取消只是一个协作式的信号，子任务必须主动检查并自行清理。如果子任务内部持有大块缓冲区、打开了文件句柄或网络连接，而取消路径上没有执行清理代码，这些资源就会一直滞留，直到进程退出。本文将围绕这个问题展开，从机制、代码实践到Instruments检测，完整梳理排查思路。
TaskGroup的取消机制到底是怎么运作的
要理解任务取消后的资源泄漏，首先需要弄清楚取消信号是如何传播的。TaskGroup遵循结构化并发的规则：当父任务被取消，或者显式调用了group.cancelAll()，取消标记会被设置到组内所有子任务上。但这个标记只是一个标志位，调度器不会强制中断子任务的执行流。换句话说，如果子任务正在一个不含取消检查的紧密循环中处理数据，它会继续跑完，期间持有的内存不会释放。
另一个关键点是withTaskCancellationHandler。许多开发者以为把清理代码放在defer中就万事大吉，但如果子任务阻塞在一个不支持取消的原生调用上（比如传统的POSIX文件读写），Swift无法中断它。此时需要用取消处理器主动触发中断，例如关闭底层描述符让阻塞调用返回错误。下面这个例子展示了典型的错误写法和正确写法的差异：
// 错误示范：取消后文件句柄不会被关闭
func badExample(_ group: inout TaskGroup<Void>) {
group.addTask {
let handle = FileHandle(forReadingAtPath: "/tmp/large.log")!
defer { try? handle.close() } // 如果任务卡在read，defer迟迟不执行
while true {
let chunk = try handle.read(upToCount: 1 << 20)
guard let chunk, !chunk.isEmpty else { break }
process(chunk) // 循环中从不检查 Task.isCancelled
}
}
}
// 正确示范：响应取消并尽快走清理路径
func goodExample(_ group: inout TaskGroup<Void>) {
group.addTask {
let handle = FileHandle(forReadingAtPath: "/tmp/large.log")!
defer { try? handle.close() }
while let chunk = try handle.read(upToCount: 1 << 20),
!chunk.isEmpty {
if Task.isCancelled { break } // 检查取消标记，触发defer清理
process(chunk)
}
}
}
两者的区别在取消发生时立刻显现：第一种写法中，即使外部调用了cancelAll()，循环仍会读完整个文件；第二种写法则在下一次迭代时退出循环，defer块关闭句柄。如果文件有几GB，第一种写法额外占用的内存与文件描述符存活时间会显著拉长。更隐蔽的情况是，子任务抛出错误或被取消时，开发者只在正常路径上写了清理逻辑，异常路径被遗漏，这需要借助工具才能发现。
编写取消安全的资源清理逻辑
取消安全的核心原则只有一条：清理代码必须放在保证执行的路径上。Swift中的defer是最佳载体，但前提是函数能够返回。对于长时间运行的任务，应当在循环边界、每次await挂起点前后主动检查Task.isCancelled或调用Task.checkCancellation()。后者会在已取消时抛出CancellationError，配合do-catch可以统一走清理分支。
对于跨类型的资源，比如自定义的下载管理器持有了临时目录和网络会话，建议把资源生命周期封装到一个不可克隆的句柄类型中，利用deinit兜底。虽然ARC下deinit的执行时机取决于引用是否清空，但结构化并发保证了TaskGroup返回后子任务的引用会被释放，此时deinit可以作为最后一道防线。下面是一个结合取消处理器的完整模式：
final class ResourceBox: @unchecked Sendable {
private var handle: FileHandle?
init(path: String) { handle = FileHandle(forReadingAtPath: path) }
deinit { try? handle?.close() } // 兜底清理，防止遗漏
func release() { try? handle?.close(); handle = nil }
}
func monitoredTask(_ group: inout TaskGroup<Void>) {
group.addTask {
let box = ResourceBox(path: "/tmp/data.bin")
defer { box.release() }
try await withTaskCancellationHandler {
while let chunk = try box.readChunk() {
try Task.checkCancellation() // 抛出 CancellationError
process(chunk)
}
} onCancel: {
box.release() // 取消时立即释放，阻塞调用会因描述符失效而返回
}
}
}
值得注意的是，onCancel闭包会在取消发生的线程上同步执行，因此它必须是非阻塞且线程安全的。在这个模式里，取消处理器主动关闭文件描述符，即使子任务正阻塞在read系统调用上，内核也会让该调用返回错误，从而打破阻塞。这种模式同样适用于socket、数据库连接等其他句柄类型。另外，要小心在取消处理器中重复释放资源导致的双重关闭问题，示例中的release方法把handle置为nil，保证了幂等性。
用Xcode Instruments定位泄漏的资源
代码写对了没有，最终要靠工具验证。打开Xcode，选择Product菜单中的Profile，或直接使用快捷键Command+I，Instruments会列出所有可用模板。针对内存问题，核心模板有三个：Allocations用于追踪所有堆对象的分配与释放，Leaks用于检测循环引用导致的真正泄漏，而针对文件句柄，则可以使用System Trace模板中的File Activity工具，或直接用lsof命令辅助观察。
具体操作流程如下：先在模拟器或真机上运行应用，进入使用TaskGroup的功能页面，触发任务取消操作，然后回到Allocations面板，点击左上角的Mark Generation按钮打一个标记，等待几秒后再打一个标记。如果第二个Generation中持续增长、且类别为Swift Task或你的业务类型的对象，就是未释放的嫌疑对象。选中可疑行后，在右侧Extended Detail面板中可以查看完整的调用栈，直接定位到addTask闭包内的分配位置。Leaks模板则以红色感叹号直接标出泄漏对象，配合栈回溯能快速判断是哪一个子任务持有了循环引用。典型的场景是子任务闭包捕获了self，而self又通过某种途径持有了Task句柄。
文件句柄的检测略有不同。Instruments的System Trace模板提供了File Activity工具，可以记录每一次open、close调用及其时间点。操作时先清空已有记录，触发一次完整的取消流程，然后按文件路径过滤，检查是否有open记录没有配对的close记录。如果不想打开Instruments，也可以在调试器中执行lsof -p 进程号，对比任务取消前后的输出行数，行数不减说明句柄仍在滞留。下面给出一个便于在测试中观察的可复现代码：
import Foundation
func runLeakTest() async {
await withTaskGroup(of: Void.self) { group in
for i in 0..<50 {
group.addTask {
// 故意持有大缓冲区且不检查取消
let buffer = UnsafeMutablePointer<UInt8>.allocate(capacity: 10 <<< 20)
defer { buffer.deallocate() }
while !Task.isCancelled { sleep(1) }
_ = i
}
}
group.cancelAll()
}
// 任务组结束后，用Instruments的Allocations确认缓冲区已全部释放
}
跑这段代码时，如果删掉defer那一行，Allocations中会立刻出现约500MB的内存增长且不回落；而Leaks面板可能不会有任何提示，因为裸指针内存不属于OC对象图，Leaks检测不到它。这也提醒我们：Leaks只能抓循环引用，裸内存、文件描述符必须依赖Allocations和File Activity，三个工具要配合使用才不会漏检。
并发代码资源管理检查清单
结合上面的分析，可以总结出一份实用的检查清单，供代码评审时逐条核对。第一，每个addTask闭包内部，凡是分配了资源的位置，是否都有对应的defer清理；第二，所有长循环是否有取消检查，检查频率是否与资源占用规模匹配；第三，阻塞在不可取消API上的任务，是否使用了withTaskCancellationHandler进行主动打断；第四，onCancel闭包是否做到线程安全与幂等，避免与defer路径产生双重释放冲突。
此外还有两点容易忽略。一是TaskGroup的取消会向下传播到子任务创建的任何嵌套任务与异步序列，但如果子任务内部又用Task.detached启动了非结构化任务，取消链会断裂，这类任务必须单独管理生命周期，最好在评审时直接质疑使用detached的必要性。二是取消的传播有时序性，cancelAll之后组仍会等待所有子任务返回，如果某个子任务长时间不响应取消，整个withTaskGroup调用点也会被拖住，外部表现是界面卡住或超时，这往往就是资源泄漏问题的前兆信号。
最后建议把Instruments检测纳入固定流程：每次改动并发模块后，跑一次包含取消场景的压测脚本，用Allocations的Generation对比功能确认内存曲线归零，用File Activity确认描述符配对关闭。自动化方面，可以在持续集成中通过xctrace record命令行工具录制trace文件并归档，便于回归对比。资源泄漏问题的特点是积累缓慢、复现困难，前期多花十分钟验证，远比线上排查OOM或描述符耗尽划算得多。
Swift TaskGroup任务取消Instruments内存检测修改时间：2026-09-12 03:50:43