libdispatch（or GCD）是最容易被使用错误的API之一，这是因为它的用法以及令人难懂的文档和API。如果你打算使用这个库，下面是总结是你要知道的。本文末尾有很多参考资料，包库对苹果自己的libdispatch维护人员（Pierre Habouzit）的评论的引用。
具体的结论如下:
- 应该创建适量、常驻、明确职能的队列。这些队列供应用程序执行上下文及其它并行任务（UI线程、后台线程等）。需要注意的是，如果这些队列处于活动状态，意味着将有等量的线程数运行。在大部分的App中，只需要不超过3或者4个队列即可。
- 优先使用串行队列，如果使用过程中发现性能瓶颈，可以先查找原因。即使并行能提供帮助，也需谨慎使用，并且始终在系统压力下验证。尽可能的重用队列，除非增加队列能带来明显的收益。
- 你可以创建比较多非全局行的队列（重点是他们有不同的标识），如使用
DispatchQueue(label:target:)方式创建的队列。 - 不要使用
DispatchQueue.global()的方式获取队列。全局队列容易导致线程爆炸：libdispatch将阻塞、睡眠、等待、锁定的线程视为非活动线程，从而在需要程序调度时又会创建新的线程。注意，我们不能保证线程永远不会被阻塞，事实是，即使我们仅仅使用系统库都可能会发生这种问题。全局队列对qos和priorities的支持也不友好。苹果工程师，libdispatch的维护者宣称它是"它提供了最糟糕的dispatch API"。用自定义的队列代替它运行你的代码。 - 并发队列相对串行队列不是最佳实践。除非衡量了确切的收益，否则直接使用并发队列更像是过早优化。
- 对于派发的小于1ms的任务，使用
queue.async()的方式是非常糟糕的。基于libdispatch的过渡分配行为，它极有可能会创建一个新的线程。宁愿使用锁定来保护共享状态（而不是切换执行上下文）。 - 有些类/库设计为同步API，重用调用者的执行上下文（而不是创建私有队列，这可能导致糟糕的性能）这意味着得使用传统的锁来保证线程安全。
-
os_unfair_lock是目前系统中最快的锁（优先级更好，上下文切换更少），用于取代OSSpinLock（取代原因可参考《不再安全的 OSSpinLock》），尝试获取已加锁的线程无需忙等，解锁时由内核唤醒。和OSSpinLock一样，os_unfair_lock也没有加强公平性和顺序，它在Swift中直接使用却是不安全的(参考StackOverFlow讨论)。事实证明，pthread_mutex的底层实现已被更新为os_unfair_lock，而NSLock本身是基于pthread_mutex实现的，因此NSLock是在Swift中锁定的最佳选择。 - 在调度任务派发后，不要阻塞当前正在等待信号量的线程或者调度组。因为内核不知道哪个线程最终会解除线程阻塞，从而导致执行低效。
- 不要在非GUI程序和库中使用
DispatchQueue.main，<dispatch/queue.h>头文件中的解释如下:“ "Because the main queue doesn't behave entirely like a regular serial queue, it may have unwanted side-effects when used in processes that are not UI apps (daemons). For such processes, the main queue should be avoided"。是说主队列并和普通的串行队列不太一样，如果在非UI操作的情况下调用，会导致一些意外情况。具体是啥意外，我还暂时举不出例子。 - 如果要并行执行，工作项中最好没有资源的竞争，否则性能会急剧下降，竞争有多种形式。加锁来保证线程的安全，但也意味着被竞争的共享资源会成为性能的瓶颈: IPC/daemons, malloc (lock), shared memory, I/O等。
- 不要一直使用
async，这样可以避免线程爆炸。使用少量调度队列来代替DispatchQueue.global()是一个更好的解决办法。 - 大量异步/回调设计的复杂性（和缺陷）也不容忽视。同步代码仍然更易于阅读、编写和维护。
网友评论