在Swift结构化并发模型里，TaskGroup承担着批量派生与统一管理子任务的责任。当外部调用cancel方法或者任务树因错误被抛出而自动取消时，组内尚未完成的子任务会收到取消信号。此时如果多个任务通过引用类型或全局变量共享了可变状态，并且没有在取消路径上建立明确的内存屏障，那么某一个任务在取消前写入的值，未必能按照代码顺序被其他任务或后续逻辑观察到。这种内存一致性错误不会每次都复现，却在并发压力与特定CPU架构下频繁出现。
TaskGroup取消机制与内存重排风险
TaskGroup的取消遵循结构化并发的树形传播规则。父任务一旦进入取消状态，运行中的子任务在下一次挂起点或显式检查Task.isCancelled时便会终止。问题在于，Swift编译器与底层运行时为了性能会对独立的内存操作做重排，CPU缓存亦会导致不同执行单元看到的内存视图不一致。若任务A在取消前对某个数组追加了元素，而任务B在取消后读取该数组，且两者之间不存在同步原语，则B可能读到旧长度甚至发生越界。
下面这段代码演示了风险所在：两个子任务共享一个未加保护的计数器，取消发生后主任务直接读取结果。
import Foundation
func riskyGroup() async {
var sharedCount = 0
await withTaskGroup(of: Void.self) { group in
for _ in 0..<3 {
group.addTask {
if Task.isCancelled { return }
sharedCount += 1
}
}
await group.waitForAll()
}
print(sharedCount)
}
上述写法在语言层面就是错误的，因为闭包捕获的sharedCount并非Sendable，且缺乏任何内存屏障。即使不考虑取消，单纯并发自增就已经产生竞态。当取消介入时，部分自增可能因任务提前返回而丢失，而主任务读取时更无法保证看到完整的写入顺序。
使用Sendable与原子类型建立内存屏障
要避免取消后的可见性问题，第一步是让共享数据具备Sendable语义，或者使用系统提供的原子容器。Swift 5.9之后引入了原子操作库，通过ManagedAtomic可以在任务之间安全地累加数值，其底层已经插入了必要的内存屏障指令，保证释放与获取顺序。
以下示例将计数器改为原子类型，并在取消时通过load获取最新值，确保主任务观察到所有已完成写入：
import Foundation
import _Concurrency
func safeGroup() async {
let counter = ManagedAtomic<Int>(0)
await withTaskGroup(of: Void.self) { group in
for _ in 0..<3 {
group.addTask {
if Task.isCancelled { return }
counter.wrappingIncrement(by: 1, ordering: .relaxed)
}
}
await group.waitForAll()
}
let final = counter.load(ordering: .acquiring)
print(final)
}
这里 wrappingIncrement 使用 relaxed 顺序仅保证原子性，而最后的 load 使用 acquiring 排序，与之前可能的 releasing 写入形成同步，从而建立内存屏障。如果子任务在取消前用 releasing 顺序写入共享缓冲区，主任务用 acquiring 读取，就能杜绝因重排导致的内容不可见。
对于复杂结构，可借助 Actor 隔离状态。Actor 的方法调用本身带有跨任务同步点，相当于在取消边界处强制了内存可见性。将共享模型放入 actor 后，TaskGroup 中的子任务通过 await 修改状态，取消发生时未完成的 await 会被合理中断，已完成的部分则确定可见。
取消路径上的有序性设计与调试手段
除了数据类型，任务取消后的代码顺序也需要审视。很多开发者在子任务末尾写清理逻辑，却未意识到清理写入若发生在取消检查之后便不会执行。正确做法是在任务入口处用 defer 块放置必须落盘的状态标记，并保证标记写入带有释放屏障。
我们可以利用任务本地值或显式信号量控制顺序。下例用 DispatchSemaphore 搭配原子标志，在取消时仍确保一条收尾记录被持久化：
import Foundation
func orderedCancel() async {
let done = ManagedAtomic<Bool>(false)
let sem = DispatchSemaphore(value: 0)
await withTaskGroup(of: Void.self) { group in
group.addTask {
defer {
done.store(true, ordering: .releasing)
sem.signal()
}
while !Task.isCancelled {
// 模拟工作
}
}
group.cancelAll()
await group.waitForAll()
}
sem.wait()
let visible = done.load(ordering: .acquiring)
print("cleanup done: (visible)")
}
该模式把收尾动作放在 defer 中，无论循环因取消退出还是自然结束都会运行。store 使用 releasing，load 使用 acquiring，两者构成内存屏障，使主任务在 sem 返回后必然看到 done 的最新值。实际工程中，应当结合 XCTest 的并发测试与 Thread Sanitizer 来捕获重排与数据竞争，尤其在 iOS 真机多核环境下验证取消逻辑。
总结来说，TaskGroup 的取消不是简单终止执行，它牵涉到任务树、共享内存与CPU缓存的多层交互。只有把数据限制在 Sendable 或 Actor 边界内，并在取消相关写入处使用正确的原子排序，才能确保任务取消后内存操作具备可见性与有序性，从根源上规避那些难以排查的一致性错误。