在GCD（中央调度）中创建dispatch_queues多少算太多？

Mike Ash 有一篇关于用 Swift 构建的轻量级通知系统的精彩文章：（https://www.mikeash.com/pyblog/friday-qa-2015-01-23-lets-build-swift-notifications.html https://www.mikeash.com/pyblog/friday-qa-2015-01-23-lets-build-swift-notifications.html).

基本思想是创建可以“监听”的对象，即在发生某些状态更改时调用回调。为了使其线程安全，创建的每个对象都拥有自己的dispatch_queue。 dispatch_queue 只是用来控制临界区：

dispatch_sync(self.myQueue) {
    // modify critical state in self
}

而且它可能不会引起激烈的争论。我有点震惊的是every您创建的可监听的单个对象会创建自己的调度队列，只是为了锁定几行代码。

一张海报建议 OS_SPINLOCK 会更快、更便宜；也许吧，但它肯定会使用更少的空间。

如果我的程序创建了数百或数千（甚至数万个对象），我是否应该担心创建这么多调度队列？也许大多数人都不会被倾听，但有些人可能会。

两个对象不会互相阻塞，即具有单独的锁，这当然是有道理的，通常我不会三思而后行，比如在每个对象中嵌入一个 pthread_mutex ，而是嵌入整个调度队列？真的可以吗？

好吧，Grand Central Dispatch 的文档 https://developer.apple.com/library/ios/documentation/Performance/Reference/GCD_libdispatch_Ref/index.html#//apple_ref/doc/uid/TP40008079关于调度队列的内部工作原理和确切成本相当模糊，但它确实指出：

GCD 提供并管理 FIFO 队列，您的应用程序可以向其中以块对象的形式提交任务。提交到调度队列的块在完全由系统管理的线程池上执行。

因此，听起来队列只不过是通过线程池对块进行排队的接口，因此在空闲时对性能没有/最小的影响。

概念文档还指出： https://developer.apple.com/library/ios/documentation/General/Conceptual/ConcurrencyProgrammingGuide/OperationQueues/OperationQueues.html#//apple_ref/doc/uid/TP40008091-CH102-SW1

您可以根据需要创建任意数量的串行队列

这听起来绝对是创建串行调度队列并使其闲置的成本几乎微不足道。

此外，我决定在具有一些 Open GL 内容的应用程序上测试创建 10,000 个串行和并发调度队列，并没有发现性能受到任何影响，FPS 保持不变，并且只使用了额外的 4MB RAM（单个队列约 400 字节）。

在使用 OS_SPINLOCK 而不是调度队列方面，Apple 是very在它的文档中清楚地说明了迁移线程 https://developer.apple.com/library/ios/documentation/General/Conceptual/ConcurrencyProgrammingGuide/ThreadMigration/ThreadMigration.html#//apple_ref/doc/uid/TP40008091-CH105-SW1GCD 比使用标准锁更有效（至少在竞争情况下）。

用队列替换基于锁的代码消除了许多与锁相关的惩罚并且还简化了剩余的代码。您可以创建一个队列来序列化访问该资源的任务，而不是使用锁来保护共享资源。队列不会施加与锁相同的惩罚。例如，对任务进行排队不需要陷入内核来获取互斥体。

但值得注意的是，如果您不使用队列，则可以随时释放它，并在稍后需要再次使用时重新创建它（如果您担心内存问题）。

TL;DR

调度队列是最佳选择。您不必太担心创建大量队列而不使用它们，而且它们肯定比锁更有效。

Edit:您实际上发现自旋锁在无竞争的情况下速度更快，因此您可能会想使用它！