一、锁的分类

image.png

从上图可以获得：锁的性能排行榜 高到低

OSSpinLock（自旋锁）> dispatch_semaphore（信号量）> pthread_mutex （互斥锁）> NSLock （互斥锁）> NSCondition （条件锁）> pthread_mutex（recursive 互斥递归锁）> NSRecursiveLock（递归锁）> NSConditionLock （条件锁） > @syschronized（互斥锁）

1、 自旋锁

在自旋锁中，线程会反复检查变量是否可用。由于线程这个过程中一致保持执行，所以是一种 忙等待。一旦获取了自旋锁，线程就会一直保持该锁，直到显示释放自旋锁。 自旋锁 避免了进程上下文的调度开销，因此对于线程只会阻塞很短时间的场合 是 有效的。对于 iOS属性的修饰符 atomic，自带一把自旋锁

• OSSPinLock
• atomic

2、互斥锁

一种用于 多线程编程 中，防止两条线同时对同一个公共资源 进行读取的机制 ，该目的是 通过将代码切成一个个 临界区 而达成。

• @synchornized
• NSLock
• pthread_mutex

3、条件锁

条件锁是 条件变量，当进程的某些资源要求不满足时就 进入休眠，即锁住了，当资源被分隔到了，条件锁打开，进程继续进行

• NSCondition
• NSConditionLock

4、递归锁

递归锁 就是 同一个线程 可用加锁N次而不会引发死锁，递归锁就是 特殊的互斥锁，即 带有递归性质的互斥锁

• pthread_mutex(recursive)
• NSRecursiveLock

5、信号量

信号量 是一种 更加高级的同步机制，互斥锁 可以说是 semphore在仅取值0/1时特例，信号量可以有更多的取值空间，用来 实现更加复杂的同步，而不单单是线程间互斥

• dispatch_semaphore

6、读写锁

读写锁实际是一种 特殊的自旋锁。

将共享资源的访问分成 读者 和 写者 ，读者只对共享资源 进行读访问，写者 则需要对共享资源 进行写操作，这种锁 相对于自旋锁而言，能提高并发性

• 一个读写锁同时 只能有一个写者或者 多个读者，但不能既有读者 又有 写者，在读写锁保持期间也是抢占失效的

• 如果读写锁当前没有读者，也没有写者，那么写者 可以立刻获得读写锁，否则它必须自旋 在那里，直到没有任何写者 或者 读者，如果读写锁没有写者，那么读者可以立

其实 基本的锁 主要包括三类：自旋锁 互斥锁 读写锁
其他的如：条件锁、递归锁、信号量 都是上层的封装和实现

1、OSSpinLock 自旋锁

OSSpinLock 在iOS10 之后就被抛弃了，由于出现了安全问题，是因为：获取锁后，线程会一直处于忙等待，造成了 任务的优先级反转

其中的忙等待 机制 可能会造成 高优先级任务一直running 等待，占用时间片，而低优先级额任务无法抢占时间片，会造成一直不能完成，锁未释放的情况

在 OSSpinLock 被弃用后，其替代方案是 内部封装os_unfair_lock, 而 os_unfair_lock 在加锁时会处于 休眠状态，而不是自旋锁额忙等状态。

2、atomic 原子锁

atomic 适用于 OC 中属性的修饰符，其自带一把自旋锁，但是这个一般基本不使用，都使用nonatomic

我们曾经提及 setter 方法 会根据修饰符调用不同方法，其中最后会统一调用 reallySetProperty 方法，其中就有 atomic 和 非atomic 的操作

static inline void reallySetProperty(id self, SEL _cmd, id newValue, ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy)
{
   ...
   id *slot = (id*) ((char*)self + offset);
   ...

    if (!atomic) {//未加锁
        oldValue = *slot;
        *slot = newValue;
    } else {//加锁
        spinlock_t& slotlock = PropertyLocks[slot];
        slotlock.lock();
        oldValue = *slot;
        *slot = newValue;        
        slotlock.unlock();
    }
    ...
}

从源码中 可以看出，对于 atomic 修饰的属性，进行了 spinLock_t 加速处理，但是在前文中 提及到OSSpinLock已经被废弃了，这里的spinLock_t 在底层是通过os_unfair_lock 替代了OSSpinLock 实现的加锁，同时为了防止 哈希冲突，还是用了 加盐 操作。

using spinlock_t = mutex_tt<LOCKDEBUG>;
class mutex_tt : nocopy_t {
    os_unfair_lock mLock;
    ...
}

3、synchronsized （互斥递归锁）

@synchronsized 的坑点

 - (void)testSync{
    _testArray = [NSMutableArray array];
    for (int i = 0; i < 200000; i++) {
        dispatch_async(dispatch_get_global_queue(0, 0), ^{
            @synchronized (self.testArray) {
                self.testArray = [NSMutableArray array];
            }
        });
    }
}

运行结果，会出现崩溃

崩溃主要原因：

testArray 在某一瞬间变成了nil，从 @synchronsized 底层流程知道，如果加锁的对象成了nil ，是锁不住的，相当于下面的这种情况，block 内部不停的retain、release，会在某一瞬间上一个还未release，下一个已经准备release，这样会导致野指针的产生。

_testArray = [NSMutableArray array];
for (int i = 0; i < 200000; i++) {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        _testArray = [NSMutableArray array];
    });
}

我们一般使用 @synchronsized(self),主要因为_testArray的持有者 self

注意：野指针 VS 过度释放

野指针： 是指由于过度释放产生的指针 还在 进行操作
过度释放：每次都会retain 和release

总结一下：

1、@synchronized 在底层封装的是一把递归锁，所以是 递归互斥锁

2、@synchronized 的可重入，即可嵌套 ，主要是由于lockCount 和 threadCount 的搭配

3、@synchronized 使用 链表 的原因是：链表方便下一个data的插入

4、但是 由于底层中链表查询、缓存的查找以及递归，是非常 耗内存以及性能的，导致性能低，所以在前文中，该锁的排名在最后

5、但是目前该锁的使用频率仍然很高，主要是因为 方便简单，且不用解锁

6、不能使用 非OC对象 作为加锁对象，因为其object 的参数为id

7、@synchornied（self） 这种适用于 嵌套次数较少 的场景。这里锁住的对象也 并不永远是self

8、如果锁嵌套次数较多，即 锁self过多，会导致底层的查找非常麻烦，因为其底层是链表进行查找，所以会相对比较麻烦，所以此时 可以使用NSLock、信号量

4、NSLock

NSLock 是对 下层pthread_mutex 的封装

NSLock *lock = [[NSLock alloc] init];
[lock lock];
[lock unlock];

由于OC的Foundation源码不开源，可以通过swfit的开源框架Foundation 来分析NSLock的底层实现。

image.png

通过swift 源码 可以获得：底层是 通过pthread_mutex 互斥实现的，并且在init方法中，还做了一些其他操作，所以 在使用NSLock 时需要使用init 初始化

弊端分析：

for (int i= 0; i<100; i++) {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        static void (^testMethod)(int);
        testMethod = ^(int value){
            if (value > 0) {
              NSLog(@"current value = %d",value);
              testMethod(value - 1);
            }
        };
        testMethod(10);
    });
}  

在未加锁之前，其中的 current = 9、10 有很多条，导致数据混乱（多线程导致的）

image.png

如下加锁之后

NSLock *lock = [[NSLock alloc] init];
for (int i= 0; i<100; i++) {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        static void (^testMethod)(int);
        testMethod = ^(int value){
            [lock lock];
            if (value > 0) {
              NSLog(@"current value = %d",value);
              testMethod(value - 1);
            }
        };
        testMethod(10);
        [lock unlock];
    });
}  

image.png

会出现一直等待的情况，主要是因为嵌套使用的递归，使用 NSLock （简单的互斥锁，如果没有回来，会一直睡觉等待），即会存在一直加Lock，等不到unlock的堵塞情况
所以，针对 这种情况，可以使用以下方式解决：

• @synchronized

for (int i= 0; i<100; i++) {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        static void (^testMethod)(int);
        testMethod = ^(int value){
            @synchronized (self) {
                if (value > 0) {
                  NSLog(@"current value = %d",value);
                  testMethod(value - 1);
                }
            }
        };
        testMethod(10); 
    });
}

或者 递归锁 NSRecursiveLock

NSRecursiveLock *recursiveLock = [[NSRecursiveLock alloc] init];
 for (int i= 0; i<100; i++) {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        static void (^testMethod)(int);
        [recursiveLock lock];
        testMethod = ^(int value){
            if (value > 0) {
              NSLog(@"current value = %d",value);
              testMethod(value - 1);
            }
            [recursiveLock unlock];
        };
        testMethod(10);
    });
}

5、pthread_mutex

pthread_mutex 就是互斥锁本身，当锁被占用，其他线程申请琐时，不会一直忙等待，而是 阻塞线程且睡眠

// 导入头文件
#import <pthread.h>

// 全局声明互斥锁
pthread_mutex_t _lock;

// 初始化互斥锁
pthread_mutex_init(&_lock, NULL);

// 加锁
pthread_mutex_lock(&_lock);
// 这里做需要线程安全操作
// 解锁 
pthread_mutex_unlock(&_lock);

// 释放锁
pthread_mutex_destroy(&_lock);

6、NSRecursiveLock

递归锁 ，NSRecursiveLock 在底层也是对pthread_mutex 的封装

递归锁 主要是用于 解决一种嵌套形式，其中循环嵌套居多

7、NSCondition

NSCondition 是一个条件锁，在日常开发中使用较少，与信号量优点相似，线程1 需要满足条件1 才会网下走，否则会堵塞等待，直到条件满足。经典模式：生成消费者模式

NSCondition 的对象 实际上作为一个锁 和 一个线程检查器

• 锁： 为了 当检测条件保护数据源，执行条件引发的任务
• 线程检查器： 主要是 根据条件决定是否继续运行线程，即线程是否被阻塞

//初始化
NSCondition *condition = [[NSCondition alloc] init]

//一般用于多线程同时访问、修改同一个数据源，保证在同一 时间内数据源只被访问、修改一次，其他线程的命令需要在lock 外等待，只到 unlock ，才可访问
[condition lock];

//与lock 同时使用
[condition unlock];

//让当前线程处于等待状态
[condition wait];

//CPU发信号告诉线程不用在等待，可以继续执行
[condition signal];

分析：

• NSCondition 是对 mutex 和 cond 的一种封装 （cnd 就是 用于 访问和操作特定类型数据的指针）

• wait 操作会 阻塞线程 ，使其进入 休眠状态，直至超时

• signal 操作是唤醒一个 正在休眠等待的线程

• broadcast 会唤醒所有正在等待的线程

8、NSConditionLock

NSConditionLock 是条件锁，一旦一个线程获得锁，其他线程一定等待，相比NSConditionLock 而言，NScondition 使用比较麻烦，推荐使用NSConditionLock，如下：

//初始化
NSConditionLock *conditionLock = [[NSConditionLock alloc] initWithCondition:2];

//表示 conditionLock 期待获得锁，如果没有其他线程获得锁(不需要判断内部的 condition) 那它能执行此行以下代码，如果已经有其他线程获得锁(可能是条件锁，或者无条件 锁)，则等待，直至其他线程解锁
[conditionLock lock]; 

//表示如果没有其他线程获得该锁，但是该锁内部的 condition不等于A条件，它依然不能获得锁，仍然等待。如果内部的condition等于A条件，并且 没有其他线程获得该锁，则进入代码区，同时设置它获得该锁，其他任何线程都将等待它代码的 完成，直至它解锁。
[conditionLock lockWhenCondition:A条件]; 

//表示释放锁，同时把内部的condition设置为A条件
[conditionLock unlockWithCondition:A条件]; 

// 表示如果被锁定(没获得 锁)，并超过该时间则不再阻塞线程。但是注意:返回的值是NO,它没有改变锁的状态，这个函 数的目的在于可以实现两种状态下的处理
return = [conditionLock lockWhenCondition:A条件 beforeDate:A时间];

//其中所谓的condition就是整数，内部通过整数比较条件

锁的使用场景

1、如果只是简单的使用，例如涉及线程安全，使用NSLock 即可

2、如果 是 循环嵌套，推荐使用 @synchornized，主要是因为使用 递归锁 的性能 不如 使用@synchornized的性能 （因为在synchornized中 无论怎么重入，都没有关系,而NSRecuriveLock 可能会出现崩溃）

3、在循环嵌套中，如果对递归锁掌握的很好，则可以使用递归锁，因为性能好

4、如果是循环嵌套，并且还有多线程影响时，例如等待、死锁现象，建议使用@synchornized