一、前言
继续我们上篇《iOS 多线程总结（上）》，继续总结多线程的其他知识点，希望帮助到更多伙伴。这篇主要总结一下线程同步方案，atomic 以及读写安全方案。
二、iOS 中的线程同步方案
-
线程同步的意思就是让多线程的操作按顺序执行。
方案有如下10 种：
自旋锁
os_unfair_lock 自旋锁的替代品
pthread_mutex
dispatch_semaphore 信号量
dispatch_queue(DISPATCH_QUEUE_SERIAL)串行队列
条件锁
多个线程修改某个方法中同一个变量时，要用全局变量的锁，每个线程执行到这个方法时，会判断这个锁是否被加锁了，如果被加锁了则会等待锁被解锁再继续执行，所以必须使用全局变量的锁。
如果只在一个方法里使用了这把锁，也可以做成 static 类型的，这样也可以达到只初始化一次的效果。
1、OSSpinLock （自旋锁）
-
叫做”自旋锁“，等待锁的线程会处于忙等（busy-wait）状态，一直占用着 CPU 资源。
- 目前已经不再安全，可能出现优先级反转问题。
- 需要导入头文件
<libkern/OSAtomic.h>
让线程停止有两种方法：
1、一直 while 判断等待，忙等；
2、sleep 休眠的方式；
- 如果等待锁的线程优先级较高，它会一直占用着 CPU 资源，优先级低的线程就无法释放。
例子：
有两个线程，
thread1：优先级比较高
thread2：优先级比较低
如果优先级比较低的 thread2 先进了方法给锁进行了加锁，紧接着优先级比较高的 thread1 也进来这个方法了，发现这个锁已经被被人加过了，thread1 只能忙等，由于 thread1 的优先级比较高，cpu 就有可能一直在分配时间给 thread1，cpu 就没有时间再分配给 thread2 了，这时 thread2 的代码就没办法继续执行，就永远无法解锁，thread1 就会一直在等，类似于死锁了的感觉了。所以自旋锁有可能会有这种问题。
如果采用休眠的方式的锁，则不会产生这个问题。
2、os_unfair_lock（互斥锁）
当我们使用 OSSpinLock 时，现在会报下面这个警告：
- 从 iOS10 开始，苹果希望我们使用
os_unfair_lock来代替OSSpinLock。 - 从底层调用看，等待
os_unfair_lock锁的线程会处于休眠状态，并非忙等。 - 需要导入头文件
<os/lock.h>
从苹果的注释可以看到，这是个Low-level lock（简称ll lock 或lll），低级锁，低级锁特点就是等不到锁就休眠。
3、pthread_mutex 普通锁
-
mutex 叫做”互斥锁“，等待锁的线程会处于休眠状态
pthread 开头的一般都是跨平台使用的锁。 - 需要导入
<pthread.h>
属性默认是 PTHREAD_MUTEX_NORMAL，属性传空时也是这个默认的。
当属性传 PTHREAD_MUTEX_RECURSIVE 时，是递归锁。
递归锁：
允许对一把锁进行重复加锁。
- 自旋锁原理
执行断点的时候，控制台输入step是一行一行 OC 代码执行（默认），如果输入stepi（缩写si也行），就是一行一行汇编指令执行。
nexti也是一行一行汇编执行，区别是遇到函数callq的时候，会一笔带过，不会进入函数。而 stepi 会进入函数。输入continue（缩写c也行）可以直接到下一个你打的断点。
输入完指令，输入回车即可。
在多个线程使用 OSSpinLock 自旋锁时，可以看到汇编代码一直在执行 0x111126a32 到 0x111126a41 这段代码，0x111126a43 的jne是jump判断，如果符合条件，则跳转到0x111126a32，这就是一个 while 循环，在忙等。
4、pthread_mutex - 递归锁
5、pthread_mutex - 条件锁
例子：
对一个数组的删除和添加操作分别在两个子线程，但是删除数组元素之前，我们需要先添加元素。
@interface NSConditionDemo()
@property (strong, nonatomic) NSCondition *condition;
@property (strong, nonatomic) NSMutableArray *data;
@end
@implementation NSConditionDemo
- (instancetype)init {
if (self = [super init]) {
self.condition = [[NSCondition alloc] init];
self.data = [NSMutableArray array];
}
return self;
}
- (void)otherTest {
[[[NSThread alloc] initWithTarget:self selector:@selector(__remove) object:nil] start];
[[[NSThread alloc] initWithTarget:self selector:@selector(__add) object:nil] start];
}
// 生产者-消费者模式
// 线程1
// 删除数组中的元素
- (void)__remove {
[self.condition lock];
NSLog(@"__remove - begin");
if (self.data.count == 0) {
// 等待
[self.condition wait];
}
[self.data removeLastObject];
NSLog(@"删除了元素");
[self.condition unlock];
}
// 线程2
// 往数组中添加元素
- (void)__add {
[self.condition lock];
sleep(1);
[self.data addObject:@"Test"];
NSLog(@"添加了元素");
// 信号
[self.condition signal];
// 广播
// [self.condition broadcast];
[self.condition unlock];
}
使用场景：
多线程之间的依赖问题。比如线程1依赖线程2做一些事情，再回到线程1做事情。
5、NSLock、NSRecursiveLock
是对 C 语言mutex 普通锁的 OC 版本的封装。就是对 pthread_mutex 的属性传
PTHREAD_MUTEX_NORMAL 时的封装。
tryLock 是尝试加锁，并且不阻塞。
lockBeforeDate 是如果在某个时间前可以加锁成功，则加锁并返回YES，否则返回NO，阻塞。
NSRecursiveLock 也是对 mutex 递归锁的OC版本的封装，API 跟 NSLock 基本一致。
所以 mutex 和 NSLock 的性能其实是一样的，只不过 NSLock 是面向对象的而已。
6、NSCondition 条件锁
是对 C 语言的 pthread_mutex_t 和 pthread_cond_t 的 OC 面向对象的封装，既包含了锁，也包含了条件。
7、NSConditionLock 条件锁
是对 NSCondition 的进一步封装，可以设置具体的条件值。
@interface NSConditionLockDemo()
@property (strong, nonatomic) NSConditionLock *conditionLock;
@end
@implementation NSConditionLockDemo
- (instancetype)init {
if (self = [super init]) {
self.conditionLock = [[NSConditionLock alloc] initWithCondition:1];
}
return self;
}
- (void)otherTest {
[[[NSThread alloc] initWithTarget:self selector:@selector(__one) object:nil] start];
[[[NSThread alloc] initWithTarget:self selector:@selector(__two) object:nil] start];
[[[NSThread alloc] initWithTarget:self selector:@selector(__three) object:nil] start];
}
- (void)__one {
[self.conditionLock lock];
NSLog(@"__one");
sleep(1);
[self.conditionLock unlockWithCondition:2];
}
- (void)__two {
[self.conditionLock lockWhenCondition:2];
NSLog(@"__two");
sleep(1);
[self.conditionLock unlockWithCondition:3];
}
- (void)__three {
[self.conditionLock lockWhenCondition:3];
NSLog(@"__three");
[self.conditionLock unlock];
}
上面代码就是 __three 依赖于__two，__two 依赖于__one。
所以当我们希望不同子线程之间是有顺序的时候，也可以用条件锁实现。
8、dispatch_queue(DISPATCH_QUEUE_SERIAL) 串行队列
直接使用 GCD 的串行队列，也是可以实现线程同步的。
例子：
@interface SerialQueueDemo()
@property (strong, nonatomic) dispatch_queue_t ticketQueue;
@property (strong, nonatomic) dispatch_queue_t moneyQueue;
@end
@implementation SerialQueueDemo
- (instancetype)init {
if (self = [super init]) {
self.ticketQueue = dispatch_queue_create("ticketQueue", DISPATCH_QUEUE_SERIAL);
self.moneyQueue = dispatch_queue_create("moneyQueue", DISPATCH_QUEUE_SERIAL);
}
return self;
}
- (void)__drawMoney {
dispatch_sync(self.moneyQueue, ^{
[super __drawMoney];
});
}
- (void)__saveMoney {
dispatch_sync(self.moneyQueue, ^{
[super __saveMoney];
});
}
- (void)__saleTicket {
dispatch_sync(self.ticketQueue, ^{
[super __saleTicket];
});
}
9、dispatch_semaphore
-
叫做”信号量“；
- 信号量的初始值，可以用来控制线程并发访问的最大数量；
-
信号量的初始值为1，代表同时只允许1条线程访问资源，保证线程同步。
所以我们可以把线程最大并发数设置为1，这样就可以达到线程同步的目的了。
10、@synchronized
-
是对 mutex 递归锁的封装。
从代码简洁度讲，是最简单的一种方案。但我们在xcode敲这个关键字的时候是没有自动提示的，因为苹果不推荐我们使用它，因为它的性能比较差。 - 源码查看：objc4 中的 objc-sync.mm 文件
底层是一个哈希表，根据传进去的对象作为key，找到封装的mutex的唯一对应的一把锁，大括号开始时是加锁，大括号结束时解锁。
- (void)__drawMoney {
@synchronized([self class]) {
[super __drawMoney];
}
}
- (void)__saveMoney {
@synchronized([self class]) { // objc_sync_enter
[super __saveMoney];
} // objc_sync_exit
}
- (void)__saleTicket {
static NSObject *lock;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
lock = [[NSObject alloc] init];
});
@synchronized(lock) {
[super __saleTicket];
}
}
- (void)otherTest {
@synchronized([self class]) {
NSLog(@"123");
[self otherTest];
}
}
iOS 线程同步方案性能比较
- 性能从高到低排序
os_unfair_lock—— iOS10 以后才可以用
OSSpinLock——已经不推荐使用
dispatch_semaphore——信号量
pthread_mutex
dispatch_queue(DISPATCH_QUEUE_SERIAL)——串行队列
NSLock——对 pthread_mutex 的封装
NSCondition——条件
pthread_mutex(recursive)——递归锁
NSRecursiveLock——递归锁，对 pthread_mutex(recursive) 的封装
NSConditionLock——条件锁
@synchronized——性能最差，但代码最简洁
所以最推荐dispatch_semaphore和pthread_mutex。
💡小技巧：
使用信号量的时候，如果我们 3 个方法需要用不同的锁，那么我们除了可以在外面定义三个不同的锁属性，还可以在每个方法内部定义静态的锁，这样就能保证一个方法一个锁了。
static dispatch_semaphore_t semaphore;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
semaphore = dispatch_semaphore_create(1);
});
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
// ... 要加锁的代码...
dispatch_semaphore_signal(semaphore);
- (void)test1 {
SemaphoreBegin;
// .....要加锁的代码...
SemaphoreEnd;
}
- (void)test2 {
SemaphoreBegin;
// .....要加锁的代码...
SemaphoreEnd;
}
- (void)test3 {
SemaphoreBegin;
// .....要加锁的代码...
SemaphoreEnd;
}
什么情况使用自旋锁比较划算？
1、预计线程等待锁的时间段；
2、加锁的代码（临界区）经常被调用，但竞争情况很少发生；
3、CPU资源不紧张；
4、多核处理器；什么情况使用互斥锁比较划算？
1、预计线程等待锁的时间较长；
2、单核处理器；
3、临界区有IO操作；
4、临界区代码复杂或者循环量大；
5、临界区竞争非常激烈（很多线程抢占资源）；
但在 iOS 里不考虑使用自旋锁了，只用互斥锁即可。
三、 atomic
nonatomic 和 atomic
atom：原子，不可再分割的单位
atomic：原子性
给属性加上 atomic 修饰，可以保证属性的 setter 和 getter 都是原子性操作，也就是保证 setter 和 getter 内部是线程安全的。
可以通过 objc4 源码中的 objc-accessors.mm 查看，objc_getProperty 和 reallySetProperty。
在reallySetProperty 中：
objc_getProperty中：
- atomic 用于保证属性 setter、getter 的原子性操作，相当于在 getter 和 setter 内部加了线程同步的锁。
- 它不能保证使用属性的过程是线程安全的。
iOS 由于性能问题，一般不使用 atomic，在 mac OS 使用会更多些。
四、iOS 中的读写安全方案
如果实现以下场景：
- 同一时间，只能有1个线程进行写的操作
- 同一时间，允许有多个线程进行读的操作
- 同一时间，不允许既有写的操作，又有读的操作
上面的场景就是典型的”多读单写“，经常用于文件等数据的读写操作，iOS中的实现方案有：
pthread_rwlock：读写锁
dispatch_barrier_async：异步栅栏调用
pthread_rwlock
-
等待锁的线程会进入休眠
dispatch_barrier_async
- 这个函数传入的并发队列必须是自己通过
dispatch_queue_cretate创建的 - 如果传入的是一个串行或是一个全局的并发队列，那这个函数便等同于
dispatch_async函数的效果
以上的总结参考了并部分摘抄了以下文章，非常感谢以下作者的分享！：
小马哥-李明杰的《多线程》课程
转载请备注原文出处，不得用于商业传播——凡几多
