原子的(Atomic)
工程师所写的任意一条代码,被编译成汇编代码之后可能不止一条指令(例如++),因此在执行的时候可能执行一半就被调度系统打断,去执行别的代码。这也是多线程会不安全的根本原因。
而我们把单指令的操作称为原子的,因为无论如何,单条指令的执行是不会被打断的。很多体系结构都提供了一些常用操作的原子指令。
广义的同步与锁
为了避免多个线程同时读取一个数据而产生不可预料的后果,我们要将各个线程对同一个数据的访问同步(Synchronization)。所谓同步,即指在一个线程访问数据未结束的时候,其他的线程不得对同一个数据进行访问。如此,对数据的访问被原子化了。
同步的最常见方法是使用锁(Lock)。锁是一种非强制机制,每一个线程在访问数据或资源之前首先试图 获取(Acquire) 锁,并在访问结束之后 释放(Release) 锁。在锁已经被占用的时候试图获取锁时,线程会等待,直到锁重新可用。
1. 二元信号量(Binary Semaphore)
最简单的一种锁,它只有两种状态:占用与非占用。它适合只能被唯一一个线程独占访问的资源。当二院信号量处于非占用状态时,第一个试图获取该二元信号量的线程会获得该锁,并将二元信号量置为占用状态,此后其他的所有试图获取该二元信号量的线程将会等待,直到该锁被释放。
这里的锁释放操作,可由其他线程执行。
2. 多元信号量(简称: 信号量Semaphore)
对于允许多个线程并发访问的资源,它是一个很好的选择。一个初始值为N的信号量允许N个线程并发访问。
线程访问资源的时候首先获取信号量,进行如下操作:
- 将信号量的值减1
- 如果信号量的值小于0,则进入等待状态,否则继续执行
访问完资源之后,线程释放信号量,进行如下操作:
- 将信号量的值加1
- 如果信号量的值小于1,唤醒一个等待中的线程
3. 互斥量(Mutex)
和二元信号量很类似,资源仅同时允许一个线程访问,但和信号量不同的是,信号量在整个系统可以被任意线程获取并释放,也就是说,同一个信号量可以被系统中的一个线程获取之后由另一个线程释放。
而互斥量则要求哪个线程获取了互斥量,哪个线程就要负责释放这个锁,其他的线程越俎代庖去释放互斥量是无效的。
4. 临界区(Critical Section)
是比互斥量更加严格的同步手段。在属于中,把临界区的锁的获取称为进入临界区,而把锁的释放称为离开临界区。临界区和互斥量与信号量的区别在于,互斥量和信号量在系统的任何进程里都是可见的,也就是说,一个进程创建了一个互斥量或信号量,另一个进程试图去获取该锁是合法的。
然而,临界区的作用范围仅限于本进程,其他的进程无法获取该锁。除此之外,临界区具有和互斥量相同的性质。
5. 读写锁(Read-Write Lock)
对于一个读写锁由两种获取方式,共享的(Shared) 或 独占的(Exclusive)。
当锁处于自由的状态时,试图以任何一种方式获取锁都能成功,并将锁置于对应的状态。
如果锁处于共享的状态,其他线程以共享的方式获取锁仍然会成功,此时这个锁分配给了多个线程。然而,如果其他的线程试图以独占的方式获取已经处于共享状态的锁,那么它将必须等待锁被所有的线程释放。
如果锁处于独占的状态,将阻止任何其他线程获取该锁,不论它们试图以那种方式获取。
6. 条件变量(Condition Variable)
作为一个同步手段,作用类似与一个栅栏。对于条件变量,线程可以有两种操作,首先线程可以等待条件变量,一个条件变量可以被多个线程等待。其次,线程可以唤醒条件变量,此时某个或所有等待此条件变量的线程都会被唤醒并继续支持。也就是说,使用条件变量可以让许多线程一起等待某个事件的发生,当事件发生时(条件变量被唤醒),所有的线程可以一起恢复执行。
iOS中的锁
1. NSLock
NSLock实现了最基本的互斥锁,遵循了NSLocking协议,通过lock和unlock来进行锁定和解锁。其使用也非常简单,由于是互斥锁,当一个线程进行访问的时候,该线程获得锁,其他线程进行访问的时候,将被操作系统挂起,直到该线程释放锁,其他线程才能对其进行访问,从而确保了线程安全。但是如果连续锁定两次,则会造成死锁问题。
注意unLock操作必须执行在lock操作所执行的线程,不然可能会造成未知的错误
_lock = [[NSLock alloc] init];
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"1");
[self lockFounction:[NSThread currentThread] num: 1];
});
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"2");
[self lockFounction:[NSThread currentThread] num: 2];
});
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"3");
[self lockFounction:[NSThread currentThread] num: 3];
});
- (void)lockFounction:(NSThread *)thread num:(NSInteger) num {
[_lock lock];
NSLog(@"thread - %@, num - %ld", thread, num);
sleep(5);
[_lock unlock];
}
以下为运行结果,正好每5秒执行一次。

tryLock方法,该方法的返回值描述YES if the lock was acquired, otherwise NO.直译过来是获取锁成功返回YES,否则返回NO。然而它具体做的工作是尝试获取锁,并在成功获取的同时进行lock操作。未成功获取时则什么都不做。,那么是否可以用它替代lock方法,从而避免多次进行锁操作造成死锁的情况呢?答案是否定的。
- (void)lockFounction:(NSThread *)thread num:(NSInteger) num {
[_lock tryLock];
NSLog(@"thread - %@ num - %ld", thread, num);
sleep(5);
[_lock unlock];
}
比如把方法改成这样,然而输出结果却不是之前那样,如下图,这里根本就没有起到上锁的效果。在我的理解是,方法中只有在lock和unlock中间的临界区代码才能得到线程保护,但是你把lock改成tryLock以后,只有第一个进入该方法的线程,才会tryLock成功并等价的执行lock方法,但是对另外的线程根本就没有约束力,因为他们获取不到锁,什么都没有执行。导致临界区的方法直接被执行了,而不会被挂起。

2. NSRecursiveLock
大家都叫它递归锁,它可以允许同一线程多次加锁,而不会造成死锁。递归锁会跟踪它被lock的次数。每次成功的lock都必须有对应的unlock操作。只有达到这种平衡,锁最后才能被释放,以供其它线程使用。下面直接上代码和执行效果。它的tryLock方法,和NSLock是相同的,都是尝试获取锁的意思,这里就不多做说明。
_lock = [[NSRecursiveLock alloc] init];
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"1");
[self lockFounction:[NSThread currentThread] num: 1 count:5];
});
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"2");
[self lockFounction:[NSThread currentThread] num: 2 count:6];
});
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"3");
[self lockFounction:[NSThread currentThread] num: 3 count:7];
});
- (void)lockFounction:(NSThread *)thread num:(NSInteger) num count:(NSInteger)count {
[_lock lock];
NSLog(@"thread - %@ num - %ld, count - %ld", thread, num, count);
if (count != 0) {
count --;
sleep(2);
[self lockFounction:thread num:num count:count];
}
[_lock unlock];
}

3. NSCondition
NSCondition 是一种特殊类型的锁,通过它可以实现不同线程的调度。一个线程被某一个条件所阻塞,直到另一个线程满足该条件从而发送信号给该线程使得该线程可以正确的执行。比如说,你可以开启一个线程下载图片,一个线程处理图片。这样的话,需要处理图片的线程由于没有图片会阻塞,当下载线程下载完成之后,则满足了需要处理图片的线程的需求,这样可以给定一个信号,让处理图片的线程恢复运行。
_ifFinished = NO;
_lock = [[NSCondition alloc] init];
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
sleep(1);
[self downLoad];
});
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[self doSomeThing];
});
- (void)downLoad {
NSLog(@"downLoad begin %@", [NSThread currentThread]);
[_lock lock];
sleep(5);
NSLog(@"downLoad finish");
_ifFinished = YES;
[_lock signal]; //发送信号
[_lock unlock];
}
- (void)doSomeThing {
[_lock lock];
NSLog(@"doSomeThing begin %@", [NSThread currentThread]);
while (!_ifFinished) {
NSLog(@"wait");
[_lock wait]; //等待信号
}
NSLog(@"doSomeThing end %@", [NSThread currentThread]);
[_lock unlock];
}

wait方法的本质是锁的转移,消费者放弃锁,然后生产者获得锁,同理,signal则是一个锁从生产者到消费者转移的过程。- 这里一个
signal信号,只能对应一个wait,如果存在多个wait,只会唤醒第一个。 NSCondition的lock也有互斥效果,但是在执行wait方法放弃锁,线程进行等待的时候,锁的效果将会失效。- 自然我们会有疑问:“如果不用互斥锁,只用条件变量(
wait和signal)会有什么问题呢?”。downLoad方法睡眠的那5秒(即模拟获取数据的过程); 这段代码不是线程安全的,也许在你把数据获取出来以前,已经有别的线程修改了数据。因此我们需要保证消费者拿到的数据是线程安全的。 wait方法除了会被signal方法唤醒,有时还会被虚假唤醒,所以需要这里while循环中的判断来做二次确认。
4. NSConditionLock
NSConditionLock对象所定义的互斥锁可以在某个条件下进行锁定和解锁。它和 NSCondition 很像,但实现方式是不同的。
当两个线程需要特定顺序执行的时候,例如生产者消费者模型,则可以使用 NSConditionLock。当生产者执行任务的时候,可以通过特定的条件获得锁,当生产者完成执行的时候,它将解锁该锁,然后把锁的条件设置成唤醒消费者线程的条件。锁定和解锁的调用可以随意组合。
//condition默认是0
_lock = [[NSConditionLock alloc] initWithCondition:5];
NSTimer * timer1 = [NSTimer timerWithTimeInterval:1 repeats:YES block:^(NSTimer * _Nonnull timer) {
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[self producer];
});
}];
NSTimer * timer2 = [NSTimer timerWithTimeInterval:3 repeats:YES block:^(NSTimer * _Nonnull timer) {
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[self consumer];
});
}];
[[NSRunLoop currentRunLoop] addTimer:timer1 forMode:NSRunLoopCommonModes];
[[NSRunLoop currentRunLoop] addTimer:timer2 forMode:NSRunLoopCommonModes];
- (void)producer {
/**
这里如果直接使用 lockWhenCondition: 方法。
跑几分钟后就会卡死,猜测是因为锁死。具体的原因我没有想明白,如果你想明白了麻烦告诉我。
用tryLock方法,我跑了10几分钟依旧正常运行。
并且注意,只有在tryLock成功的情况下才进行具体的操作。
*/
if ([_lock tryLockWhenCondition:5]) {
NSLog(@"have something %@", [NSThread currentThread]);
_count ++;
[_lock unlockWithCondition:6];
}
}
- (void)consumer {
if ([_lock tryLockWhenCondition:6]) {
NSLog(@"use something %@", [NSThread currentThread]);
_count --;
NSLog(@"%ld", _count);
[_lock unlockWithCondition:5];
}
}

参考链接: