前沿：什么叫作多线程安全？

我们在多线程访问共享资源的时候，不会出现意想不到的结果。

我们先来才想一下下面的代码输出结果会是什么？

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

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状态。就不会出现负数的情况。