Swift

一句话概括 1️⃣ 问题背景：非结构化并发的痛点 传统线程 / 线程池模型： 问题： 任务孤儿化 父函数返回后，任务可能还在跑 没人管理它的生命周期 资源泄露 内存 / 文件句柄 / actor 状态

一句话定义（先抓住本质） 更直白一点： 1️⃣ 什么叫“结构化”？ 来看这个对比。 非结构化并发（传统） 任务： 被丢进某个池子 跑多久、谁负责、什么时候结束 —— 不清楚 生命周期： 与调用点无关

一句话对照结论（先记住） 1️⃣ structured concurrency 到底在“继承”什么？ 以一个普通的结构化子任务为例： 这是 structured concurrency，它会继承父任务

一句话结论（记住这个） 1️⃣ 先看最典型的例子 当 work2() 抛错时，发生的事是： 2️⃣ 运行期到底发生了什么？ ✅ 1. 第一个错误被“锁定” 第一个抛出的错误： 成为 TaskGroup

一、最标准、推荐的收集方式（for-await） 这是 官方推荐 + 最安全 的方式。 关键点 group.addTask → 并发执行 for await value in group → 串行、安

一句话先给结论 或者更狠一点的说法： 1️⃣ 为什么需要 TaskGroup？（设计动机） 先看一个“天真实现”的问题： ❌ 问题一堆： results 有数据竞争 子任务生命周期不受控 取消无法统一

一句话总览 1️⃣ 最重要的区别（先看这个） 维度 Task {} Task.detached {} 是否有父 Task ✅ 有 ❌ 没有 继承取消状态 ✅ ❌ 继承优先级 ✅ ❌ 继承 Task-l

在 Swift（乃至整个并发世界）里： 我会按 概念 → Swift 里的具体形态 → 与 async/await 的关系 → 常见误区 来讲。 一句话定义（先刻在脑子里） 换句话说： 1️⃣ 直观理

一句话结论 1️⃣ 编译器眼中的 await 源码： 在 AST / SIL 层面，这一行意味着三件事： 这里可能中断当前函数 后续代码不能假设仍在同一线程 跨越此点的局部变量必须被提升 所以 awa

一句话结论 1️⃣ 同步调用栈 vs async 调用栈 同步函数 栈帧连续 返回地址由 CPU 保存 局部变量在栈上 async 函数（遇到 await） 关键点： 2️⃣ async 函数真正保存

一句话总览 1️⃣ 从源码开始看 编译器看到的关键信息： foo 是 async 有 2 个 suspension point await bar() await baz(x) 👉 每一个 await

1️⃣ GCD 内部缓解机制：QoS 继承 1.1 原理 问题来源： 高 QoS 任务等待低 QoS 队列中的任务或锁 如果低 QoS 任务占用线程 → 高 QoS 任务被延迟 典型场景：串行队列 +

1️⃣ 什么是优先级反转 高优先级任务本应先执行 低优先级任务占用资源（锁、队列、线程） 中等或低优先级任务阻塞高优先级任务 → “反转” 简单例子（概念） 2️⃣ GCD 中优先级反转发生的条件 2

1️⃣ 场景示例 当前线程：主线程 目标队列：主队列（串行队列） 我们分析它的调度过程。 2️⃣ 主队列的调度模型 主队列 = 串行队列 队列内部只有一个线程执行 block → FIFO 顺序 队列

1️⃣ 什么是死锁 核心特点： 任务 A 等待资源/任务 B 完成 任务 B 等待资源/任务 A 完成 结果：双方都阻塞 → 系统或队列停滞 例子（抽象） 2️⃣ GCD 中死锁的核心场景 GCD 的

如果在 GCD 中 QoS 设置不当，会直接影响系统调度和应用性能，甚至可能导致 UI 卡顿、后台任务延迟或能耗增加。下面系统分析。 1️⃣ 核心原则 2️⃣ 常见问题与场景 2.1 高优先级任务过多

1️⃣ 核心结论 本质：防止高优先级任务被低优先级队列拖慢 → 保证响应性 临时提升仅在调度时生效，任务完成后恢复队列默认 QoS 2️⃣ QoS 继承机制 2.1 什么时候继承 当高 QoS 线程

QoS 和线程优先级并不是 1:1 映射，它们只是相关，但机制上存在差别。下面详细解释： 1️⃣ 核心结论 换句话说： QoS → 告诉系统“任务重要性”，GCD 根据这个在全局线程池中选择或创建线程

QoS（Quality of Service，服务质量）是 GCD 中用来 指示任务重要性和优先级 的机制，它不仅影响任务调度的优先级，还影响系统资源分配。下面详细解析。 1️⃣ QoS 的核心作用

1️⃣ 忘记 resume() 坑：创建 DispatchSource 后必须调用 resume() 才会启动事件源 原因：DispatchSource 默认是暂停状态 后果：事件永远不会触发 解决：