ios - GCD 对比 @synchronized 对比 NSLock

Question

谁能简要说明这 3 个系统在线程安全方面的优缺点？

通过观看最近的 WWDC 视频，我感觉到 Apple 正在插入 GCD 的使用，以创建线程安全的高性能读写器。

这背后的想法/支持是什么？是时候访问必须进入导致此 GCD 推送的内核并回避 @synchronized 和 NSLock 的锁了吗？

@synchronized 和 NSLock 是否被排除在最佳实践之外，或者它们是否还有一席之地？

Answer 1

有很多细节可以就此进行详细讨论。但是，核心是:

这些总是需要在某处或以某种方式获取锁:

@synchronized(...) { ... }
[lock lock];

由于您提到的原因，锁非常昂贵；他们必然消耗内核资源。 (现在 @synchronized() 的情况实际上可以避免内核锁，但它是一种基于散列的排除机制，它本身是昂贵的)。

这些并不总是需要锁(但有时可能需要):

dispatch_sync(...concurrent q...., ^{ ... });
dispatch_async(...queue of any kind...., ^{ ... });

通过有效无锁的调度函数有一条快速路径(尽管它们将使用测试和设置原子原语，这可能会在负载下导致性能问题)。

最终结果是，对并发队列的同步分派(dispatch)可以有效地视为“立即在该线程上执行”。对串行队列的同步调度可以执行原子测试和设置以测试队列是否正在处理，将其标记为忙碌，如果不忙，则立即在调用线程上执行 block 。

异步调度可以同样快，尽管异步调度需要复制 block (这可能非常便宜，但需要考虑一下)。

一般来说，GCD 可以做任何锁可以做的事情，至少可以——如果不是更高效的话——而且你可以使用 GCD API 来超越简单的锁定(使用信号量作为计算例如 throttle )。

顺便说一句:如果您的任务粒度相对较粗，请查看NSOperationQueue 和NSOperation。