iOS多线程开发：几个容易被忽略的细节
通常状况下，iOS开发者只要会使用GCD、@synchronized、NSLock等几个简单的API，就能够应对大部分多线程开发了，不过这样是否真正作到了多线程安全，又是否真正充分利用了多线程的效率优点呢？看看如下几个容易被忽略的细节。node
读者写者问题（Readers-writers problem）
先看下读者写者问题的描述：面试
有读者和写者两组并发线程，共享同一数据，当两个或以上的读线程同时访问共享数据时不会产生反作用，但若某个写线程和其余线程（读线程或写线程）同时访问共享数据时则可能致使数据不一致的错误。所以要求：算法
-
容许多个读者能够同时对共享数据执行读操做；swift
-
只容许一个写者写共享数据；安全
-
任一写者在完成写操做以前不容许其余读者或写者工做；bash
-
写者执行写操做前，应让已有的读者和写者所有退出。网络
从以上描述能够得知，所谓“读者写者问题”是指保证一个写线程必须与其余线程互斥地访问共享对象的同步问题，容许并发读操做，可是写操做必须和其余读写操做是互斥的。数据结构
大部分客户端App作的事情无非就是从网络拉取最新数据、加工数据、展示列表，这个过程当中既有拿到最新数据后写入本地的操做，也有上层业务对本地数据的读取操做，所以会牵涉大量的多线程读写操做，很显然，这些基本都属于读者写者问题的范畴[1]。多线程
然而笔者注意到，在遇到多线程读写问题时，多数iOS开发者都会当即想到加锁，或者干脆避免使用多线程，但却少有人会尝试用读者写者问题的思路去进一步提高效率。并发
给你们推荐一个iOS技术交流群!763164022群内提供数据结构与算法、底层进阶、swift、逆向、底层面试题整合文档等免费资料！
如下是实现一个简单cache的示例代码：
//实现一个简单的cache
- (void)setCache:(id)cacheObject forKey:(NSString *)key {
if (key.length == 0) {
return;
}
[_cacheLock lock];
self.cacheDic[key] = cacheObject;
...
[_cacheLock unlock];
}
- (id)cacheForKey:(NSString *key) {
if (key.length == 0) {
return nil;
}
[_cacheLock lock];
id cacheObject = self.cacheDic[key];
...
[_cacheLock unlock];
return cacheObject;
}
复制代码
上述代码用互斥锁来实现多线程读写，作到了数据的安全读写，可是效率却并非最高的，由于这种状况下，虽然写操做和其余操做之间是互斥的，但同时读操做之间却也是互斥的，这会浪费cpu资源，如何改良呢？不难发现，这实际上是个典型的读者写者问题。先看下解决读者写者问题的伪代码：
semaphore ReaderWriterMutex = 1; //实现读写互斥
int Rcount = 0; //读者数量
semaphore CountMutex = 1; //读者修改计数互斥
writer(){
while(true){
P(ReaderWriterMutex);
write;
V(ReaderWriterMutex);
}
}
reader(){
while(true){
P(CountMutex);
if(Rcount == 0) //当第一个读者进来时，阻塞写者
P(ReaderWriterMutex);
++Rcount;
V(CountMutex);
read;
P(CountMutex);
--Rcount;
if(Rcount == 0)
V(ReaderWriterMutex); //当最后一个读者离开后，释放写者
V(CountMutex);
}
}
复制代码
在iOS中，上述代码中的PV原语能够替换成GCD中的信号量API，dispatch_semaphore_t来实现，可是须要额外维护一个readerCount以及实现readerCount互斥访问的信号量，手动实现比较麻烦，封装成统一接口有必定难度。不过好在iOS开发中能够找到现成的读者写者锁：
pthread_rwlock_t
这是一个古老的C语言层面的函数，用法以下：
// 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.
var lock = pthread_rwlock_t()
pthread_rwlock_init(&lock, nil)
// Protecting read section:
pthread_rwlock_rdlock(&lock)
// Read shared resource
pthread_rwlock_unlock(&lock)
// Protecting write section:
pthread_rwlock_wrlock(&lock)
// Write shared resource
pthread_rwlock_unlock(&lock)
// Clean up
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重写，作下对比：
//实现一个简单的cache（使用普通锁）
- (void)setCache:(id)cacheObject forKey:(NSString *)key {
if (key.length == 0) {
return;
}
[_cacheLock lock];
self.cacheDic[key] = cacheObject;
...
[_cacheLock unlock];
}
- (id)cacheForKey:(NSString *key) {
if (key.length == 0) {
return nil;
}
[_cacheLock lock];
id cacheObject = self.cacheDic[key];
...
[_cacheLock unlock];
return cacheObject;
}
复制代码
//实现一个简单的cache（使用读者写者锁）
static dispatch_queue_t queue = dispatch_queue_create("com.gfzq.testQueue", DISPATCH_QUEUE_CONCURRENT);
- (void)setCache:(id)cacheObject forKey:(NSString *)key {
if (key.length == 0) {
return;
}
dispatch_barrier_async(queue, ^{
self.cacheDic[key] = cacheObject;
...
});
}
- (id)cacheForKey:(NSString *key) {
if (key.length == 0) {
return nil;
}
__block id cacheObject = nil;
dispatch_sync(queue, ^{
cacheObject = self.cacheDic[key];
...
});
return cacheObject;
}
复制代码
这样实现的cache就能够并发执行读操做，同时又有效地隔离了写操做，兼顾了安全和效率。
对于声明为atomic并且又本身手动实现getter或者setter的属性，也能够用barrier来改进：
@property (atomic, copy) NSString *someString;
- (NSString *)someString {
__block NSString *tempString;
dispatch_sync(_syncQueue, ^{
tempString = _someString;
});
return tempString;
}
- (void)setSomeString :(NSString *)someString {
dispatch_barrier_async(_syncQueue, ^{
_someString = someString
...
}
}
复制代码
在作到atomic的同时，getter之间还能够并发执行，比直接把setter和getter都放到串行队列或者加普通锁要更高效。
读者写者锁能提高多少效率？
使用读者写者锁必定比全部读写都加锁以及使用串行队列要快，可是到底能快多少呢？Dmytro Anokhin在[3]中作了实验对比，测出了分别使用NSLock、GCD barrier和pthread_rwlock时获取锁所须要的平均时间，实验样本数在100到1000之间，去掉最高和最低的10%，结果以下列图表所示：
分析可知：
（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的代码：
//读cache
- (id)objectForKey:(id)key {
if (!key) return nil;
pthread_mutex_lock(&_lock);
_YYLinkedMapNode *node = CFDictionaryGetValue(_lru->_dic, (__bridge const void *)(key));
if (node) {
node->_time = CACurrentMediaTime();
[_lru bringNodeToHead:node];
}
pthread_mutex_unlock(&_lock);
return node ? node->_value : nil;
}
复制代码
//写cache
- (void)setObject:(id)object forKey:(id)key withCost:(NSUInteger)cost {
if (!key) return;
if (!object) {
[self removeObjectForKey:key];
return;
}
pthread_mutex_lock(&_lock);
_YYLinkedMapNode *node = CFDictionaryGetValue(_lru->_dic, (__bridge const void *)(key));
NSTimeInterval now = CACurrentMediaTime();
if (node) {
_lru->_totalCost -= node->_cost;
_lru->_totalCost += cost;
node->_cost = cost;
node->_time = now;
node->_value = object;
[_lru bringNodeToHead:node];
} else {
node = [_YYLinkedMapNode new];
node->_cost = cost;
node->_time = now;
node->_key = key;
node->_value = object;
[_lru insertNodeAtHead:node];
}
if (_lru->_totalCost > _costLimit) {
dispatch_async(_queue, ^{
[self trimToCost:_costLimit];
});
}
if (_lru->_totalCount > _countLimit) {
_YYLinkedMapNode *node = [_lru removeTailNode];
if (_lru->_releaseAsynchronously) {
dispatch_queue_t queue = _lru->_releaseOnMainThread ? dispatch_get_main_queue() : YYMemoryCacheGetReleaseQueue();
dispatch_async(queue, ^{
[node class]; //hold and release in queue
});
} else if (_lru->_releaseOnMainThread && !pthread_main_np()) {
dispatch_async(dispatch_get_main_queue(), ^{
[node class]; //hold and release in queue
});
}
}
pthread_mutex_unlock(&_lock);
}
复制代码
这里的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。[
锁的粒度（Granularity）
首先看两段代码： 代码段1
@property (atomic, copy) NSString *atomicStr;
//thread A
atomicSr = @"am on thread A";
NSLog(@"%@", atomicStr);
//thread B
atomicSr = @"am on thread B";
NSLog(@"%@", atomicStr);
复制代码
代码段2
- (void)synchronizedAMethod {
@synchronized (self) {
...
}
}
- (void)synchronizedBMethod {
@synchronized (self) {
...
}
}
- (void)synchronizedCMethod {
@synchronized (self) {
...
}
}
复制代码
粒度太小
执行代码段1，在线程A上打印出来的字符串却多是“am on thread B”，缘由是虽然atomicStr是原子操做，可是取出atomicStr以后，在执行NSLog以前，atomicStr仍然可能会被线程B修改。所以atomic声明的属性，只能保证属性的get和set是完整的，可是却不能保证get和set完以后的关于该属性的操做是多线程安全的，这就是aomic声明的属性不必定能保证多线程安全的缘由。
一样的，不只仅是atomic声明的属性，在开发中本身加的锁若是粒度过小，也不能保证线程安全，代码段1其实和下面代码效果一致：
@property (nonatomic, strong) NSLock *lock;
@property (nonatomic, copy) NSString *atomicStr;
//thread A
[_lock lock];
atomicSr = @"am on thread A";
[_lock unlock];
NSLog(@"%@", atomicStr);
//thread B
[_lock lock];
atomicSr = @"am on thread B";
[_lock unlock];
NSLog(@"%@", atomicStr);
复制代码
若是想让程序按照咱们的初衷，设置完atomicStr后打印出来的就是设置的值，就须要加大锁的范围，将NSLog也包括在临界区内：
//thread A
[_lock lock];
atomicSr = @"am on thread A";
NSLog(@"%@", atomicStr);
[_lock unlock];
//thread B
[_lock lock];
atomicSr = @"am on thread B";
NSLog(@"%@", atomicStr);
[_lock unlock];
复制代码
示例代码很简单，很容易看出问题所在，可是在实际开发中遇到更复杂些的代码块时，一不当心就可能踏入坑里。所以在设计多线程代码时，要特别注意代码之间的逻辑关系，若后续代码依赖于加锁部分的代码，那这些后续代码也应该一并加入锁中。
粒度过大
@synchronized关键字会自动根据传入对象建立一个与之关联的锁，在代码块开始时自动加锁，并在代码块结束后自动解锁，语法简单明了，很方便使用，可是这也致使部分开发者过渡依赖于@synchronized关键字，滥用@synchronized(self)。如上述代码段2中的写法，在一整个类文件里，全部加锁的地方用的都是@synchronized(self)，这就可能会致使不相关的线程执行时都要互相等待，本来能够并发执行的任务不得不串行执行。另外使用@synchronized(self)还可能致使死锁：
//class A
@synchronized (self) {
[_sharedLock lock];
NSLog(@"code in class A");
[_sharedLock unlock];
}
//class B
[_sharedLock lock];
@synchronized (objectA) {
NSLog(@"code in class B");
}
[_sharedLock unlock];
复制代码
缘由是由于self极可能会被外部对象访问，被用做key来生成一锁，相似上述代码中的@synchronized (objectA)。两个公共锁交替使用的场景就容易出现死锁。因此正确的作法是传入一个类内部维护的NSObject对象，并且这个对象是对外不可见的[2]。
所以，不相关的多线程代码，要设置不一样的锁，一个锁只管一个临界区。除此以外，还有种常见的错误作法会致使并发效率降低：
//thread A
[_lock lock];
atomicSr = @"am on thread A";
NSLog(@"%@", atomicStr);
//do some other tasks which are none of business with atomicStr;
for (int i = 0; i < 100000; i ++) {
sleep(5);
}
[_lock unlock];
//thread B
[_lock lock];
atomicSr = @"am on thread B";
NSLog(@"%@", atomicStr);
//do some other tasks which are none of business with atomicStr;
for (int i = 0; i < 100000; i ++) {
sleep(5);
}
[_lock unlock];
复制代码
即在临界区内包含了与当前加锁对象无关的任务，实际应用中，须要咱们尤为注意临界区内的每个函数，由于其内部实现可能调用了耗时且无关的任务。
递归锁（Recursive lock）
相比较上述提到的@synchronized(self)，下面这种情形引发的死锁更加常见：
@property (nonatomic,strong) NSLock *lock;
_lock = [[NSLock alloc] init];
- (void)synchronizedAMethod {
[_lock lock];
//do some tasks
[self synchronizedBMethod];
[_lock unlock];
}
- (void)synchronizedBMethod {
[_lock lock];
//do some tasks
[_lock unlock];
}
复制代码
A方法已获取锁后，再调用B方法，就会触发死锁，B方法在等待A方法执行完成释放锁后才能继续执行，而A方法执行完成的前提是执行完B方法。实际开发中，可能发生死锁的情形每每隐蔽在方法的层层调用中。所以建议在不能肯定是否会产生死锁时，最好使用递归锁。更保守一点的作法是不论什么时候都使用递归锁，由于很难保证之后的代码会不会在同一线程上屡次加锁。
递归锁容许同一个线程在未释放其拥有的锁时反复对该锁进行加锁操做，内部经过一个计数器来实现。除了NSRecursiveLock，也可使用性能更佳的pthread_mutex_lock，初始化时参数设置为PTHREAD_MUTEX_RECURSIVE便可：
pthread_mutexattr_t attr;
pthread_mutexattr_init (&attr);
pthread_mutexattr_settype (&attr, PTHREAD_MUTEX_RECURSIVE);
pthread_mutex_init (&_lock, &attr);
pthread_mutexattr_destroy (&attr);
复制代码
值得注意的是，@synchronized内部使用的也是递归锁：
// Begin synchronizing on 'obj'.
// Allocates recursive mutex associated with 'obj' if needed.
// Returns OBJC_SYNC_SUCCESS once lock is acquired.
int objc_sync_enter(id obj)
{
int result = OBJC_SYNC_SUCCESS;
if (obj) {
SyncData* data = id2data(obj, ACQUIRE);
assert(data);
data->mutex.lock();
} else {
// @synchronized(nil) does nothing
if (DebugNilSync) {
_objc_inform("NIL SYNC DEBUG: @synchronized(nil); set a breakpoint on objc_sync_nil to debug");
}
objc_sync_nil();
}
return result;
}
复制代码
总结
想写出高效、安全的多线程代码，只是熟悉GCD、@synchronized、NSLock这几个API是不够的，还须要了解更多API背后的知识，深入理解临界区的概念、理清各个任务之间的时序关系是必要条件。
给你们推荐一个iOS技术交流群!763164022群内提供数据结构与算法、底层进阶、swift、逆向、底层面试题整合文档等免费资料！
做者：Eternal_Love 连接：www.jianshu.com/p/b053b3c3c… 转载简书：简书
- 1. iOS多线程开发：几个容易被忽略的细节（马甲包）
- 2. 容易被忽视的js细节
- 3. html5一些容易忽略的细节
- 4. Java中容易被你忽略的细节(一)
- 5. 随手记几个容易被忽略的bug
- 6. WWDC 2015容易被忽视的9个细节（图文）
- 7. 史考特 容易忽略的开户细节
- 8. 站长最容易忽视的几个细节
- 9. 关于TCP套接字开启多进程主进程与子进程一个容易忽略的小细节
- 10. SQL开发中容易被忽略的BUG~
- 更多相关文章...
- • C# 多线程 - C#教程
- • Rust 并发编程 - RUST 教程
- • PHP开发工具
- • Git可视化极简易教程 — Git GUI使用方法
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 字节跳动21届秋招运营两轮面试经验分享
- 2. Java 3 年，25K 多吗？
- 3. mysql安装部署
- 4. web前端开发中父链和子链方式实现通信
- 5. 3.1.6 spark体系之分布式计算-scala编程-scala中trait特性
- 6. dataframe2
- 7. ThinkFree在线
- 8. 在线画图
- 9. devtools热部署
- 10. 编译和链接