Question

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

基本的想法是你创造出你可以＆＃34;倾听＆＃34;当有一些状态改变时调用回调。为了使其成为线程安全的，每个创建的对象都拥有自己的dispatch_queue。 dispatch_queue仅用于关键部分：

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

此外，它可能不会引起很大争议。令我感到震惊的是，你创建的每个单个对象都可以监听它自己的调度队列，只是为了锁定几行代码。

一张海报表示OS_SPINLOCK会更快更便宜;也许，但肯定会占用更少的空间。

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

两个对象之间没有相互阻塞，即具有单独的锁定，这当然是有意义的，通常我不会想到在每个对象中嵌入pthread_mutex，而是整个调度队列？那真的好吗？

Answer 1

which day of week given a date python对内部运作方式相当模糊。调度队列的确切成本，但它确实说明了：

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

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

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

这肯定听起来像创建串行调度队列并让它空闲时几乎是微不足道的代价。

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

在使用OS_SPINLOCK而不是调度队列方面，Apple在其关于The conceptual documentation also states that:的文档中非常清楚GCD比使用标准锁更有效（至少在竞争情况下）

使用队列替换基于锁的代码消除了许多与锁相关的惩罚，并简化了剩余的代码。您可以改为创建一个队列来序列化访问该资源的任务，而不是使用锁来保护共享资源。 队列不会像锁一样处罚。例如，排队任务不需要捕获内核来获取互斥锁。

虽然值得注意的是，如果你不使用它，你可以随时释放一个队列，并在需要再次使用时重新创建它，如果你担心内存。

TL; DR

调度队列是可行的方法。你不需要过多担心创建大量队列而不使用它们，它们肯定比锁更有效。

编辑：您实际上发现在无争用的情况下自旋锁更快，因此您可能希望将其用于此目的！