前沿：什么叫作多线程安全？
我们在多线程访问共享资源的时候，不会出现意想不到的结果。
我们先来才想一下下面的代码输出结果会是什么？
image.png
是不是49->40顺序输出呢？结果如下
image.png
我们会发现结果有错乱，47后面直接变成45了
有同学可能会想到，因为count是nonatomic修饰的，非原子性导致count是线程不安全的。
那我们把count改成atomic,再来试试结果会是如何吧
image.png
结果同样不尽如人意，证实了一点count对象是线程不安全的。
我们看看苹果系统nonatomic、atomic修饰符都为我们设置属性做了什么操作，查看源码
1、set属性
image.png
2、查看nonatomic、atomic区别
image.png
很明显的可以看出，非原子属性是直接赋值，而原子属性是添加了一个spinlock
再来看看get属性
image.png
既然我们说锁的作用就是保证多线程安全，那为什么count用atomic修饰为什么还是出现了意想不到的结果呢？
看看第一张图的26行代码，self.count--,其实他既有set操作，又有get操作，27行NSLog同样也是进行了一次get操作。而我们的atomic的spinlock的范围太小，只能保证一次的set或者get。所有如果把26、27两行用一个锁包起来就可以保证正常了。
引出iOS的八大锁
平时使用的锁都有哪些，他们的性能优势如何？
image.png
可以看出OSSpinLock的性能最高。
上面的锁又可以分出几种类型出来呢？
1、自旋锁
它是一种忙等的锁，就是说锁的时候就像有一个do while循环，没发继续执行其他的操作。因为忙等就不会出现cpu的调度，就不会出现时间片的消耗，也不会出现线程的创建（创建一个线程大概消耗90微秒），所有他的效率是更高的
2、互斥锁
它是一种闲等，调用者线程会处于一种休眠的状态，cpu可以调度其他的线程
那我们针对上面提到的锁一一进行一个讲解：
1、OSSpinLock
image.png
image.png
但是iOS10，苹果已经废弃了OSSpinLock这把锁，取而代之的是os_unfair_lock。
自旋锁的效率高，苹果还要废弃它，说明它肯定有问题，其实这个OSSpinLock有一个BUG，存在一个优先级反转的BUG（一个优先级低的线程访问了OSSpinLock，又来一个优先级高的线程来访问OSSpinLock，由于优先级高，导致线程一直占用的CPU，导致低优先级的线程无法释放这个OSSpinLock，就出现了优先级反转的BUG。）
如果你想要使用自旋锁，必须要保证锁在同一个优先级下面使用，不然会复现上面的BUG
image.png
使用OSSpinLock的时候记得导入头文件#import <libkern/OSAtomic.h>
2、OS_unfair_lock
image.png
image.png
使用os_unfair_lock的时候需要导入头文件#import<os/lock.h>
它有两个函数比较有意思，一个是线程未持有lock的时候调用该函数会崩溃，还有一个是线程已持有lock的时候调用会崩溃（持有的标准是线程是否加锁该lock）。
3、NSLock
这个就比较简单了，平时用的也比较多
image.png
@protocol NSLocking
- (void)lock;
- (void)unlock;
@end
@interface NSLock : NSObject <NSLocking> {
@private
void *_priv;
}
- (BOOL)tryLock;
- (BOOL)lockBeforeDate:(NSDate *)limit;
@property (nullable, copy) NSString *name API_AVAILABLE(macos(10.5), ios(2.0), watchos(2.0), tvos(9.0));
@end
其实OC的lock都遵循了NSLocking的协议，所有都有相同的function （lock、unlock），也都是基于pthread的一个封装。
NSLock并不是一把递归锁，所以我们不能进行连续加锁，会导致crash。
4、NSCondition
这把锁有一个经典的案例，就是生产和消费的多线程案例
image.png
上面的输出是不是没发满足生产一个商品再去消费一个的目的呢？
image.png
很显然出现了很多负数。
我们可以通过condition的wait和signal来实现这种存在商品再去消费的情况。如下
image.png
当商品为0的时候不消费，等待信息再去消费。这样是不是就不会出现负数呢？？？
image.png
结果并不理想，依然出现了负数。按道理signal只会唤醒一条线程,其实出现上面的原因是系统的一个bug，导致虚假唤醒。相当于NSCondition调用了broadcast，唤醒了所有的线程。
如果需要修复上面的bug，可以调整消费方法
//消费
- (void)consumption_count {
[_condition lock];
while (_count == 0) {
[_condition wait];
}
_count --;
NSLog(@"消费了一个产品，现在的总产品为：%d个",self.count);
[_condition unlock];
}
这样即使所有线程被唤醒，依然会判断count是否等于0，用来让线程依然处于wait状态。就不会出现负数的情况。
网友评论