iOS多线程

发表于 | 分类于 |

iOS中的常见多线程方案

GCD

GCD源码地址:https://github.com/apple/swift-corelibs-libdispatch。

GCD使用概要：Objective-C之GCD概要。

常用函数

GCD中有2个用来执行任务的函数：

  1. 用同步的方式执行任务
1
dispatch_sync(dispatch_queue_t queue, dispatch_block_t block);
  1. 用异步的方式执行任务
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
dispatch_t queue = dispatch_queue_create("rwQueue", DISPATCH_QUEUE_CONCURRENT)

// 读
dispatch_async(queue, ^{

});

// 写
dispatch_barrier_async(queue, ^{

});