第41条:多用派发队列，少用同步锁

　　本条要点：（作者总结）

• 派发队列可用来表述同步语义（synchronization semantic），这种做法要比使用 @synchronized 块或 NSLock 对象更简单。
• 将同步与异步派发结合起来，可以实现与普通加锁机制一样的同步行为，而这么做却不会阻塞执行异步派发的线程。
• 使用同步队列及栅栏块，可以令同步行为更加高效。

 

　　在 Objective-C 中，如果有多个线程要执行同一份代码，那么有时可能会出问题。这种情况下，通常要使用锁来实现某种同步机制。在 GCD 出现之前，有两种办法，第一种是采用内置的 “同步块”（synchronization block）:

1 　　- (void)synchronizedMethod {
2 
3 　　　　@synchronized(self) {
4 　　　　　　// Safe
5 　　　　}
6 　　}

　　这种写法会根据给定的对象，自动创建一个锁，并等待块中的代码执行完毕。执行到这段代码结尾处，锁就释放了。在本例中，同步行为所针对的对象是 self。这么写通常没错，因为它可以保证每个对象实例都能不受干扰地运行其 synchronizedMethod 方法。然而，滥用@synchronized(self) 则会降低代码效率，因为共用同一个锁的那些同步块，都必须按顺序执行。若是在 self 对象上频繁加锁，那么程序可能要等另一段与此无关的代码执行完毕，才能继续执行当前代码，这样做其实并没有必要。

　　另一个办法是直接使用 NSLock 对象：

1 　　_lock = [[NSLock alloc] init];
2 
3 　　- (void)synchronizedMethod {
4 
5 　　　　[_lock lock];
6 　　　　// Safe
7 
8 　　　　[_block unlock];
9 　　　}

　　也可以使用 NSRecursiveLock 这种 “递归锁”（recursive lock）（重入锁），线程能够多次持有该锁，而不会出现死锁（deadlock）现象。

　　这两种方法都很好，不过也有其缺陷。比方说，在极端情况下，同步块会导致死锁，另外，其效率也不见得很高，而如果直接使用锁对象的话，一旦遇到死锁，就会非常麻烦。

　　替代方案就是使用 GCD ，它能以更简单、更高效的形式为代码加锁。比方说，属性就是开发者经常需要同步的地方，这种属性需要做成 “原子的”。用 atomic 特质来修饰属性，即可实现这一点。而开发者如果想自己来编写访问方法的话，那么通常会这样写：

 1 　　- (NSString *)someString {
 2 
 3 　　　　@synchronized(self) {
 4 　　　　　　return _someString;
 5 　　　　}
 6 　　}
 7 
 8 　　- (void)setSomeString:(NSString *)someString {
 9 
10 　　　　@synchronized(self) {
11 　　　　　　_someString = someString;
12 　　　　}
13 　　}

　　刚才说过，滥用 @synchronized(self) 会很危险，因为所有同步块都会彼此抢夺同一个锁。要是有很多个属性都这么写的话，那么每个属性的同步块都要等其他所有同步块执行完毕才能执行，这也许并不是开发者想要的效果。我们只是想令每个属性各自独立地同步。

　　顺便说一下，这么做虽然能提供某种程度的 “线程安全”（thread safety），但却无法保证访问该对象时绝对是线程安全的。当然，访问属性的操作确实是“原子的”。使用属性时，必定能从中获取到有效值，然而在同一个线程上多次调用获取方法（getter），每次获取到的结果未必相同。在两次访问操作之间，其他线程可能会写入新的属性值。

　　有种简单而高效的办法可以代替同步块或锁对象，那就是使用 “串行同步队列”（serial synchronization queue）。将读取操作及写入操作都安排在同一个队列里，即可保证数据同步。

　　其用法如下：

 1 　　_syncQueue = dispatch_queue_create("com.effectiveobjectivec.syncQueue", NULL);
 2 　　-(NSString *)someString {
 3 
 4 　　　　__block NSString *localSomeString;
 5 　　　　dispatch_sync(_syncQueue, ^{
 6 
 7 　　　　　　localSomeString = _someString;　　　　　　
 8 
 9 　　　　});
10 　　　　return localSomeString;
11 　　}
12 
13 
14 
15 　　- (void)setSomeString:(NSString *)someString {
16 
17 　　　　dispatch_sync(_suncQueue, ^{
18 
19 　　　　　　_someString = someString;　　　　
20 
21 　　　　});
22 　　}

　　此模式的思路是：把设置操作与获取操作都安排在序列化的队列里执行，这样的话，所有针对属性的访问操作就都同步了。为了使块代码能够设置局部变量，获取方法中用到了 __block 语法，若是抛开这一点，那么这种写法要比前面那些更为整洁。全部加锁任务都在 GCD 中处理，而 GCD 是在相当深的底层来实现的，于是能够做许多优化。因此，开发者无须担心那些事，只要专心把访问方法写好就行。

　　然而还可以进一步优化。设置方法并不一定非得是同步的。设置实例变量所用的块，并不需要向设置方法返回什么值。也就是说，设置方法的代码可以改成下面这样：

1 　　- (void)setSomeString:(NSString *)someString {
2 
3 　　　　dispatch_async(_syncQueue, ^{
4 
5 　　　　　　_someString = someString;
6 　　　　});
7 
8 　　}

　　这次只是把同步派发改成了异步派发，从调用者的角度来看，这个小改动可以提升设置方法的执行速度，而读取操作与写入操作依然会按顺序执行。但这么改有个坏处：如果你测一下程序性能，那么可能会发现这种写法比原来慢，因为执行异步派发时，需要拷贝块。若拷贝块所用的时间明显超过执行块所花的时间，则这种写法将比原来更慢。由于本书所举的这个例子很简单，所以改完之后很可能会变慢。然而，若是派发给队列的块要执行更为繁重的任务，那么仍然可以考虑这种备选方案。

　　多个获取方法可以并发执行，而获取方法与设置方法之间不能并发执行，利用这个特点，还能写出更快一些的代码来。此时正可以体现出 GCD 写法的好处。用同步块或锁对象，是无法轻易实现出下面这种方案的。这次不用串行队列，而改用并发队列（concurrent queue）:

 1 　　_syncQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
 2 
 3 　　- (NSString *)someString {
 4 
 5 　　　　__block NSString *localSomeString ;
 6 　　　　dispatch_sync(_syncQueue, ^{
 7 　　　　　　　localSomeString = _someString;
 8 　　　　});
 9 　　　　return localSomeString;
10 　　}
11 
12 　　- (void)setSomeString:(NSString *)someString {
13 
14 　　　　dispatch_async(_syncQueue, ^{
15 
16 　　　　　　_someString = someString;
17 
18 　　　　});
19 
20 　　}

　　像现在这样写代码，还无法正确实现同步。所有读取操作与写入操作都会在同一个队列上执行，不过由于是并发队列，所以读取与写入操作可以随时执行。而我们恰恰不想让这些操作随意执行。此问题用一个简单的 GCD 功能即可解决，它就是栅栏（barrier）。下列函数可以向队列中派发块，将其作为栅栏使用：

1 　　void dispatch_barrier_async(dispatch_queue_t queue, dispatch_block_t block);
2 
3 　　void dispatch_barrier_sync(dispatch_queue_t queue, dispatch_block_t block);

　　在队列中，栅栏块必须单独执行，不能与其他块并行。这只对并发队列有意义，因为串行队列中的块总是按顺序逐个来执行的。并发队列如果发现接下来要处理的块是个栅栏块（barrier block）(barrier 一词也称 “阻断器”、“障碍”、“屏障”) ，那么就一直要等当前所有并发块都执行完毕，才会单独执行这个栅栏块。待栅栏块执行过后，再按正常方式继续向下处理。

　　在本例中，可以用栅栏块来实现属性的设置方法。在设置方法中使用了栅栏块之后，对属性的读取操作依然可以并发执行，但是写入操作却必须单独执行了。在图所演示的这个队列中，有许多读取操作，而且还有一个写入操作。

　　实现代码很简单：

 1 　　_syncQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAUL, 0);
 2 
 3 　　- (NSString *)someString {
 4 
 5 　　　　__block NSString *localSomeString ;
 6 　　　　dispatch_sync(_syncQueue, ^{
 7 
 8 　　　　　　localSomeString = _someString;　　　　　
 9 
10 　　　　});
11 　　　　return localSomeString;
12 　　}
13 
14 　　- (void)setSomeString:(NSString *)someString {
15 
16 　　　　dispatch_barrier_async(_syncQueue, ^{
17 
18 　　　　　　_someString = someString;　　　　
19 
20 　　　　});
21 　　}

　　　　　　　　　　　　　　

　　在这个并发队列中，读取操作是用普通的块来实现的，而写入操作则是用栅栏块来实现的

　　读取操作可以并行，但写入操作必须单独执行，因为它是栅栏块

　　测试一下性能，你就会发现，这种做法肯定比使用串行队列要快。注意，设置函数也可以改用同步的栅栏块（synchronous barrier）来实现，那样做可能会更高效，其原因刚才已经解释过了。最好还是测一测每种做法的性能，然后从中选出最适合当前场景的方案。

END

 

转载于:https://www.cnblogs.com/chmhml/p/7399803.html