无状态 Actor：是多余还是必要？

背景

在并发编程中，Actor 模型（如 Swift 中的 actor）通常被视为保护可变状态（mutable state）的安全屏障。其核心设计理念是通过隔离（isolation）机制，防止数据竞争。因此，当被问及“如果一个 Actor 没有任何状态，它是否毫无意义？”时，直觉反应往往是肯定的——既然没有需要隔离的数据，构建这样一个“保护气泡”似乎显得多余且怪异。

然而，这种直觉可能忽略了 Actor 在并发控制、线程调度以及系统架构集成方面的其他重要价值。本文深入探讨了无状态 Actor 在多种场景下的实际应用、潜在优势以及与之相关的权衡取舍，旨在澄清对 Actor 模型的常见误解。

核心内容

1. 无状态 Actor 的实用场景：以 NetworkClient 为例

在实际开发中，我们经常遇到类似 NetworkClient 这样的类型，它们封装了网络 API 调用，但自身并不持有需要保护的可变状态。

使用 Actor 的优势：

• 线程安全性与 Sendable：Actor 类型默认是 Sendable 的。这意味着我们可以轻松地在不同线程或并发任务之间传递该类型的实例，而无需担心线程安全问题。
• 非主线程执行：Actor 的同步方法默认在共享线程池上执行，而非主线程。对于耗时的操作（如 JSON 解码），这能确保主线程不会被阻塞。
• 预留状态空间：虽然当前无状态，但未来可能需要引入缓存或认证机制。预先使用 Actor 可以为未来的状态管理提供现成的隔离环境。

权衡与代价：

• 协议兼容性差：Actor 类型在与 Swift 协议（Protocols）结合使用时往往面临困难，因为协议通常无法直接约束 Actor 的隔离特性。
• 数据传递限制：Actor 的方法输入和输出必须是 Sendable 的，这迫使开发者更多地使用不可变或线程安全的数据结构。
• 串行执行限制：Actor 内部的同步代码是串行执行的。即使有多个并发任务请求，JSON 解码等操作也只能排队逐一执行，无法利用多核并行处理。

对比方案：struct + @concurrent 如果改用 struct 并标记方法为 @concurrent，可以获得以下优势：

• 更好的协议兼容性：避免了隔离不匹配的问题。
• 并行执行能力：@concurrent 允许方法在多个线程上并行运行，打破了 Actor 的串行限制，提高了吞吐量。

作者强调，这并非说 struct 一定优于 actor，而是指出两者各有优劣，开发者需根据具体需求（如是否需要状态隔离 vs. 是否需要并行性能）进行权衡。

2. 全局 Actor（Global Actor）的陷阱：以 BackgroundActor 为例

Swift 允许定义自定义的全局 Actor（如 @globalActor actor BackgroundActor），以便在代码中统一标记后台任务。虽然这提供了熟悉感（类似于 @MainActor），但存在两个严重缺陷：

• 串行执行瓶颈：与上述 NetworkClient 类似，基于 Actor 的全局 Actor 会强制其下的代码串行执行。这意味着所有标记为 @BackgroundActor 的任务将排队处理，无法并行，这对于后台密集型任务来说是不理想的。
• 类型系统的“病毒式”传播：全局 Actor 与类型系统紧密集成。一旦添加，编译器会强制保证工作在该 Actor 上执行。这可能导致隔离特性的“病毒式”扩散，使得后续移除或修改变得极其痛苦。

作者建议，与其依赖自定义全局 Actor，不如深入理解语言现有的并发控制构造（如 Task、Executor 等），这通常是更稳健的投资。

3. 自定义执行器 Actor（Custom Executor Actors）

这是无状态 Actor 最核心的价值所在之一。这类 Actor 本身不持有业务状态，而是作为适配器，将 Swift 的并发系统与现有的基于队列的系统（如 GCD、AVFoundation）集成。

示例：LandingSite

actor LandingSite {
    private let queue = DispatchSerialQueue(label: "com.example.landing")
    
    nonisolated var unownedExecutor: UnownedSerialExecutor {
        queue.asUnownedSerialExecutor()
    }
}

通过实现 UnownedSerialExecutor，Actor 可以将并发任务委托给底层的 GCD 队列。这种模式的优势在于：

• 集成现有系统：可以无缝对接 AVFoundation 或其他基于队列的框架。
• 灵活性：适用于任何基于队列的系统，而不仅限于 Swift 原生的并发模型。

MainActor 的特殊性 MainActor 本身也是一个无状态 Actor（没有直接属性），但它管理着整个 UI 的状态。因此，它处于“无状态”与“有状态”的边界，但其作为执行器管理 UI 线程调度的角色，证明了无状态 Actor 在系统级调度中的重要性。

4. 文件系统与外部状态

文件系统是一种存在于程序之外、对编译器不可见的“状态”。当多个并发部分访问磁盘上的缓存或文件时，可能导致数据损坏。

无状态 Actor 的作用：

• 序列化访问：Actor 提供的序列化机制可以确保对文件系统的访问是串行的，从而防止并发写入导致的损坏。
• 手动封装：虽然编译器无法检查文件系统操作的线程安全，但通过 Actor 封装，开发者可以手动确保操作的安全性。

阻塞操作的考量：

• 线程占用：磁盘读写是同步阻塞操作，会占用并发运行时（Concurrency Runtime）的线程。由于并发线程数量是有限的（通常与 CPU 核心数相关），大量阻塞操作可能导致线程耗尽。
• 与 GCD 的区别：GCD 会根据需要创建大量线程（尽管也是有限的），而 Swift 并发运行时更倾向于复用少量线程。
• 建议：通常情况下，只要操作能向前推进，阻塞问题并不严重。但如果担心性能瓶颈，应将阻塞操作移出并发线程池，使用 GCD 等机制处理。

关键要点

• 无状态并非无用：Actor 的价值不仅在于保护内部状态，还在于提供线程安全的 Sendable 类型、控制执行线程（如非主线程）以及集成外部系统。
• 串行 vs. 并行：Actor 内部的同步代码是串行的。如果需要高并行的计算密集型任务（如 JSON 解码），struct + @concurrent 可能比 Actor 更高效。
• 避免滥用全局 Actor：自定义全局 Actor 会导致串行执行瓶颈和类型系统的过度耦合，建议优先使用语言现有的并发原语。
• 执行器适配器的价值：无状态 Actor 是连接 Swift 并发系统与现有基于队列系统（如 GCD、AVFoundation）的理想桥梁。
• 外部状态的序列化：对于编译器无法感知的外部状态（如文件系统），Actor 可以提供必要的序列化访问保护，但需注意阻塞操作对线程池的影响。
• 首要原则：使用 Actor 前，必须能清晰阐述其必要性。虽然无状态 Actor 看似奇怪，但在特定架构场景下，它们是合理且必要的工具。

意义与影响

这篇文章对 Swift 并发编程实践具有重要的指导意义。它打破了“Actor 仅用于保护可变状态”的刻板印象，揭示了无状态 Actor 在系统架构、线程调度和外部资源集成中的独特价值。

1. 架构设计的灵活性：开发者可以更灵活地选择 struct、actor 或自定义执行器，而不是盲目地将所有并发类型都定义为 Actor。
2. 性能优化的新视角：通过理解 Actor 的串行特性与 @concurrent 的并行特性，开发者可以在网络请求、数据处理等场景中做出更优的性能选择。
3. 系统集成的最佳实践：对于需要与 Objective-C 遗留代码、GCD 或媒体框架集成的项目，无状态 Actor 作为执行器适配器提供了一种类型安全且易于管理的方案。
4. 警惕过度工程：文章提醒开发者不要为了使用 Actor 而使用 Actor，强调了理解并发原语底层机制的重要性，避免引入不必要的复杂性或性能瓶颈。

总之，无状态