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

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

读者写者问题（Readers-writers problem）

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

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

  • 允许多个读者可以同时对共享数据执行读操作；

  • 只允许一个写者写共享数据；

  • 任一写者在完成写操作之前不允许其他读者或写者工作；

  • 写者执行写操作前，应让已有的读者和写者全部退出。

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

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

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

以下是实现一个简单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%，结果如下列图表所示：

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的代码：

//读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。[5]

锁的粒度（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背后的知识，深刻理解临界区的概念、理清各个任务之间的时序关系是必要条件。

参考文档

[1] iOS应用架构谈
[2] Concurrency in Swift: Reader Writer Lock
[3] 正确使用多线程同步锁@synchronized()
[4] iOS多线程到底不安全在哪里？
[5] dispatch_barrier_async
[6] 深入理解iOS开发中的锁
[7] NSRecursiveLock
[8] Readers-writers problem
[9] Effective Objective-C 2.0

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 157,012评论 4赞 359
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 66,589评论 1赞 290
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 106,819评论 0赞 237
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 43,652评论 0赞 202
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 51,954评论 3赞 285
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 40,381评论 1赞 210
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 31,687评论 2赞 310
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 30,404评论 0赞 194
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 34,082评论 1赞 238
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,355评论 2赞 241
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,880评论 1赞 255
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 28,249评论 2赞 250
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 32,864评论 3赞 232
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,007评论 0赞 8
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,760评论 0赞 192
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 35,394评论 2赞 269
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 35,281评论 2赞 259