线程与网络-①锁
–
知识架构 iOS知识库
Android知识库
四、线程安全问题
< 返回目录
1、线程安全 当多个线程访问同一块资源时，很容易引发数据错乱和数据安全问题。就好比几个人在同一时修改同一个表格，造成数据的错乱。
参考：iOS中保证线程安全的几种方式与性能对比
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 性能对比 对以上各个锁进行1000000此的加锁解锁的空操作时间如下： OSSpinLock: 46.15 ms dispatch_semaphore: 56.50 ms pthread_mutex: 178.28 ms NSCondition: 193.38 ms NSLock: 175.02 ms pthread_mutex(recursive): 172.56 ms NSRecursiveLock: 157.44 ms NSConditionLock: 490.04 ms @synchronized: 371.17 ms 总的来说： OSSpinLock 自旋锁和 dispatch_semaphore 信号量的效率远远高于其他。 @synchronized和NSConditionLock效率较差。 OSSpinLock 自旋锁原理很简单，就是一直 do while 忙等。它的缺点是当等待时会消耗大量 CPU 资源，所以它不适用于较长时间的任务。 不过最近YY大神在自己的博客不再安全的 OSSpinLock中说明了OSSpinLock已经不再安全，请大家谨慎使用。 dispatch_semaphore 是信号量，但当信号总量设为 1 时也可以当作锁来。相对于 OSSpinLock 来说，它的优势在于等待时不会消耗 CPU 资源。 鉴于OSSpinLock的不安全，所以我们在开发中如果考虑性能的话，建议使用dispatch_semaphore。 如果不考虑性能，只是图个方便的话，那就使用@synchronized。
2、死锁 死锁是指两个或两个以上的进程（线程）在运行过程中因争夺资源而造成的一种僵局（Deadly-Embrace) ) ，若无外力作用，这些进程（线程）都将无法向前推进。
死锁的4个必要条件
一、@synchronized 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 NSObject *obj = [[NSObject alloc] init]; dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ @synchronized(obj) { NSLog(@"需要线程同步的操作1 开始"); sleep(3); NSLog(@"需要线程同步的操作1 结束"); } }); dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ sleep(1); @synchronized(obj) { NSLog(@"需要线程同步的操作2"); } });
@synchronized(obj)指令使用的obj为该锁的唯一标识，只有当标识相同时，才为满足互斥 ，如果线程2中的@synchronized(obj)改为@synchronized(self),刚线程2就不会被阻塞，
二、NSLock 1 2 3 4 5 6 7 8 9 NSLock *lock = [[NSLock alloc] init]; dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ [lock lock]; // 加锁 NSLog(@"需要线程同步的操作1 开始"); sleep(2); NSLog(@"需要线程同步的操作1 结束"); [lock unlock]; // 解锁 });
三、NSRecursiveLock递归锁的使用 我们先写一个典型的死锁情况。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 NSLock *lock = [[NSLock alloc] init]; // 此锁在本代码中会造成死锁 //NSRecursiveLock *lock = [[NSRecursiveLock alloc] init]; //要想下面的递归调用不会造成死锁，只要这里将锁改成递归锁NSRecursiveLock就可以了。NSRecursiveLock递归锁，这个锁可以被同一线程多次请求，而不会引起死锁。这主要是用在循环或递归操作中。 dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ static void (^RecursiveMethod)(int); RecursiveMethod = ^(int value) { [lock lock]; if (value > 0) { NSLog(@"value = %d", value); sleep(2); RecursiveMethod(value - 1); // 此时lock还没解锁，就有执行这个block，而block里又给加了次锁，从而造成了死锁 } [lock unlock]; }; RecursiveMethod(5); });
在是跟你面的代码中，在我们的线程中，RecursiveMethod是递归调用的。所以每次进入这个block时，都会去加一次锁，而从第二次开始，由于锁已经被使用了且没有解锁，所以它需要等待锁被解除，这样就导致了死锁，线程被阻塞住了。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 NSLock *lock = [[NSLock alloc] init]; dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ static void (^RecursiveMethod)(int); RecursiveMethod = ^(int value) { if (value > 0) { NSLog(@"value = %d", value); sleep(2); RecursiveMethod(value - 1); } }; [lock lock]; RecursiveMethod(5); [lock unlock]; });
四、NSCondition & NSConditionLock 条件锁 wait方法是傻等；
waitUntilDate:方法是等一会；
signal是唤起一个在等待的线程。
通过wait()和waitUntilDate(limit: NSDate) -> Bool这两个方法都可以实现线程阻塞即线程睡眠。
不同之处在于
wait()会使线程一直处于休眠状态，直到收到signal()为止；
而waitUntilDate(limit: NSDate) -> Bool在使线程睡眠的同时会设置睡眠的终止时间。
如果在终止时间前收到了signal()就会唤醒线程；signal()，也会直接唤醒线程，而不会像wait()方法那样一直睡眠下去。
1、NSCondition 基本的条件锁，手动的控制。wait
2、NSConditionLock 条件锁 条件锁，这里的条件并不是bool表达式中的条件，而是一个特定的int值。
条件锁，不是简单的加锁/解锁， 而是需要根据一定条件满足后进行 加锁/解锁.
以一个生产中与消费者的例子，介绍条件锁的用法。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 static NSInteger CONDITION_NO_DATA //条件一： 没有数据 static NSInteger CONDITION_HAS_DATA //条件二： 有数据 // 初始化锁时，指定一个默认的条件 NSConditionLock *lock = [[NSConditionLock alloc] initWithCondition:CONDITION_NO_DATA]; //生产者，加锁与解锁的过程 while (YES) { //1. 当满足 【没有数据的条件时】进行加锁 [lock lockWhenCondition:CONDITION_NO_DATA]; //2. 生产者生成数据 //..... //3. 解锁，并设置新的条件，已经有数据了 [locker unlockWithCondition:CONDITION_HAS_DATA]; } //消费者，加锁与解锁的过程 while (YES) { //1. 当满足 【有数据的条件时】进行加锁 [lock lockWhenCondition:CONDITION_HAS_DATA]; //2. 消费者消费数据 //..... //3. 解锁，并设置新的条件，没有数据了 [locker unlockWithCondition:CONDITION_NO_DATA]; }
五、OSSpinLock自旋锁 & os_unfair_lock 由于OSSpinLock不再安全，所以这里我们就直接说一下os_unfair_lock，这个是苹果用于代替OSSpinLock的。效率很高用法很简单如下
1 2 3 4 5 os_unfair_lock_t lock = OS_UNFAIR_LOCK_INIT;os_unfair_lock_lock (&lock);NSLog (@"os_unfair_lock_t" );os_unfair_lock_unlock (&lock);
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 #import "ViewController.h" #import <libkern/OSAtomic.h> @interface ViewController () @property (nonatomic,assign) int ticket; //@property (nonatomic,assign) OSSpinLock lock; @end @implementation ViewController - (void)viewDidLoad { [super viewDidLoad]; // self.lock = OS_SPINLOCK_INIT; self.ticket=50; [self ticketsTest]; // Do any additional setup after loading the view. } -(void)ticketsTest{ // 这里我们开两个线程处理同一件事 dispatch_queue_t queue = dispatch_get_global_queue(0, 0); dispatch_async(queue, ^{ for (int i =0; i<5; i++) { [self saleTicket]; } }); dispatch_async(queue, ^{ for (int i =0; i<5; i++) { [self saleTicket]; } }); } -(void)saleTicket{ //静态创建、则不需要新建属性 static OSSpinLock lock = OS_SPINLOCK_INIT; //若后面是个函数、则需 /* static OSSpinLock lock = nil; static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ lock = OS_SPINLOCK_INIT; }); */ //其他线程执行到这里时，发现锁被加锁了 就会再这排队等待、直到这个锁被打开 //加锁 OSSpinLockLock(&lock); int ticket = self.ticket; sleep(.2); ticket--; self.ticket=ticket; NSLog(@"%d",self.ticket); //解锁 OSSpinLockUnlock(&lock); }
iOS - 互斥锁&&自旋锁 多线程安全隐患 iOS - 互斥锁&&自旋锁 多线程安全隐患
一、多线程安全隐患
资源共享 atomic ：原子属性，为 setter 方法加锁nonatomic ：非原子属性，不会为 setter 方法加锁：线程安全，需要消耗大量的资源 ：非线程安全，适合内存小的移动设备synchronized ：互斥锁atomic ：自旋锁共同点 ：都能保证同一时刻只能有一个线程操作锁住的代码区别 ：互斥锁 ：当上一个线程的任务没有执行完毕的时候（被锁住），那么下一个线程会进入睡眠状态等待任务执行完毕，当上一个线程的任务执行完毕，下一个线程会. 自动唤醒然后执行任务。自旋锁 ：当上一个线程的任务没有执行完毕的时候（被锁住），那么下一个线程会一直等待（不会睡眠），当上一个线程的任务执行完毕，下一个线程会立即执行。自旋锁应用场景 ：比较适合做一些不耗时的操作
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 @synchronized(self) { //线程1进来之后，锁住，2和3都再外面等待 //1、查询剩余的票数 NSUInteger count = self.totalCount; //2、判断是否还有余票 //2.1卖票 //3 、提示客户，没有票了 if (count>0) { [NSThread sleepForTimeInterval:0.1]; self.totalCount = count-1; NSLog(@"%@卖了一张票,还剩%zd票",[NSThread currentThread].name,self.totalCount); } else { NSLog(@"没票了"); break; } } //解锁
四、自旋锁
ObjC 多线程简析（一）-多线程简述和线程锁的基本应用
在iOS10之后apple废弃了OSSpinLock自旋锁，使用os_unfair_lock互斥锁来替代。
在iOS10之后apple已经不再建议使用OSSpinLock自旋锁了，它的替代方案是一个互斥锁，所以一般情况下我们使用互斥锁来解决线程同步的问题才是比较合理的。
1 2 3 4 5 6 7 8 9 10 11 // 初始化OSSpinLock _osspinlock = OS_SPINLOCK_INIT; // 加锁 OSSpinLockLock(&_osspinlock); // 操作数据 // ... // 解锁 OSSpinLockUnlock(&_osspinlock);
1 2 3 4 5 6 7 8 9 10 11 // 初始化os_unfair_lock _osunfairLock = OS_UNFAIR_LOCK_INIT; // 加锁 os_unfair_lock_lock(&(_osunfairLock)); // 操作数据 // ... // 解锁 os_unfair_lock_unlock(&(_osunfairLock));
iOS中的线程同步方案
自旋锁、互斥锁比较:
a, 什么情况使用自旋锁比较划算？
预计线程等待锁的时间很短
加锁的代码（临界区）经常被调用，但竞争情况很少发生
CPU资源不紧张
多核处理器
b,什么情况使用互斥锁比较划算？
预计线程等待锁的时间较长
单核处理器
临界区有IO操作
临界区代码复杂或者循环量大
临界区竞争非常激烈
(4)、自己延伸的问题：什么队列能同时存在同步任务和异步任务？(并发队列) eg：主线程的主队列是串行队列，不可能在该队列上添加同步任务，否则会造成死锁。所以，同时存在同步任务和异步任务的队列应该只能是并发队列。
最终的执行顺序，还是看这些各式各样的任务所在的队列是什么队列，串行的还是并发的。
1、死锁探究：GCD死锁及报错提示(EXC_BAD_INSTRUCTION) (1)、死锁举例：通过串行队列里的任务，往这个串行队列里添加同步任务，会造成死锁 代码如下：
1 2 3 4 5 6 7 8 9 10 11 12 - (IBAction)testDeadlock1:(id)sender { //测试死锁 dispatch_queue_t q1 = dispatch_queue_create("serial_queue_1", DISPATCH_QUEUE_SERIAL); dispatch_async(q1, ^{ NSLog(@"1(属任务①).验证通过串行队列里的任务，往这个串行队列里添加同步任务，会造成死锁%@", [NSThread currentThread]); dispatch_sync(q1, ^{ // 添加的同步任务和外面的任务是同一个串行队列 sleep(2); NSLog(@"2(属任务②).验证通过串行队列里的任务，往这个串行队列里添加同步任务，会造成死锁%@", [NSThread currentThread]); }); NSLog(@"3(属任务①).验证通过串行队列里的任务，往这个串行队列里添加同步任务，会造成死锁%@", [NSThread currentThread]); }); }
(2)、死锁结论：往串行队列里添加的同步任务不能卡住该串行队列，否则会造成死锁(这句话非常重要) (3)、死锁原因分析： 要了解通过串行队列里的任务，往这个串行队列里添加同步任务，会造成死锁 ，或者说往串行队列里添加的同步任务卡住该串行队列的时候会发生死锁 的原因，我们首先需要知道几个概念：
知识点①：创建同步任务的操作，在创建完之后，需要立马执行所创建的同步任务。即创建完同步任务的操作后，只有连其所创建的同步任务也结束了才能继续执行下去；
知识点②：而创建异步任务的操作，在创建完之后，即可继续执行下去，不需要等待所创建的异步任务结束。
附：在线程组的使用中，我们会遇到需要监听多个子线程中的所有任务都结束后，才去执行最后的更新UI的操作。假设最后更新UI的操作，除了需要子线程的任务结束，还需要子线程中的异步线程，如网络请求也结束后，才能更新UI，那么为了不让子线程提前退出，而是等到网络请求也结束后才退出，我们通常会通过使用gcd的enter leave或者信号量来等待。
知识点③：串行队列里的任务是一个执行完，才接着执行下一个；
所以，由以上①②③知识点，我们就能分析出其造成死锁的原因如下：
首先，对于标记1、2、3，先只看是同步任务还是异步任务，而不管是串行队列，还是并行队列，或者说是哪个队列。
从代码上我们很容易看出其是同步任务，所以由以上同步的知识点②，可以知道，最终标记输出的正确顺序应该依次是标记1、标记2、标记3。
即我们的关注点是标记2能否在标记1之后输出。
答，在上述代码中，标记2处的同步任务是被添加到串行队列的，而且还是当前的串行队列。
我们知道串行队列里的任务是一个执行完，才接着执行下一个的，也就是说，往串行队列里添加的任务要执行的条件一定是在所添加的新任务之前的所有任务都已经全部执行完了后，才会执行到这一个的。
这里我们依次往串行队列里添加了第一个任务块和第二个任务块。
要完成第一个任务块需要同时完成任务1+第二个任务块2+任务3。
第二个任务块要执行，根据串行队列的性质，我们知道第二个任务块要等待第一个任务块结束才会执行。（如果两个任务即使都是添加到串行队列，但是他们是不同串行队列的时候就不会需要等待）
由此死锁。
显然这里任务②需要等到任务①真正完成，而任务①的真正完成需要等任务②完成，这样的一个互相等待也就构成了一个死锁，导致我们** EXC_BAD_INSTRUCTION**的崩溃了。
那么以上死锁的问题，怎么解决呢？
答：其实只要解决标记2即任务②，可以在标记1执行之后执行就可以了。
1 2 3 4 5 6 7 8 9 10 11 12 13 - (IBAction)testDeadlock2:(id)sender { //测试死锁 dispatch_queue_t q1 = dispatch_queue_create("serial_queue_1", DISPATCH_QUEUE_SERIAL); dispatch_async(q1, ^{ NSLog(@"1(属任务①).验证通过串行队列里的任务，往其他串行队列里添加同步任务，不会造成死锁%@", [NSThread currentThread]); dispatch_queue_t q2 = dispatch_queue_create("serial_queue_2", DISPATCH_QUEUE_SERIAL); dispatch_sync(q2, ^{ sleep(2); NSLog(@"2(属任务②).验证通过串行队列里的任务，往其他串行队列里添加同步任务，不会造成死锁%@", [NSThread currentThread]); }); NSLog(@"3(属任务①).验证通过串行队列里的任务，往其他串行队列里添加同步任务，不会造成死锁%@", [NSThread currentThread]); }); }
2、主队列中的死锁：在主队列开启同步任务，一定为什么会阻塞线程(看同步任务是不是加在主队列里去了)？ 回答本问题前，我们需要先了解的知识点是：
知识点①：主线程和主队列的关系：
主队列是主线程中的一个串行队列。每一个应用程序只有唯一的一个主队列用来update UI。所有的和UI的操作(刷新或者点击按钮)都必须在主线程中的主队列中去执行，否则无法更新UI。
因为主线程是一个串行队列，所以往主队列里添加同步任务 （如果不是往主队列添加同步任务就不会）是很有可能 发生死锁卡死的。如以下代码就会发生死锁。代码如下：
1 2 3 4 5 6 7 8 9 10 - (void)viewDidLoad { [super viewDidLoad]; NSLog(@"打印1"); dispatch_sync(dispatch_get_main_queue(), ^{ NSLog(@"打印2"); }); NSLog(@"打印3"); }
由引述，我们已经知道往串行队列里添加的同步任务，如果卡住的是该串行队列，则会发生死锁 ，所以显然即执行往这个串行队列里添加同步任务的该任务也是在这个串行队列里的话，那么由于相互等待会造成死锁。
最简单的解决方法：将sync同步方法，替换成异步方法
1 2 3 4 5 6 7 8 9 10 11 12 - (void)viewDidLoad { [super viewDidLoad]; NSLog(@"标记1"); dispatch_async(dispatch_get_main_queue(), ^{ NSLog(@"标记3"); }); NSLog(@"标记5"); } //输出结果为 标记1、标记5、标记3
其他修改方法：将同步任务卡住的队列改成并发队列。如：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 - (void)testDeadLock { NSLog(@"标记1"); dispatch_queue_t other_queue = dispatch_queue_create("other_queue", DISPATCH_QUEUE_SERIAL);//不管是串行队列还是并发队列，都能解决这个死锁问题，因为它同步方法没有卡住这个other_queue。 dispatch_async(other_queue, ^{ NSLog(@"标记2"); dispatch_sync(dispatch_get_main_queue(), ^{ NSLog(@"标记3"); }); NSLog(@"标记4"); }); sleep(2); NSLog(@"标记5"); } //输出结果为 标记1、标记2、标记5、标记3、标记4。
有了这些基础，你再看以下文章中的例子时，就能轻松判断是否会造成死锁了 。
iOS中自旋锁与互斥锁的区别 自旋锁（spinlock） ：是指当一个线程在获取锁的时候，如果锁已经被其它线程获取，那么该线程将循环等待，然后不断的判断锁是否能够被成功获取，直到获取到锁才会退出循环。（附：获取锁的线程一直处于活跃状态，但是并没有执行任何有效的任务，使用这种锁会造成busy-waiting。自旋锁不会使线程状态发生切换，一直处于用户态，即线程一直都是active活跃状态的；不会使线程进入阻塞状态，减少了不必要的上下文切换，执行速度快）
其他参考文章：iOS中自旋锁与互斥锁的区别
pthread_mutex 表示互斥锁。互斥锁可以传入不同参数，实现递归锁pthread_mutex(recursive)。
NSLock，NSCondition，NSRecursiveLock，NSConditionLock都是内部封装的pthread_mutex，即都属于互斥锁。@synchronized是NSLock的一种封装，牺牲了效率，简洁了语法。
OSSpinLock 表示自旋锁，从上图可以看到自旋锁的效率最高，但是现在的iOS因为优先级反转的问题，已经不安全，所以推荐使用pthread_mutex或者dispatch_semaphore。
总结 ：
优缺点 ：