是否有任何理由共享调度队列？答案

【问题标题】：Is there any reason to share a dispatch queue?是否有任何理由共享调度队列？
【发布时间】：2013-09-06 19:47:50
【问题描述】：

我正在处理一些无法联系到原始开发人员的代码。

他将一个类的引用传递给另一个类的串行调度队列，我看不出他有什么目的，而不仅仅是创建另一个调度队列（每个类都是一个单例）。

这不会造成问题，但我想进一步了解它，因此感谢您对积极影响的任何见解，谢谢。

编辑：我建议在这里阅读所有答案，它们解释了很多。

【问题讨论】：

【解决方案1】：

以这种方式共享队列实际上不是一个好主意（不，不是因为它们很昂贵 - 它们不是，恰恰相反）。基本原理是除了队列的创建者之外，任何人都不清楚队列的语义是什么。是串行的吗？同时？高优先级？低优先级？一切皆有可能，一旦您开始传递实际上是为特定类的利益而创建的内部队列，外部调用者可以安排在其上的工作，这会导致相互死锁或以其他方式与其他项目以意想不到的方式表现队列，因为调用者 A 知道会发生并发行为，而调用者 B 认为这是一个串行队列，没有任何并发执行所暗示的“陷阱”。

因此，队列应该尽可能隐藏类的实现细节。该类可以根据需要导出针对其内部队列调度工作的方法，但这些方法应该是唯一的访问器，因为它们是唯一知道如何最好地访问和调度特定类型队列的工作的方法！

【讨论】：

哇，非常感谢您写得很好。这里有很多有用的答案，但为了推广最佳实践，我将您的答案标记为正确。

【解决方案2】：

如果它是一个串行队列，那么他们可能打算序列化对共享它的所有对象之间共享的某些资源的访问。

【讨论】：

谢谢，是的，它是一个串行队列（我已经编辑了问题以反映这一点）
这是我在旅行中看到的共享串行队列的最常见原因。
如果不是串行队列呢？恕我直言，如果需要公开队列，则应由调用站点完成以执行完成处理程序或进度处理程序。关联的异步任务的工作负载应该在它们自己的私有队列上执行。 IMO，OP 描述是一种潜在的代码异味。
我想一个共享的并发队列可以用于它的暂停语义，但这很不寻常。我同意这可能不是最好的方法。

【解决方案3】：

创建调度队列的成本有点高，而且会占用系统资源。如果您可以共享一个，则系统运行效率更高。就此而言，如果您的应用程序确实在后台运行，则使用共享队列可以让您管理要完成的单个任务池。所以是的，使用共享调度队列是有充分理由的。

【讨论】：

我对 GCD 的了解参差不齐（我正在尽可能快地阅读以纠正），但为什么一个队列比两个队列运行得更好？
我不同意队列“昂贵”的创建和“占用 [有意义的] 系统资源”。调度队列和内核互斥锁或类似的东西之间没有 1:1 的关系。根据经验，我观察到分配 dispatch_queue_t 会占用 128 字节的堆，而您可以在几秒钟内分配 1000 万个。