阅读视图

发现新文章,点击刷新页面。

RxSwift 中 asDriver() 详解

本文从「是什么、为什么用、怎么用」三个层面,详细讲解 RxSwift 中的 asDriver() 方法,适配新手理解,兼顾实用性和易懂性。

一、asDriver() 核心含义

asDriver() 是 RxSwift 中专门用于将 Observable ** 序列(或其他可转换序列,如 ** Single Maybe )转换为 ** Driver ** 序列 的方法。

简单来说,它是一个「序列类型转换器」:输入为 Observable,输出为 Driver,且转换过程中会自动为序列附加 Driver 特有的「UI 友好型安全特性」,无需手动额外配置。

补充前提:Driver 并非全新序列类型,而是 Observable 的「专用子类/特殊封装」,专门针对 UI ** 绑定场景**(如更新 Label 文本、刷新 TableView 数据、修改按钮状态等)设计,因此也被称为「UI 友好型序列」。

二、asDriver() 自动附加的 3 个关键安全特性

这是 Driver 的核心价值,也是 asDriver() 的核心意义——自动规避 UI 开发中常见的 3 个坑,减少冗余代码:

1. 确保在主线程订阅/发送事件

UI 操作必须在主线程执行(否则会崩溃或界面错乱),asDriver() 会自动将序列的事件派发切换到主线程,无需手动编写 observe(on: MainScheduler.instance)

2. 确保序列不会发送 Error 事件

Driver 序列仅支持发送 next(传递数据)和 completed(序列结束)事件,不支持发送 Error ** 事件**。若原始 Observable 可能发送错误,asDriver() 要求必须提供「错误兜底值」(或错误处理逻辑),避免 UI 绑定链路因错误中断。

3. 具备「共享订阅」(共享事件流)特性

对应 RxSwift 中的 share(replay: 1, scope: .whileConnected),多个观察者订阅同一个 Driver 序列时,不会重复执行上游逻辑(如网络请求、数据库查询),仅共享一份事件流,既节省资源,又能保证多个 UI 组件拿到的数据一致。

三、为什么需要用 asDriver()(适用场景)

核心场景:当需要将 Rx 序列的结果绑定到 UI 控件时,优先使用 ** asDriver() ** 转换为 ** Driver ** 序列

反例:直接用 Observable 绑定 UI(需手动处理安全问题)


// 直接用 Observable 绑定 UI,需手动处理 3 个安全问题
someObservable
    .observe(on: MainScheduler.instance) // 1. 切换到主线程
    .catch { error in Observable.just("默认值") } // 2. 捕获错误,避免链路中断
    .share(replay: 1, scope: .whileConnected) // 3. 共享订阅
    .bind(to: label.rx.text)
    .disposed(by: disposeBag)

正例:用 asDriver() 绑定 UI(自动处理安全问题,代码简洁)


// asDriver() 自动处理安全问题,代码更简洁
someObservable
    .asDriver(onErrorJustReturn: "默认值") // 转换为 Driver,指定错误兜底值
    .drive(label.rx.text) // Driver 专用绑定方法(替代 bind)
    .disposed(by: disposeBag)

四、asDriver() 的常见用法

asDriver() 有两个常用重载方法,对应不同错误场景:

场景 1:原始序列可能发送错误(需兜底值)

使用 asDriver(onErrorJustReturn:),传入「错误时序列要发送的默认值」,错误会被自动捕获,序列发送默认值后正常结束,不中断链路。


// 示例:网络请求结果绑定到 UI(网络请求可能失败,需兜底)
let networkRequest: Observable<String> = fetchDataFromServer() // 假设是网络请求序列

networkRequest
    .asDriver(onErrorJustReturn: "网络请求失败,请重试") // 错误兜底文本
    .drive(label.rx.text) // 绑定到 UILabel
    .disposed(by: disposeBag)

场景 2:原始序列不可能发送错误(如本地数据、UI 事件)

直接使用asDriver(),无需传入兜底值(因序列不会产生错误)。


// 示例:按钮点击事件转换为 Driver(按钮点击不会有错误)
let buttonTap: Observable<Void> = button.rx.tap

buttonTap
    .asDriver() // 无需兜底值,直接转换
    .drive(onNext: {
        print("按钮被点击了")
        // 执行 UI 操作,无需担心线程问题
    })
    .disposed(by: disposeBag)

五、补充:Driver 专用绑定方法 drive()

序列被 asDriver() 转换为 Driver 后,推荐使用 drive() 绑定,而非 bind(),原因如下:

  • 语义更清晰:drive() 意为「驱动 UI 变化」,明确适配 UI 绑定场景;

  • 更安全:drive() 内部已默认处理 UI 绑定的相关细节,避免意外绑定到非 UI 场景。

六、总结

  1. asDriver() 是 RxSwift 中**「将 ** Observable ** 转换为 ** Driver ** 序列」**的专用方法,核心服务于 UI 绑定场景;

  2. 转换后自动获得 3 个安全特性:主线程执行、不发送错误、共享订阅,减少手动冗余代码;

  3. 用法区分:序列可能出错用 asDriver(onErrorJustReturn:),不可能出错用 asDriver(),UI 绑定优先用 drive()

主线程Runloop

Runloop循环的代码,不是在主线程上运行的吗 Runloop循环的代码,不是在主线程上运行的吗 Runloop循环的代码,不是在主线程上运行的吗

聊聊swift闭包

Swift闭包语法详解 代码示例 详细解释 这是一个Swift中的闭包(Closure)语法,具体解释如下: 代码分解 语法分析 变量声明: var b:声明一个变量 b :() -> Void:指定

3-27.【函数式编程】讨论 Combine 的 Publisher 如何体现 Functor / Monad 特性。

1️⃣ Functor 特性在 Publisher 中的体现

Functor 核心:能够把函数映射到容器/上下文中的值,同时保持结构不变。

在 Combine 中:

  • Publisher 可以看作一个 容器,异步发出值
  • 使用 map 可以对 Publisher 发出的每个元素进行函数映射
  • 不改变 Publisher 的结构,只改变输出值

示例

import Combine
import Foundation

let publisher = [1, 2, 3].publisher // ArrayPublisher<Int>

let mapped = publisher.map { $0 * 2 }

let cancellable = mapped.sink { value in
    print("Mapped value:", value)
}
// 输出:Mapped value: 2
//       Mapped value: 4
//       Mapped value: 6
  • map 只改变 输出值,不改变 Publisher 的类型
  • 多次 map 可组合,满足 Functor 规律:
let f: (Int) -> Int = { $0 + 1 }
let g: (Int) -> Int = { $0 * 10 }

let left = publisher.map(f).map(g)
let right = publisher.map { g(f($0)) }
  • left == right ✅ 组合律满足

2️⃣ Monad 特性在 Publisher 中的体现

Monad 核心:支持 bind(flatMap)操作,能够把返回容器的函数平铺,避免嵌套容器。

在 Combine 中:

  • flatMap 对应 Monad 的 bind
  • 输入:(Output) -> Publisher<NewOutput, Failure>
  • 输出:单一 Publisher,把可能产生的多个嵌套 Publisher 平铺
  • 支持链式组合多个异步操作

示例

假设我们有两个异步 Publisher 函数:

func fetchNumber(_ id: Int) -> AnyPublisher<Int, Never> {
    Just(id * 2).eraseToAnyPublisher()
}

func fetchString(_ number: Int) -> AnyPublisher<String, Never> {
    Just("Number is (number)").eraseToAnyPublisher()
}

// 使用 flatMap 链式组合
let cancellable2 = [1, 2, 3].publisher
    .flatMap { fetchNumber($0) }   // Monad bind,平铺 Publisher
    .flatMap { fetchString($0) }
    .sink { print($0) }

解释

  1. [1,2,3].publisher → Publisher

  2. .flatMap(fetchNumber) → Publisher

    • 每个值会生成一个新的 Publisher
    • flatMap 平铺输出,而不是产生嵌套 Publisher<Publisher>
  3. .flatMap(fetchString) → Publisher

  4. 最终输出一个 扁平 Publisher,可以订阅


3️⃣ Functor vs Monad 对比在 Combine 中

特性 Functor (map) Monad (flatMap)
操作类型 (Output) -> NewOutput (Output) -> Publisher<NewOutput, Failure>
结构变化 不改变 Publisher 层级 平铺嵌套 Publisher
适用场景 对值做同步转换 异步链式调用,生成新的 Publisher
示例 .map { $0 * 2 } .flatMap { fetchNumber($0) }

4️⃣ 总结

  1. Functor

    • Publisher.map → 映射输出值,保持 Publisher 结构
    • 遵循恒等和组合律
  2. Monad

    • Publisher.flatMap → 绑定新的 Publisher,平铺嵌套,短路失败可处理
    • 支持函数式异步流水线,链式组合

💡 核心思想

Combine 的 Publisher 就是一个 异步容器,Functor 和 Monad 的特性保证了:

  1. 可以安全映射数据 (map)
  2. 可以安全组合异步操作 (flatMap)
  3. 异步值处理保持函数式风格,副作用集中在 sinkassign

2-5.【Concurrency】Task 和 DetachedTask 有什么区别?使用场景各是什么?

一句话总览

Task {} = 有父任务、会继承上下文的结构化并发
Task.detached {} = 没有父任务、完全独立的非结构化并发


1️⃣ 最重要的区别(先看这个)

维度 Task {} Task.detached {}
是否有父 Task ✅ 有 ❌ 没有
继承取消状态
继承优先级
继承 Task-local
继承 actor / executor
结构化并发
推荐使用 ⭐⭐⭐⭐⭐ ⭐⭐(谨慎)

99% 的情况下,你应该用 Task {}


2️⃣ Task {} 到底是什么?

定义

Task {
    await doSomething()
}

这是一个 child task(子任务)

它会继承什么?

假设你在这里:

@MainActor
func onTap() {
    Task {
        await loadData()
    }
}

这个 Task 会继承:

  • 当前 Task 的取消状态
  • 当前 优先级
  • 当前 Task-local 值
  • 当前 actor(MainActor)

所以:

loadData() // 默认仍在 MainActor

除非你 await 到别的 executor。


为什么这很重要?

因为它保证了:

  • 生命周期清晰
  • 取消可以向下传播
  • 行为可预测

👉 这就是“结构化并发”


3️⃣ Task.detached {} 是什么?

定义

Task.detached {
    await doSomething()
}

这是一个 完全独立的任务

特点(非常关键):

  • ❌ 不属于当前 Task
  • ❌ 不继承 MainActor
  • ❌ 不继承优先级
  • ❌ 不继承取消
  • ❌ 不继承 Task-local

相当于:

“在并发世界里新开了一个孤儿线程(逻辑上)”


4️⃣ 一个最容易踩坑的例子 ⚠️

@MainActor
func onTap() {
    Task.detached {
        updateUI() // ❌ 运行期错误
    }
}

原因:

  • detached task 不在 MainActor
  • 却访问了 MainActor 隔离的状态

必须显式切回:

Task.detached {
    await MainActor.run {
        updateUI()
    }
}

5️⃣ 取消(cancellation)语义差异

Task {}

let task = Task {
    try await longWork()
}

task.cancel()
  • 子任务会被标记为 cancelled
  • await 点会抛 CancellationError
  • 和父任务强关联

Task.detached {}

let task = Task.detached {
    try await longWork()
}
  • 不会被父任务取消
  • 必须手动管理生命周期
  • 很容易“偷偷活很久”

6️⃣ 什么时候该用 Task {}?(几乎所有时候)

✅ UI 事件响应

Button("Load") {
    Task {
        await viewModel.load()
    }
}

✅ actor 内部并发工作

actor Cache {
    func refresh() {
        Task {
            await self.loadFromDisk()
        }
    }
}

✅ 需要自动取消、优先级继承


7️⃣ 什么时候才该用 Task.detached {}

⚠️ 使用条件(缺一不可)

真的需要:

  1. 不继承任何上下文
  2. 生命周期独立于调用者
  3. 手动处理取消 / actor hop

合理场景 1️⃣:全局后台维护任务

Task.detached(priority: .background) {
    await cleanTempFiles()
}
  • 不该被 UI 取消
  • 明确是系统级任务

合理场景 2️⃣:跨 actor / 跨 subsystem 的桥接

Task.detached {
    let data = await fetch()
    await logger.log(data)
}

合理场景 3️⃣:底层库内部(而不是 App 代码)

Swift 官方建议:

Task.detached 主要用于框架 / runtime 层


8️⃣ 官方态度(很明确)

Swift Concurrency 的设计哲学是:

默认结构化并发,尽量消灭 detached task

你可以理解成:

  • Task {} = safe default
  • Task.detached {} = unsafe escape hatch

9️⃣ 快速记忆口诀 🧠

要继承上下文,用 Task
要彻底断亲,用 Task.detached
不确定?别 detached


10️⃣ 最后一段总结(面试版)

Task {} 创建的是结构化的子任务,会继承当前任务的取消、优先级、actor 和 task-local,适合绝大多数并发场景;
Task.detached {} 创建的是非结构化任务,不继承任何上下文,生命周期完全独立,适合极少数系统级或框架级后台工作,普通业务代码应尽量避免。

2-4.【Concurrency】Continuation 是什么?与 async/await 有何关系?

在 Swift(乃至整个并发世界)里:

如果你真正理解了 continuation,你就理解了 async/await 的底层本质。

我会按 概念 → Swift 里的具体形态 → 与 async/await 的关系 → 常见误区 来讲。


一句话定义(先刻在脑子里)

Continuation =「从当前点开始,程序接下来该怎么继续执行」的一个可保存、可传递、可稍后调用的对象。

换句话说:

continuation 就是 “未来的自己”


1️⃣ 直观理解(不用术语)

看这段代码:

let x = await foo()
print(x)

await foo() 这一行:

  • 当前函数不能继续往下跑
  • 但“等 foo 完成之后该干什么”是完全确定的

这段“之后该干什么”的逻辑:

print(x)

👉 这就是一个 continuation


2️⃣ continuation 在 Swift 中到底是什么?

在 Swift Concurrency 里,continuation 不是抽象概念,而是真实存在的东西

在编译器 / runtime 层面

continuation 由以下几部分组成:

  1. resume function

    • 一个函数指针
    • 指向“await 之后的代码块”
  2. async context

    • 保存局部变量、状态机状态
  3. executor 信息

    • 决定在哪里恢复执行

合在一起:

continuation = (async context + resume entry + executor)


3️⃣ async/await 和 continuation 的关系(核心)

❓ async/await 做了什么?

async/await 的本质就是:
把 continuation 自动、隐式地帮你创建和管理了。


不用 async/await(手写 continuation)

func foo(_ cont: @escaping (Int) -> Void) {
    bar { result in
        cont(result + 1)
    }
}

你在手动传递 continuation


用 async/await

func foo() async -> Int {
    let x = await bar()
    return x + 1
}

编译器在背后自动做了:

  • 创建 continuation
  • 保存当前上下文
  • 把 continuation 传给 bar
  • 在合适的 executor 上 resume

👉 你写的是顺序代码,底层仍然是 continuation。


4️⃣ withUnsafeContinuation 是什么角色?

这是 Swift 暴露给用户的 continuation API

func legacy() async -> Int {
    await withCheckedContinuation { cont in
        legacyAPI { value in
            cont.resume(returning: value)
        }
    }
}

这里:

  • cont 就是当前 async 函数的 continuation

  • 调用 resume

    • 就等于“触发 await 后面的代码继续执行”

⚠️ 注意:

  • resume 只能调用一次
  • 否则 continuation 会崩(checked 版会直接 trap)

5️⃣ continuation 与“状态机”的关系

continuation ≠ 状态机
continuation = 状态机的一个“入口点”

  • 状态机:

    • 决定你现在在哪个状态
  • continuation:

    • 是“从这个状态继续跑”的 callable handle

你可以把它理解为:

state machine + continuation = coroutine

6️⃣ continuation 与线程的关系(常见误解)

❌ 错误理解

continuation = 保存当前线程

✅ 正确理解

continuation 不保存线程,只保存“逻辑上的下一步”。

  • 恢复时:

    • 可能在同一个线程
    • 也可能在完全不同的线程
  • 线程由 executor 决定


7️⃣ continuation 在错误、取消中的作用

错误传播

await foo() // throws
  • continuation 包含:

    • normal resume
    • error resume

cancellation

  • task 被取消时

  • runtime 会:

    • 找到 continuation
    • 恢复执行
    • 抛出 CancellationError

8️⃣ 和其他语言的对比(帮助定位)

语言 continuation 表现
Swift 隐式 + 显式(withContinuation)
Kotlin Continuation<T> 参数
JS Promise.then
C++20 coroutine_handle
Scheme call/cc

Swift 的设计目标是:

让 99% 的 continuation 消失在语法糖后面


9️⃣ 终极记忆版总结

Continuation 是“await 之后要做什么”的可执行表示。
async/await 的全部魔法,就是把 continuation 自动保存、传递、恢复。


1-24.【GCD】QoS 和线程优先级是 1:1 映射的吗?

QoS 和线程优先级并不是 1:1 映射,它们只是相关,但机制上存在差别。下面详细解释:


1️⃣ 核心结论

QoS 是 GCD 的任务级别优先策略,用于指导系统调度任务和线程资源;线程优先级(pthread / sched)是操作系统层面线程调度权重。二者关联,但并非严格一一对应。

换句话说:

  • QoS → 告诉系统“任务重要性”,GCD 根据这个在全局线程池中选择或创建线程
  • 线程优先级 → 控制 CPU 时间分配
  • 高 QoS 通常对应较高线程优先级,但不是绝对,也会受到系统调度和能耗优化影响

2️⃣ 关联机制

2.1 任务到线程的映射

当你提交一个任务到队列:

  1. GCD 查看任务 QoS

  2. 选择或创建合适线程

    • 高 QoS → 尝试在高优先级线程或更多线程上执行
    • 低 QoS → 使用低优先级线程池或延迟执行
  3. 线程可能共享

    • 同一线程可以执行不同 QoS 任务
    • 系统会动态调整线程优先级以匹配任务 QoS

⚠️ 所以一个线程上可能交替执行不同 QoS 的任务,线程优先级会动态调整,并非固定 1:1


2.2 系统动态调节

  • macOS/iOS 内核会综合考虑:

    • 当前 CPU 利用率
    • 能耗和电量策略
    • 多任务调度公平性
  • 因此:

    • 高 QoS 任务不一定始终在最高优先级线程上执行
    • 低 QoS 任务可能在空闲线程上抢占 CPU

3️⃣ 与 pthread 优先级的区别

特性 QoS (GCD) 线程优先级 (pthread / sched)
粒度 任务级别 线程级别
作用 指导系统调度任务和线程分配 决定线程在 CPU 上调度权重
线程绑定 任务可能在任何线程上执行 固定线程调度权重
动态性 GCD 可动态提升/继承 QoS 通常固定,除非手动修改
对能耗影响 高 QoS → 可能更激进分配 CPU 无直接能耗优化机制

4️⃣ QoS 优先级与线程优先级关系

GCD 文档说明:

  • .userInteractive / .userInitiated → 高 QoS → 系统会尽量在高优先级线程或更多线程执行
  • .utility / .background → 低 QoS → 系统可能延迟执行或降低线程 CPU 优先级
  • 线程优先级只是 一个调度参考,实际调度会动态调整

✅ 核心:高 QoS 更可能获得高线程优先级,但不是一条任务对应一条线程的固定关系


5️⃣ 总结一句话

QoS 影响 GCD 如何选择线程和调度任务,但不是 1:1 映射到线程优先级;线程优先级只是系统层面的调度权重,GCD 会动态调整线程以匹配任务 QoS。


1-22.【GCD】使用 DispatchSource 时最容易踩的坑有哪些?

1️⃣ 忘记 resume()

let source = DispatchSource.makeTimerSource(queue: DispatchQueue.global())
source.schedule(deadline: .now(), repeating: 1.0)
source.setEventHandler { print("Timer fired") }
// source.resume() // ⚠️ 忘记 resume
  • :创建 DispatchSource 后必须调用 resume() 才会启动事件源
  • 原因:DispatchSource 默认是暂停状态
  • 后果:事件永远不会触发
  • 解决:调用 resume();如果需要暂停/恢复,结合 suspend() 使用

2️⃣ DispatchSource 被释放

DispatchSource.makeTimerSource(queue: .global()).schedule(deadline: .now(), repeating: 1.0).setEventHandler {
    print("Fired")
}
  • :DispatchSource 没有被强引用 → 立即释放
  • 原因:DispatchSource 是对象,如果没有外部引用,系统会释放它
  • 后果:事件永远不会触发
  • 解决:保留一个强引用,例如类属性
class MyClass {
    var timer: DispatchSourceTimer?
    
    func start() {
        timer = DispatchSource.makeTimerSource(queue: .global())
        timer?.schedule(deadline: .now(), repeating: 1.0)
        timer?.setEventHandler { print("Fired") }
        timer?.resume()
    }
}

3️⃣ 线程安全误区

  • :认为事件处理 block 内访问的资源线程安全

  • 原因:DispatchSource 的回调在指定队列上执行,并发队列上可能同时执行多个事件 block

  • 后果:共享资源竞争、数据不一致

  • 解决

    • 串行队列保证顺序和互斥
    • 并发队列访问共享资源时加锁或 barrier

4️⃣ 重复 resume 导致 crash

source.resume()
source.resume() // ⚠️ 再次 resume 会 crash
  • :DispatchSource 只能 resume 一次

  • 原因:resume 用来启动事件源,重复调用会触发异常

  • 解决

    • 使用标志位判断是否已 resume
    • 或通过类属性封装管理状态

5️⃣ 使用 sync 触发死锁

let queue = DispatchQueue(label: "serial")
let source = DispatchSource.makeTimerSource(queue: queue)
source.setEventHandler {
    queue.sync { print("Deadlock") } // ⚠️ 死锁
}
source.resume()
  • :事件 block 内调用 sync 队列同队列 → 死锁
  • 原因:串行队列同步调用自己会等待 → 永远无法完成
  • 解决:使用 async 调度,或者将事件 block 放到不同队列

6️⃣ 忘记 cancel

  • :DispatchSource 用完不取消
  • 原因:DispatchSource 会保持队列引用,未 cancel 可能导致内存泄漏
  • 解决
source.cancel()
source.setEventHandler(nil) // 释放闭包引用

7️⃣ 对定时器误用 resume/suspend

  • :误认为 suspend/resume 可以无限暂停定时器

  • 注意

    • DispatchSourceTimer 初始为暂停状态 → 必须 resume 启动
    • suspend/resume 必须成对使用,否则下一次 resume 会 crash

8️⃣ 队列选择不当

  • :将 DispatchSource 绑定到主队列或串行队列,但事件量大

  • 后果

    • 阻塞主线程 → UI 卡顿
    • 串行队列上高频事件 → 队列积压
  • 解决

    • 高频事件使用后台并发队列
    • 根据场景合理选择队列类型

✅ 总结常见坑及解决策略

解决方案
忘记 resume 必须调用 resume() 启动事件源
DispatchSource 被释放 保持强引用(类属性)
线程安全误区 并发队列访问共享资源加锁,或使用串行队列
重复 resume 导致 crash 只 resume 一次,使用标志位
sync 导致死锁 避免在事件 block 内对同队列 sync,使用 async
忘记 cancel 使用完毕后 cancel,并释放事件处理器闭包
suspend/resume 不成对 严格成对调用,确保队列状态正确
队列选择不当 高频事件用后台并发队列,UI 事件用主队列

💡 核心经验

  1. DispatchSource 本质是 事件源 + GCD block → 避免直接对线程或队列做 unsafe 操作
  2. 所有事件处理 block 都遵循绑定队列调度 → 理解串行/并发对共享资源的影响
  3. 强引用 + resume + cancel 是生命周期管理三部曲

1-13.【GCD】dispatch_barrier 的作用和使用场景是什么?

1️⃣ 基本作用

dispatch_barrier 用于在并发队列中创建一个“屏障”,保证屏障前的任务全部完成后才执行屏障任务,屏障任务完成后才允许屏障后的任务继续执行。

  • 本质:把并发队列临时变成“串行屏障”
  • 保证 读-写或写-写安全,同时不阻塞其他并行队列的线程资源

2️⃣ 工作机制

假设有一个并发队列 concurrentQueue

let concurrentQueue = DispatchQueue(label: "concurrent", attributes: .concurrent)

concurrentQueue.async { print("A") }
concurrentQueue.async { print("B") }
concurrentQueue.async(flags: .barrier) { print("Barrier") }
concurrentQueue.async { print("C") }
concurrentQueue.async { print("D") }

执行顺序:

  1. A、B 可以同时执行(并发)
  2. BarrierA、B 完全完成 后执行
  3. C、D 等 Barrier 完成后再执行

⚠️ 注意:

  • barrier 任务前后不会并发执行
  • barrier 前的任务可以并发
  • barrier 后的任务也可以并发(但 Barrier 本身是独占的)

3️⃣ 使用场景

3.1 并发队列上的读写安全

典型场景:多读少写的数据结构

var sharedArray = [Int]()
let queue = DispatchQueue(label: "concurrentQueue", attributes: .concurrent)

// 多个并发读
queue.async {
    print(sharedArray.count)
}
queue.async {
    print(sharedArray.last ?? 0)
}

// 写操作使用 barrier
queue.async(flags: .barrier) {
    sharedArray.append(42)
}

解释:

  • 多个读可以并发执行 → 高性能
  • 写操作必须等前面读完成,并且执行时阻止其他读写 → 数据安全

Barrier 是 并发队列上的写锁机制


3.2 替代传统锁(NSLock / DispatchSemaphore)

  • 可以用 barrier 替代全局锁对共享资源加锁

  • 优势:

    • 保持 读操作并发性
    • 写操作串行化,不阻塞其他队列的线程池
  • 适合 读多写少场景


3.3 串行队列上的 barrier 无效

let serialQueue = DispatchQueue(label: "serial")
serialQueue.async(flags: .barrier) { ... }
  • barrier 在串行队列上 没有任何特殊作用

  • 原因:

    • 串行队列天然保证同一时间只执行一个任务
    • barrier 只是多余标记

4️⃣ 使用注意事项

  1. 只能在自定义并发队列上使用

    • global queue 不允许 barrier
  2. 不要在主队列上使用 barrier

    • 主队列是串行的,没意义
  3. 同步 barrier(sync + barrier)可能死锁

    • 原因和普通 sync 一样,当前线程可能阻塞自己

5️⃣ 总结

作用:

  • 在并发队列中创建一个排它屏障
  • 屏障前的任务先执行,屏障独占执行,屏障后的任务再继续并发执行

典型场景:

  • 并发读 + 写操作的共享数据
  • 读多写少,避免使用锁仍保证线程安全
  • 替代 NSLock / semaphore 进行高性能读写控制

💡 一句话总结

dispatch_barrier 就是给并发队列加了一道“独占关卡”,保证关键写操作在队列中独占执行,而不影响前后的并发读任务。

1-6.【GCD】自定义队列在底层是如何映射到全局队列的?

自定义队列本身不拥有线程;它们通过 target queue 机制,最终把任务“汇流”到某个全局并发队列(按 QoS)上执行。

下面我们从 结构 → 映射路径 → 调度细节 → 常见误解 一层层拆。


1️⃣ 核心模型:Queue ≠ Thread(再强调一次)

在 GCD 里:

  • 队列(DispatchQueue)
    👉 任务的组织和调度规则
  • 线程(worker thread)
    👉 真正执行任务的资源

👉 自定义队列永远不直接绑定线程


2️⃣ 自定义队列创建时发生了什么?

let queue = DispatchQueue(
    label: "com.example.myqueue",
    qos: .utility,
    attributes: [.concurrent]
)

你得到的是一个:

  • 有自己 FIFO / 并发规则的 逻辑队列
  • 没有线程
  • 没有独立线程池

3️⃣ 真正关键的机制:target queue

每一个 dispatch queue 都有一个 target queue

你可以显式指定:

queue.setTarget(queue: DispatchQueue.global(qos: .utility))

但即使你不写:

系统也会自动帮你设

默认 target 规则是:

队列类型 默认 target
main queue main thread / RunLoop
global queue root queue(系统内部)
自定义 queue 对应 QoS 的 global queue

4️⃣ 调度路径(重点流程)

当你执行:

queue.async {
    work()
}

真实发生的是:

你的自定义 queue
   ↓(保持自己的串行 / 并发语义)
target queue(global queue, by QoS)
   ↓
GCD 调度器
   ↓
共享线程池(worker threads)
   ↓
执行 block

👉 自定义队列只负责:

  • 任务顺序
  • barrier
  • 串行 / 并发约束

👉 全局队列负责:

  • 线程选择
  • QoS 调度
  • CPU 分配

5️⃣ 串行队列是如何“跑在并发队列上”的?

这点很容易让人迷糊。

let serial = DispatchQueue(label: "serial")

虽然:

  • serial queue 自己是 串行的
  • 但它的 target 是 并发的 global queue

为什么还能串行?

原因是:

串行语义是在“队列层”保证的,不是在“线程层”

GCD 保证:

  • 同一时间
  • serial queue 只会向 target queue 提交 一个 block

即使 target 是并发的:

  • 永远只会有一个来自该 serial queue 的任务在执行

6️⃣ 并发自定义队列又是如何工作的?

let concurrent = DispatchQueue(
    label: "concurrent",
    attributes: .concurrent
)

特点:

  • 并发规则由 这个队列自己管理
  • 多个 block 可以同时被提交给 target queue
  • target queue(global)负责并行执行

7️⃣ barrier 为什么只能用于自定义并发队列?

queue.async(flags: .barrier) {
    criticalSection()
}

原因很直白:

  • barrier 是 队列内部的语义

  • global queue 是:

    • 共享的
    • 多来源的
  • GCD 无法也不允许:

    • 为“全局公共队列”插入独占屏障

👉 所以:

barrier 只能作用在你“拥有”的那一层队列


8️⃣ QoS 是如何一路传下去的?

  • 自定义队列有自己的 QoS

  • 提交的 block 继承:

    • queue QoS
    • 或 caller QoS(取更高)
  • 最终:

    • 映射到 target global queue
    • 再映射到线程优先级

👉 QoS 是任务属性,不是队列绑定线程。


9️⃣ 一个容易忽略但很重要的点

setTarget(queue:) 可以改变的不只是 QoS

你可以:

queue.setTarget(queue: someSerialQueue)

结果是:

  • 多个队列“汇流”到一个串行队列

  • 从而实现:

    • 资源限流
    • 顺序控制
    • 自定义调度树

这就是 GCD 的“队列树(queue hierarchy)”设计


🔚 一句话终极总结

自定义队列通过 target queue 机制映射到对应 QoS 的全局并发队列执行;它们只定义任务的组织与同步语义,而线程管理与调度完全由全局队列和系统线程池负责。

❌