iOS中的常见多线程方案
GCD
GCD源码地址:https://github.com/apple/swift-corelibs-libdispatch。
GCD使用概要:Objective-C之GCD概要。
常用函数
GCD中有2个用来执行任务的函数:
- 用同步的方式执行任务
1
| dispatch_sync(dispatch_queue_t queue, dispatch_block_t block);
|
- 用异步的方式执行任务
1
| dispatch_async(dispatch_queue_t queue, dispatch_block_t block);
|
队列
GCD的队列可以分为2大类型:
- 并发队列(Concurrent Dispatch Queue):可以让多个任务并发(同时)执行(自动开启多个线程同时执行任务),并发功能只有在异步(dispatch_async)函数下才有效
- 串行队列(Serial Dispatch Queue):让任务一个接着一个地执行(一个任务执行完毕后,再执行下一个任务)
同步和异步主要影响:能不能开启新的线程
- 同步:在当前线程中执行任务,不具备开启新线程的能力
- 异步:在新的线程中执行任务,具备开启新线程的能力
并发和串行主要影响:任务的执行方式
- 并发:多个任务并发(同时)执行
- 串行:一个任务执行完毕后,再执行下一个任务
各种队列的执行效果:
使用sync函数往当前串行队列中添加任务,会卡住当前的串行队列(产生死锁)。
队列组
参见GCD使用概要:Objective-C之GCD概要。
iOS中的线程同步方案
性能从高到低排序:
- os_unfair_lock
- OSSpinLock
- dispatch_semaphore
- pthread_mutex(default)
- dispatch_queue(DISPATCH_QUEUE_SERIAL)
- NSLock
- NSCondition
- pthread_mutex(recursive)
- NSRecursiveLock
- NSConditionLock
- @synchronized
OSSpinLock
OSSpinLock叫做”自旋锁”,等待锁的线程会处于忙等(busy-wait)状态,一直占用着CPU资源。目前已经不再安全,可能会出现优先级反转问题,如果等待锁的线程优先级较高,它会一直占用着CPU资源,优先级低的线程就无法释放锁。
1 2 3 4 5 6 7 8 9 10
| #import <libkern/OSAtomic.h>
// 初始化 OSSpinLock lock = OS_SPINLOCK_INIT; // 尝试加锁,如果需要等待就不加锁直接返回false,否则加锁后返回true bool result = OSSpinLockLock(&lock); // 加锁 OSSpinLockLock(&lock); // 解锁 OSSpinLockUnlock(&lock);
|
os_unfair_lock
os_unfair_lock用于取代不安全的OSSpinLock ,从iOS10开始才支持。从底层调用看,等待os_unfair_lock锁的线程会处于休眠状态,并非忙等。
1 2 3 4 5 6 7 8 9 10
| #import <os/lock.h>
// 初始化 os_unfair_lock lock = OS_UNFAIR_LOCK_INIT; // 尝试加锁 os_unfair_lock_trylock(lock); // 加锁 os_unfair_lock_lock(&lock); // 解锁 os_unfair_lock_unlock(&lock);
|
pthread_mutex
mutex叫做”互斥锁”,等待锁的线程会处于休眠状态。
1 2 3 4 5 6 7 8 9 10 11 12 13
| #import <pthread.h>
// 初始化属性 pthread_mutexattr_t attr; pthread_mutexattr_init(&attr); pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_DEFAULT); // 初始化锁 pthread_mutex_t mutex; pthread_mutex_init(&mutex, &attr); // 销毁属性 pthread_mutexattr_destroy(&attr); // 销毁锁 pthread_mutex_destroy(&mutex);
|
锁的类型有:
1 2 3 4
| #define PTHREAD_MUTEX_NORMAL 0 #define PTHREAD_MUTEX_ERRORCHECK 1 #define PTHREAD_MUTEX_RECURSIVE 2 //递归锁 #define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_NORMAL
|
递归锁:允许同一个线程对一把锁进行重复加锁。
pthread_mutex条件:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
| // 初始化锁 pthread_mutex_t mutex; // NULL表示使用默认属性 pthread_mutex_init(&mutex, NULL); // 初始化条件 pthread_cond_t cond pthread_cond_init(&cond, NULL); // 等待条件(进入休眠,放开mutex锁,被唤醒后会再次对mutex加锁 pthread_cond_wait(&cond, &mutex) // 激活一个等待该条件的线程 pthread_cond_signal(&cond); // 激活所有等待该条件的线程 pthread_cond_broadcast(&cond); // 销毁资源 pthread_mutex_destroy(&mutex); pthread_cond_destroy(&cond);
|
NSLock
NSLock是对mutex普通锁的封装。
核心定义如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
| @protocol NSLocking
- (void)lock; - (void)unlock;
@end
@interface NSLock : NSObject <NSLocking>
- (BOOL)tryLock; - (BOOL)lockBeforeDate:(NSDate *)limit;
@property (nullable, copy) NSString *name;
@end
|
NSRecursiveLock
NSRecursiveLock也是对mutex递归锁的封装,API跟NSLock基本一致。
NSCondition
NSCondition是对mutex和cond的封装。
核心定义如下:
1 2 3 4 5 6 7 8 9
| @interface NSCondition : NSObject <NSLocking> - (void)wait; - (BOOL)waitUntilDate:(NSDate *)limit; - (void)signal; - (void)broadcast;
@property (nullable, copy) NSString *name;
@end
|
NSConditionLock
NSConditionLock是对NSCondition的进一步封装,可以设置具体的条件值。条件值默认为0。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
| @interface NSConditionLock : NSObject <NSLocking>
// 初始化, 同时设置 condition - (instancetype)initWithCondition:(NSInteger)condition;
// condition值 @property (readonly) NSInteger condition;
// 只有NSConditionLock实例中的condition值与传入的condition值相等时, 才能加锁 - (void)lockWhenCondition:(NSInteger)condition; // 尝试加锁 - (BOOL)tryLock; // 尝试加锁, 只有NSConditionLock实例中的condition值与传入的condition值相等时, 才能加锁 - (BOOL)tryLockWhenCondition:(NSInteger)condition; // 解锁, 同时设置NSConditionLock实例中的condition值 - (void)unlockWithCondition:(NSInteger)condition; // 加锁, 如果锁已经使用, 那么一直等到limit为止, 如果过时, 不会加锁 - (BOOL)lockBeforeDate:(NSDate *)limit; // 加锁, 只有NSConditionLock实例中的condition值与传入的condition值相等时, 才能加锁, 时间限制到limit, 超时加锁失败 - (BOOL)lockWhenCondition:(NSInteger)condition beforeDate:(NSDate *)limit; // 锁的name @property (nullable, copy) NSString *name;
@end
|
dispatch_queue
直接使用GCD的串行队列,也是可以实现线程同步的。
1 2 3 4
| dispatch_queue_t queue = dispatch_queue_create("myQueue", DISPATCH_QUEUE_SERIAL); dispatch_sync(queue, ^{ //do something; });
|
dispatch_semaphore
semaphore叫做”信号量”。信号量的初始值,可以用来控制线程并发访问的最大数量。信号量的初始值为1,代表同时只允许1条线程访问资源,保证线程同步。
1 2 3 4 5 6
| // 初始化信号量 dispatch_semaphore_t semaphore = dispatch_semaphore_create(long value) // 计数为0时休眠等待,计数为1或大于1时,减去1而不等待继续执行。 dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER); // 信号量计数器加1 dispatch_semaphore_signal(semaphore);
|
@synchronized
@synchronized是对mutex递归锁的封装。@synchronized(obj)内部会生成obj对应的递归锁,然后进行加锁、解锁操作。
1 2 3
| @synchronized(obj) { //do something }
|
自旋锁、互斥锁比较
什么情况使用自旋锁比较划算?
- 预计线程等待锁的时间很短
- 加锁的代码(临界区)经常被调用,但竞争情况很少发生
- CPU资源不紧张
- 多核处理器
什么情况使用互斥锁比较划算?
- 预计线程等待锁的时间较长
- 单核处理器
- 临界区有IO操作
- 临界区代码复杂或者循环量大
- 临界区竞争非常激烈
atomic
atomic用于保证属性setter、getter的原子性操作,相当于在getter和setter内部加了线程同步的自旋锁。但是它并不能保证使用属性的过程是线程安全的。
可以参考源码objc4的objc-accessors.mm。
iOS中的读写安全
考虑如下场景:
- 同一时间,只能有1个线程进行写的操作
- 同一时间,允许有多个线程进行读的操作
- 同一时间,不允许既有写的操作,又有读的操作
上面的场景就是典型的“多读单写”,经常用于文件等数据的读写操作,iOS中的实现方案有:
- pthread_rwlock:读写锁
- dispatch_barrier_async:异步栅栏调用
pthread_rwlock
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
| // 定义读写锁 pthread_rwlock_t rwlock; // 初始化读写锁 pthread_rwlock_init(&rwlock, NULL); // 读取加锁 pthread_rwlock_rdlock(&rwlock); // 尝试读取加锁 pthread_rwlock_tryrdlock(&rwlock); // 写入加锁 pthread_rwlock_wrlock(&rwlock); // 尝试写入加锁 pthread_rwlock_trywrlock(&rwlock); // 解锁 pthread_rwlock_unlock(&rwlock); // 销毁读写锁 pthread_rwlock_destroy(&rwlock);
|
dispatch_barrier_async
该函数会等到追加到并发队列上的并行处理全部结束之后, 再将指定的处理追加到该并发队列中。 然后在等该函数追加的处理执行完成后, 该并发队列才恢复为一般动作, 开始执行之后追加的并行处理.
该函数传入的并发队列必须通过dispatch_queue_cretate创建。
1 2 3 4 5 6 7 8 9 10 11 12
| dispatch_t queue = dispatch_queue_create("rwQueue", DISPATCH_QUEUE_CONCURRENT)
// 读 dispatch_async(queue, ^{
});
// 写 dispatch_barrier_async(queue, ^{
});
|