iOS之武功秘籍⑭: 锁的原理

2021-03-02  本文已影响0人  長茳

iOS之武功秘籍 文章汇总

写在前面

通过上一篇的学习我们对多线程有了比较深入的了解，在使用多线程的时候，我们为了保证线程安全会使用锁，那么这篇呢.我们就来探究一下锁的使用原理

本节可能用到的秘籍Demo

一、锁

① 锁的性能

借鉴一张锁的性能数据对比图，如下所示

从上图我们可以知道锁的性能从高到底依次为：OSSpinLock(自旋锁) -> dispatch_semaphone（信号量） -> pthread_mutex（互斥锁） -> NSLock（互斥锁） -> NSCondition（条件锁） -> pthread_mutex（recursive 互斥递归锁） -> NSRecursiveLock（递归锁） -> NSConditionLock（条件锁） -> synchronized（互斥锁）

② 锁的归类

结合上图锁大致分为以下几类:

②.1 自旋锁

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

②.2 互斥锁

互斥锁是一种用于多线程编程中，防止两条线程同时对同一公共资源（例如全局变量）进行读写的机制，该目的是通过将代码切成一个个临界区而达成.当获取锁操作失败时，线程会进入睡眠，等待锁释放时被唤醒

②.3 条件锁

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

②.4 递归锁

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

②.5 信号量

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

②.6 读写锁

读写锁实际是一种特殊的自旋锁，它把对共享资源的访问者划分成读者和写者，读者只对共享资源进行读访问，写者则需要对共享资源进行写操作.这种锁相对于自旋锁而言，能提高并发性，因为在多处理器系统中，它允许同时有多个读者来访问共享资源，最大可能的读者数为实际的CPU数

②.7 总结

其实在iOS中锁的基本种类只有两种：互斥锁、自旋锁，其他的比如条件锁、递归锁、信号量都是上层的封装和实现.

二、锁的细说

① OSSpinLock（自旋锁）

自从OSSpinLock出现了安全问题,在iOS10之后就被废弃了.自旋锁之所以不安全，是因为自旋锁由于获取锁时，线程会一直处于忙等待状态，造成了任务的优先级反转.

而OSSpinLock忙等的机制就可能造成高优先级一直running等待，占用CPU时间片；而低优先级任务无法抢占时间片，变成迟迟完不成，不释放锁的情况

在OSSpinLock被弃用后，其替代方案是内部封装了os_unfair_lock，而os_unfair_lock在获取锁操作失败时，线程会进入休眠状态，而不是自旋锁的忙等状态

② atomic（原子锁）

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

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

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

getter方法中对atomic的处理，同setter是大致相同的

atomic只能保证setter、getter方法的线程安全，并不能保证数据安全

如上图所示，被atomic修饰的index变量分别在两次并发异步for循环10000次后输出的结果并不等于20000.由此可以得出结论：

③ @synchronized（互斥递归锁）

@synchronized可能是日常开发中用的比较多的一种互斥锁，因为它的使用比较简单，但并不是在任意场景下都能使用@synchronized，且它的性能较低

接下来就通过源码探索来看一下@synchronized在使用中的注意事项

③.1 objc_sync_enter & objc_sync_exit 分析

打开objc4-818.2源码，搜索objc_sync_enter

在objc4-818.2源码中搜索objc_sync_exit

通过上面两个实现逻辑的对比，发现它们有一个共同点，在obj存在时，都会通过id2data方法，获取SyncData

③.2 SyncData

进入SyncData的定义，是一个结构体，主要用来表示一个线程data，类似于链表结构，有next指向，且封装了recursive_mutex_t属性，可以确认@synchronized确实是一个递归互斥锁

进入SyncCache的定义，也是一个结构体，用于存储线程，其中list[0]表示当前线程的链表data，主要用于存储SyncData和lockCount

③.3 id2data 分析

进入id2data源码，从上面的分析，可以看出，这个方法是加锁和解锁都复用的方法

所以在id2data方法中，主要分为三种情况：

③.4 tls和cache表结构

针对tls和cache缓存，底层的表结构如下所示

③.5 @synchronized 坑点

下面代码这样写，会有什么问题？


运行结果发现，运行就崩溃


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

下面我们验证下，上面代码，做如下图操作，来查看是否存在僵尸对象

我们发现确实出现过度释放，出现野指针.所以我们一般使用@synchronized (self)，主要是因为_testArray的持有者是self

解决方案：

③.6 @synchronized 总结

④ NSLock

④.1 简单实用

NSLock是对下层pthread_mutex的封装，使用如下

直接进入NSLock定义查看，其遵循了NSLocking协议，下面来探索NSLock的底层实现

通过加符号断点lock分析，发现其源码在Foundation框架中

由于OC的Foundation框架不开源，所以这里借助Swift的开源框架Foundation来分析NSLock的底层实现，其原理与OC是大致相同的

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

回到前文的锁性能图中，可以看出NSLock的性能仅次于 pthread_mutex（互斥锁），非常接近

NSLock在AFNetworking的AFURLSessionManager.m中有使用到

④.2 使用弊端

请问下面block嵌套block的代码中，会有什么问题？

其运行结果如下


会出现一直等待的情况，主要是因为嵌套使用的递归，使用NSLock（简单的互斥锁，如果没有回来，会一直睡觉等待），即会存在一直加lock，等不到unlock的堵塞情况

所以，针对这种情况，可以使用以下方式解决

⑤ 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);

pthread_mutex在YYKit中的YYMemoryCache中有所应用

⑥ NSRecursiveLock

NSRecursiveLock在底层也是对pthread_mutex的封装，可以通过swift的Foundation源码查看

对比NSLock 和 NSRecursiveLock，其底层实现几乎一模一样，区别在于init时，NSRecursiveLock有一个标识PTHREAD_MUTEX_RECURSIVE，而NSLock是默认的

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

NSRecursiveLock在YYKit中YYWebImageOperation.m中有用到

⑦ NSCondition

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

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

⑦.1 基本使用

⑦.2 源码分析

通过swift的Foundation源码查看NSCondition的底层实现

其底层也是对下层pthread_mutex的封装

⑧ NSConditionLock

NSConditionLock是条件锁，一旦一个线程获得锁，其他线程一定等待.其本质就是NSCondition + Lock.

相比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时间];

以下是其swift的底层实现

通过源码可以看出

以下面代码为例，调试NSConditionLock底层流程

* 通过汇编可知，`x2`移动到了`x21`![](https://img.haomeiwen.com/i2340353/30d591f3614f3129.jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

到这里后，我们调试的目的主要有两个：NSCondition + lock 以及condition与value的值匹配

**NSCondition + lock验证 **

所以可以验证NSConditionLock在底层调用的是NSCondition的lock方法

condition与value的值匹配

此时是x8 和 x21 是匹配的，通过断点也可以体现

验证总结一下:

⑨ dispatch_semaphore

在iOS之武功秘籍⑬: 多线程原理与GCD和NSOperation篇章已经对信号量进行过讲解

⑩ 总结

三、锁的使用场景

写在后面

和谐学习,不急不躁.我还是我,颜色不一样的烟火.

上一篇 下一篇

猜你喜欢

热点阅读