iOS多线程开发：几个容易被忽略的细节

一般情况下，iOS开发者只要会使用GCD、@synchronized、NSLock等几个简单的API，就可以应对大部分多线程开发了，不过这样是否真正做到了多线程安全，又是否真正充分利用了多线程的效率优势呢?看看以下几个容易被忽略的细节。

读者写者问题(Readers-writers problem)

先看下读者写者问题的描述：

有读者和写者两组并发线程，共享同一数据，当两个或以上的读线程同时访问共享数据时不会产生副作用，但若某个写线程和其他线程(读线程或写线程)同时访问共享数据时则可能导致数据不一致的错误。因此要求：

• 允许多个读者可以同时对共享数据执行读操作;
• 只允许一个写者写共享数据;
• 任一写者在完成写操作之前不允许其他读者或写者工作;
• 写者执行写操作前，应让已有的读者和写者全部退出。

从以上描述可以得知，所谓“读者写者问题”是指保证一个写线程必须与其他线程互斥地访问共享对象的同步问题，允许并发读操作，但是写操作必须和其他读写操作是互斥的。

大部分客户端app做的事情无非就是从网络拉取最新数据、加工数据、展现列表，这个过程中既有拿到最新数据后写入本地的操作，也有上层业务对本地数据的读取操作，因此会牵涉大量的多线程读写操作，很显然，这些基本都属于读者写者问题的范畴[1]。

然而笔者注意到，在遇到多线程读写问题时，多数iOS开发者都会立即想到加锁，或者干脆避免使用多线程，但却少有人会尝试用读者写者问题的思路去进一步提升效率。

以下是实现一个简单cache的示例代码：

1. //实现一个简单的cache 
2. - (void)setCache:(id)cacheObject forKey:(NSString *)key { 
3.     if (key.length == 0) { 
4.         return; 
5.     } 
6.     [_cacheLock lock]; 
7.     self.cacheDic[key] = cacheObject; 
8.     ... 
9.     [_cacheLock unlock]; 
10. } 
11.  
12. - (id)cacheForKey:(NSString *key) { 
13.     if (key.length == 0) { 
14.         return nil; 
15.     } 
16.     [_cacheLock lock]; 
17.     id cacheObject = self.cacheDic[key]; 
18.     ... 
19.     [_cacheLock unlock]; 
20.     return cacheObject; 
21. } 

上述代码用互斥锁来实现多线程读写，做到了数据的安全读写，但是效率却并不是最高的，因为这种情况下，虽然写操作和其他操作之间是互斥的，但同时读操作之间却也是互斥的，这会浪费cpu资源，如何改良呢?不难发现，这其实是个典型的读者写者问题。先看下解决读者写者问题的伪代码：

1. semaphore ReaderWriterMutex = 1;    //实现读写互斥 
2. int Rcount = 0;             //读者数量 
3. semaphore CountMutex = 1;   //读者修改计数互斥 
4.  
5. writer(){ 
6.     while(true){ 
7.         P(ReaderWriterMutex); 
8.         write; 
9.         V(ReaderWriterMutex);    
10.     } 
11.      
12. } 
13.  
14. reader(){ 
15.     while(true){ 
16.         P(CountMutex); 
17.         if(Rcount == 0)     //当第一个读者进来时，阻塞写者 
18.             P(ReaderWriterMutex); 
19.         ++Rcount; 
20.         V(CountMutex); 
21.  
22.         read; 
23.  
24.         P(CountMutex); 
25.         --Rcount; 
26.         if(Rcount == 0) 
27.             V(ReaderWriterMutex);   //当最后一个读者离开后，释放写者 
28.         V(CountMutex); 
29.     } 
30. } 

在iOS中，上述代码中的PV原语可以替换成GCD中的信号量API，dispatch_semaphore_t来实现，但是需要额外维护一个readerCount以及实现readerCount互斥访问的信号量，手动实现比较麻烦，封装成统一接口有一定难度。不过好在iOS开发中可以找到现成的读者写者锁：

pthread_rwlock_t

这是一个古老的C语言层面的函数，用法如下：

1. // Initialization of lock, pthread_rwlock_t is a value type and must be declared as var in order to refer it later. Make sure not to copy it. 
2. var lock = pthread_rwlock_t() 
3. pthread_rwlock_init(&lock, nil) 
4.  
5. // Protecting read section: 
6. pthread_rwlock_rdlock(&lock) 
7. // Read shared resource 
8. pthread_rwlock_unlock(&lock) 
9.  
10. // Protecting write section: 
11. pthread_rwlock_wrlock(&lock) 
12. // Write shared resource 
13. pthread_rwlock_unlock(&lock) 
14.  
15. // Clean up 
16. pthread_rwlock_destroy(&lock) 

接口简洁但是却不友好，需要注意pthread_rwlock_t是值类型，用=赋值会直接拷贝，不小心就会浪费内存，另外用完后还需要记得销毁，容易出错，有没有更高级更易用的API呢?

GCD barrier

dispatch_barrier_async / dispatch_barrier_sync并不是专门用来解决读者写者问题的，barrier主要用于以下场景：当执行某一任务A时，需要该队列上之前添加的所有操作都执行完，而之后添加进来的任务，需要等待任务A执行完毕才可以执行，从而达到将任务A隔离的目的，具体过程如下图所示：

如果将barrier任务之前和之后的并发任务换为读操作，barrier任务本身换为写操作，就可以将dispatch_barrier_async / dispatch_barrier_sync当做读者写者锁来使用了，下面把文初的使用普通锁实现的cache代码，用dispatch_barrier_async重写，做下对比：

1. //实现一个简单的cache（使用普通锁） 
2. - (void)setCache:(id)cacheObject forKey:(NSString *)key { 
3.     if (key.length == 0) { 
4.         return; 
5.     } 
6.     [_cacheLock lock]; 
7.     self.cacheDic[key] = cacheObject; 
8.     ... 
9.     [_cacheLock unlock]; 
10. } 
11.  
12. - (id)cacheForKey:(NSString *key) { 
13.     if (key.length == 0) { 
14.         return nil; 
15.     } 
16.     [_cacheLock lock]; 
17.     id cacheObject = self.cacheDic[key]; 
18.     ... 
19.     [_cacheLock unlock]; 
20.     return cacheObject; 
21. } 

1. //实现一个简单的cache（使用读者写者锁） 
2. static dispatch_queue_t queue = dispatch_queue_create("com.gfzq.testQueue", DISPATCH_QUEUE_CONCURRENT); 
3.  
4. - (void)setCache:(id)cacheObject forKey:(NSString *)key { 
5.     if (key.length == 0) { 
6.         return; 
7.     } 
8.     dispatch_barrier_async(queue, ^{ 
9.         self.cacheDic[key] = cacheObject; 
10.         ... 
11.     }); 
12. } 
13.  
14. - (id)cacheForKey:(NSString *key) { 
15.     if (key.length == 0) { 
16.         return nil; 
17.     } 
18.     __block id cacheObject = nil; 
19.     dispatch_sync(queue, ^{ 
20.         cacheObject = self.cacheDic[key]; 
21.         ... 
22.     }); 
23.     return cacheObject; 
24. } 

这样实现的cache就可以并发执行读操作，同时又有效地隔离了写操作，兼顾了安全和效率。

对于声明为atomic而且又自己手动实现getter或者setter的属性，也可以用barrier来改进：

1. @property (atomic, copy) NSString *someString; 
2.  
3. - (NSString *)someString { 
4.     __block NSString *tempString; 
5.     dispatch_sync(_syncQueue, ^{ 
6.         tempString = _someString; 
7.     }); 
8.     return tempString; 
9. } 
10.  
11. - (void)setSomeString :(NSString *)someString { 
12.     dispatch_barrier_async(_syncQueue, ^{ 
13.         _someString = someString 
14.         ... 
15.     } 
16. } 

在做到atomic的同时，getter之间还可以并发执行，比直接把setter和getter都放到串行队列或者加普通锁要更高效。

读者写者锁能提升多少效率?

使用读者写者锁一定比所有读写都加锁以及使用串行队列要快，但是到底能快多少呢?Dmytro Anokhin在[3]中做了实验对比，测出了分别使用NSLock、GCD barrier和pthread_rwlock时获取锁所需要的平均时间，实验样本数在100到1000之间，去掉最高和最低的10%，结果如下列图表所示：

3 writers / 10 readers

1 writer / 10 readers

5 writers / 5 readers

10 writers / 1 reader

分析可知：

1. 使用读者写者锁(GCD barrier、pthread_rwlock)，相比单纯使用普通锁(NSLock)，效率有显著提升;
2. 读者数量越多，写者数量越少，使用读者写者锁的效率优势越明显;
3. 使用GCD barrier和使用pthread_rwlock的效率差异不大。

由于pthread_rwlock不易使用且容易出错，而且GCD barrier和pthread_rwlock对比性能相当，建议使用GCD barrier来解决iOS开发中遇到的读者写者问题。另外，使用GCD还有个潜在优势：GCD面向队列而非线程，dispatch至某一队列的任务，可能在任一线程上执行，这些对开发者是透明的，这样设计的好处显而易见，GCD可以根据实际情况从自己管理的线程池中挑选出开销最小的线程来执行任务，最大程度减小context切换次数。

何时使用读者写者锁

需要注意的是，并非所有的多线程读写场景都一定是读者写者问题，使用时要注意辨别。例如以下YYCache的代码：

1. //读cache 
2. - (id)objectForKey:(id)key { 
3.     if (!key) return nil; 
4.     pthread_mutex_lock(&_lock); 
5.     _YYLinkedMapNode *node = CFDictionaryGetValue(_lru->_dic, (__bridge const void *)(key)); 
6.     if (node) { 
7.         node->_time = CACurrentMediaTime(); 
8.         [_lru bringNodeToHead:node]; 
9.     } 
10.     pthread_mutex_unlock(&_lock); 
11.     return node ? node->_value : nil; 
12. } 

1. //写cache 
2. - (void)setObject:(id)object forKey:(id)key withCost:(NSUInteger)cost { 
3.     if (!key) return; 
4.     if (!object) { 
5.         [self removeObjectForKey:key]; 
6.         return; 
7.     } 
8.     pthread_mutex_lock(&_lock); 
9.     _YYLinkedMapNode *node = CFDictionaryGetValue(_lru->_dic, (__bridge const void *)(key)); 
10.     NSTimeInterval now = CACurrentMediaTime(); 
11.     if (node) { 
12.         _lru->_totalCost -= node->_cost; 
13.         _lru->_totalCost += cost; 
14.         node->_cost = cost; 
15.         node->_time = now; 
16.         node->_value = object; 
17.         [_lru bringNodeToHead:node]; 
18.     } else { 
19.         node = [_YYLinkedMapNode new]; 
20.         node->_cost = cost; 
21.         node->_time = now; 
22.         node->_key = key; 
23.         node->_value = object; 
24.         [_lru insertNodeAtHead:node]; 
25.     } 
26.     if (_lru->_totalCost > _costLimit) { 
27.         dispatch_async(_queue, ^{ 
28.             [self trimToCost:_costLimit]; 
29.         }); 
30.     } 
31.     if (_lru->_totalCount > _countLimit) { 
32.         _YYLinkedMapNode *node = [_lru removeTailNode]; 
33.         if (_lru->_releaseAsynchronously) { 
34.             dispatch_queue_t queue = _lru->_releaseOnMainThread ? dispatch_get_main_queue() : YYMemoryCacheGetReleaseQueue(); 
35.             dispatch_async(queue, ^{ 
36.                 [node class]; //hold and release in queue 
37.             }); 
38.         } else if (_lru->_releaseOnMainThread && !pthread_main_np()) { 
39.             dispatch_async(dispatch_get_main_queue(), ^{ 
40.                 [node class]; //hold and release in queue 
41.             }); 
42.         } 
43.     } 
44.     pthread_mutex_unlock(&_lock); 
45. } 

这里的cache由于使用了LRU淘汰策略，每次在读cache的同时，会将本次的cache放到数据结构的最前面，从而延缓最近使用的cache被淘汰的时机，因为每次读操作的同时也会发生写操作，所以这里直接使用pthread_mutex互斥锁，而没有使用读者写者锁。

综上所述，如果你所遇到的多线程读写场景符合：

1. 存在单纯的读操作(即读任务里没有同时包含写操作);
2. 读者数量较多，而写者数量较少。

都应该考虑使用读者写者锁来进一步提升并发率。

注意：

(1)读者写者问题包含“读者优先”和“写者优先”两类：前者表示读线程只要看到有其他读线程正在访问文件，就可以继续作读访问，写线程必须等待所有读线程都不访问时才能写文件，即使写线程可能比一些读线程更早提出申请;而写者优先表示写线程只要提出申请，再后来的读线程就必须等待该写线程完成。GCD的barrier属于写者优先的实现。具体请参考文档[2]。

(2)串行队列上没必要使用GCD barrier，应该使用dispatch_queue_create建立的并发队列;dispatch_get_global_queue由于是全局共享队列，使用barrier达不到隔离当前任务的效果，会自动降级为dispatch_sync / dispatch_async。[5]

锁的粒度(Granularity)

首先看两段代码：

代码段1

1. @property (atomic, copy) NSString *atomicStr; 
2.  
3. //thread A 
4. atomicSr = @"am on thread A"; 
5. NSLog(@"%@", atomicStr); 
6.  
7. //thread B 
8. atomicSr = @"am on thread B"; 
9. NSLog(@"%@", atomicStr); 

代码段2

1. - (void)synchronizedAMethod { 
2.     @synchronized (self) { 
3.         ... 
4.     } 
5. } 
6.  
7. - (void)synchronizedBMethod { 
8.     @synchronized (self) { 
9.         ... 
10.     } 
11. } 
12.  
13. - (void)synchronizedCMethod { 
14.     @synchronized (self) { 
15.         ... 
16.     } 
17. } 

粒度过小

执行代码段1，在线程A上打印出来的字符串却可能是“am on thread B”，原因是虽然atomicStr是原子操作，但是取出atomicStr之后，在执行NSLog之前，atomicStr仍然可能会被线程B修改。因此atomic声明的属性，只能保证属性的get和set是完整的，但是却不能保证get和set完之后的关于该属性的操作是多线程安全的，这就是aomic声明的属性不一定能保证多线程安全的原因。

同样的，不仅仅是atomic声明的属性，在开发中自己加的锁如果粒度太小，也不能保证线程安全，代码段1其实和下面代码效果一致：

1. @property (nonatomic, strong) NSLock *lock; 
2. @property (nonatomic, copy) NSString *atomicStr; 
3.  
4. //thread A 
5. [_lock lock]; 
6. atomicSr = @"am on thread A"; 
7. [_lock unlock]; 
8. NSLog(@"%@", atomicStr); 
9.  
10. //thread B 
11. [_lock lock]; 
12. atomicSr = @"am on thread B"; 
13. [_lock unlock]; 
14. NSLog(@"%@", atomicStr); 

如果想让程序按照我们的初衷，设置完atomicStr后打印出来的就是设置的值，就需要加大锁的范围，将NSLog也包括在临界区内：

1. //thread A 
2. [_lock lock]; 
3. atomicSr = @"am on thread A"; 
4. NSLog(@"%@", atomicStr); 
5. [_lock unlock]; 
6.  
7. //thread B 
8. [_lock lock]; 
9. atomicSr = @"am on thread B"; 
10. NSLog(@"%@", atomicStr); 
11. [_lock unlock]; 

示例代码很简单，很容易看出问题所在，但是在实际开发中遇到更复杂些的代码块时，一不小心就可能踏入坑里。因此在设计多线程代码时，要特别注意代码之间的逻辑关系，若后续代码依赖于加锁部分的代码，那这些后续代码也应该一并加入锁中。

粒度过大

@synchronized关键字会自动根据传入对象创建一个与之关联的锁，在代码块开始时自动加锁，并在代码块结束后自动解锁，语法简单明了，很方便使用，但是这也导致部分开发者过渡依赖于@synchronized关键字，滥用@synchronized(self)。如上述代码段2中的写法，在一整个类文件里，所有加锁的地方用的都是@synchronized(self)，这就可能会导致不相关的线程执行时都要互相等待，原本可以并发执行的任务不得不串行执行。另外使用@synchronized(self)还可能导致死锁：

1. //class A 
2.  
3. @synchronized (self) { 
4.     [_sharedLock lock]; 
5.     NSLog(@"code in class A"); 
6.     [_sharedLock unlock]; 
7. } 
8.  
9. //class B 
10. [_sharedLock lock]; 
11. @synchronized (objectA) { 
12.     NSLog(@"code in class B"); 
13. } 
14. [_sharedLock unlock]; 

原因是因为self很可能会被外部对象访问，被用作key来生成一锁，类似上述代码中的@synchronized (objectA)。两个公共锁交替使用的场景就容易出现死锁。所以正确的做法是传入一个类内部维护的NSObject对象，而且这个对象是对外不可见的[2]。

因此，不相关的多线程代码，要设置不同的锁，一个锁只管一个临界区。除此之外，还有种常见的错误做法会导致并发效率下降：

1. //thread A 
2. [_lock lock]; 
3. atomicSr = @"am on thread A"; 
4. NSLog(@"%@", atomicStr); 
5. //do some other tasks which are none of business with atomicStr; 
6. for (int i = 0; i < 100000; i ++) { 
7.     sleep(5); 
8. } 
9. [_lock unlock]; 
10.  
11. //thread B 
12. [_lock lock]; 
13. atomicSr = @"am on thread B"; 
14. NSLog(@"%@", atomicStr); 
15. //do some other tasks which are none of business with atomicStr; 
16. for (int i = 0; i < 100000; i ++) { 
17.     sleep(5); 
18. } 
19. [_lock unlock]; 

即在临界区内包含了与当前加锁对象无关的任务，实际应用中，需要我们尤其注意临界区内的每一个函数，因为其内部实现可能调用了耗时且无关的任务。

递归锁(Recursive lock)

相比较上述提到的@synchronized(self)，下面这种情形引起的死锁更加常见：

1. @property (nonatomic,strong) NSLock *lock; 
2.  
3. _lock = [[NSLock alloc] init]; 
4.  
5. - (void)synchronizedAMethod { 
6.     [_lock lock]; 
7.     //do some tasks 
8.     [self synchronizedBMethod]; 
9.     [_lock unlock]; 
10. } 
11.  
12. - (void)synchronizedBMethod { 
13.     [_lock lock]; 
14.     //do some tasks 
15.     [_lock unlock]; 
16. } 

A方法已获取锁后，再调用B方法，就会触发死锁，B方法在等待A方法执行完成释放锁后才能继续执行，而A方法执行完成的前提是执行完B方法。实际开发中，可能发生死锁的情形往往隐蔽在方法的层层调用中。因此建议在不能确定是否会产生死锁时，最好使用递归锁。更保守一点的做法是不论何时都使用递归锁，因为很难保证以后的代码会不会在同一线程上多次加锁。

递归锁允许同一个线程在未释放其拥有的锁时反复对该锁进行加锁操作，内部通过一个计数器来实现。除了NSRecursiveLock，也可以使用性能更佳的pthread_mutex_lock，初始化时参数设置为PTHREAD_MUTEX_RECURSIVE即可：

1. pthread_mutexattr_t attr; 
2. pthread_mutexattr_init (&attr); 
3. pthread_mutexattr_settype (&attr, PTHREAD_MUTEX_RECURSIVE); 
4. pthread_mutex_init (&_lock, &attr); 
5. pthread_mutexattr_destroy (&attr); 

值得注意的是，@synchronized内部使用的也是递归锁：

1. // Begin synchronizing on 'obj'.  
2. // Allocates recursive mutex associated with 'obj' if needed. 
3. // Returns OBJC_SYNC_SUCCESS once lock is acquired.   
4. int objc_sync_enter(id obj) 
5. { 
6.     int result = OBJC_SYNC_SUCCESS; 
7.  
8.     if (obj) { 
9.         SyncData* data = id2data(obj, ACQUIRE); 
10.         assert(data); 
11.         data->mutex.lock(); 
12.     } else { 
13.         // @synchronized(nil) does nothing 
14.         if (DebugNilSync) { 
15.             _objc_inform("NIL SYNC debug: @synchronized(nil); set a breakpoint on objc_sync_nil to debug"); 
16.         } 
17.         objc_sync_nil(); 
18.     } 
19.  
20.     return result; 
21. } 

总结

想写出高效、安全的多线程代码，只是熟悉GCD、@synchronized、NSLock这几个API是不够的，还需要了解更多API背后的知识，深刻理解临界区的概念、理清各个任务之间的时序关系是必要条件。

为了保护你的隐私，从日历、通讯录、提醒事项和照片获取位置信息的 app 必须先获得你的许可。你可以设置密码锁，以防止有人未经授权访问你的设备，并进行相关配置，允许设备在多次尝试输入密码失败后删除所有数据。