从锁到Actor：Swift并发编程的得与失
Swift 5.5引入的Actor模型被视为并发编程的一次范式革命，它试图用编译器级的数据隔离替代开发者手动加锁的脆弱方式。然而，过度吹捧Actor的所谓"安全"恰恰掩盖了它背后的复杂性。当我们深入剖析Actor的调度机制，会发现它本质上是一个串行执行队列加上编译期约束，其底层仍然依赖锁来保护自身状态。这种包装虽然降低了普通场景下的出错率，但在追求极致性能或处理高频读写时，Actor的全局串行化执行和不透明的调度开销往往成为新的瓶颈。传统锁虽然名声不佳，但在精细控制锁粒度、支持读写分离、实现优先级反转处理等方面，依然有着不可替代的优势。真正的工程智慧不在于盲目跟随新潮，而是理解每种工具背后的成本收益，在正确的位置做出恰当选择。
从性能视角来看，传统锁与Actor的对比远比教科书描述的更为微妙。一个简单的NSLock在临界区内的加锁解锁耗时通常在纳秒级，而Actor的每次方法调用都需要通过执行器进行异步调度，即使是无竞争的调用也会产生微秒级的开销。这意味着在循环密集计算或高频数据采集的场景下，使用Actor会让性能断崖式下跌。更关键的是，Actor要求所有方法调用都使用await，这迫使原本同步路径上的调用方被迫改成异步上下文，从而引入不必要的线程切换和上下文保存。反观精心设计的锁方案，可以做到只在写入时加锁，读取时使用原子操作或其他无锁技术，在CPU缓存友好性方面远胜于Actor的单一队列模型。因此，在实时音视频处理、高频传感器数据读取等低延迟敏感场景中，传统锁依然是更理性的选择。
然而，我们批评Actor并非出于守旧心理，而是想指出其设计哲学上的一个盲区：编译器无法替你设计并发架构。Actor封装了状态，却把并发架构的决策权交给了隐式调度器。当多个Actor相互调用时，极易产生死锁——例如Actor A等待Actor B，同时Actor B又等待Actor A，这种循环依赖在编译期无法发现，运行时也只会表现为永久性的等待。传统锁虽然没有编译器检查，但开发者能够清晰地看到锁的获取顺序，从而通过设计锁层级或使用超时参数来主动规避死锁。此外，Actor的可重入性问题也经常被低估：一个Actor方法内部调用另一个Actor方法时，如果两个方法恰好共享某个资源（比如全局缓存），可能会造成意想不到的数据竞争。这种隐藏的复杂性让所谓"数据安全"变成一纸空谈。我们必须承认，任何并发机制都不可能消除并发本身的复杂度，只能将其转移到别处。
那么，在Swift开发中我们应当如何取舍？我认为核心原则应当是：用Actor保护跨模块的长期状态，用锁保护细粒度的临界区。例如，在ViewModel或Service层中，使用Actor管理整体状态是合理的，因为它能简化逻辑并减少遗漏。但在底层工具库中，针对高频访问的计数器、缓存列表或ID生成器，直接在类内部使用自旋锁或读写锁会带来数十倍的性能提升。同时，我们还可以利用Swift 5.9引入的Nonisolated和Region-based Isolation等新特性，让Actor与锁共存，而不是彼此否定。一个全新的架构思路是：将锁封装为Actor的私有实现细节，对外只暴露Actor接口。这样既保留了Actor的编译期检查，又能在热点路径上使用更高效的同步原语。最终，我们要记住，并发编程的铁律从来不是"某个工具更好"，而是"你的临界区到底有多小，你的调用频率到底有多高"。脱离场景谈优劣，都是不负责任的空谈。
结论：Actor是Swift并发的一件利器，但并非银弹。传统锁也没有资格被扫进历史垃圾堆。作为iOS开发者，我们需要以开放心态同时精通这两种工具，用权衡思维替代宗教式膜拜。未来Swift并发体系还会继续演化，但底层原理不会改变：数据竞争源于共享可变状态，而解决它永远需要控制访问时序。锁与Actor只是两种不同的控制方式，它们的优劣取决于应用场景、数据规模与硬件条件。与其争论谁取代谁，不如多花时间学习如何在自己的项目里精确度量性能、分析调度行为。这才是一个专业开发者应有的态度。
