iOS之武功秘籍 文章汇总
写在前面
通过上一篇的学习我们对多线程有了比较深入的了解，在使用多线程的时候，我们为了保证线程安全会使用锁，那么这篇呢.我们就来探究一下锁的使用原理
本节可能用到的秘籍Demo
一、锁
① 锁的性能
借鉴一张锁的性能数据对比图，如下所示从上图我们可以知道锁的性能从高到底依次为：OSSpinLock(自旋锁) -> dispatch_semaphone（信号量） -> pthread_mutex（互斥锁） -> NSLock（互斥锁） -> NSCondition（条件锁） -> pthread_mutex（recursive 互斥递归锁） -> NSRecursiveLock（递归锁） -> NSConditionLock（条件锁） -> synchronized（互斥锁）
② 锁的归类
结合上图锁大致分为以下几类:
②.1 自旋锁
在自旋锁中，线程会反复检查变量是否可用.由于线程在这个过程中一致保持执行，所以是一种忙等待. 一旦获取了自旋锁，线程就会一直保持该锁，直到显式释放自旋锁.自旋锁避免了进程上下文的调度开销，因此对于线程只会阻塞很短时间的场合是有效的.对于iOS属性的修饰符atomic，它自带一把自旋锁.
OSSpinLockatomic
②.2 互斥锁
互斥锁是一种用于多线程编程中，防止两条线程同时对同一公共资源（例如全局变量）进行读写的机制，该目的是通过将代码切成一个个临界区而达成.当获取锁操作失败时，线程会进入睡眠，等待锁释放时被唤醒
pthread_mutexNSLock@synchronized
②.3 条件锁
条件锁就是条件变量，当进程的某些资源要求不满足时就进入休眠，即锁住了，当资源被分配到了，条件锁打开了，进程继续运行
NSConditionNSConditionLock
②.4 递归锁
递归锁就是同一个线程可以加锁N次而不会引发死锁.递归锁是特殊的互斥锁，即是带有递归性质的互斥锁
pthread_mutex(recursive)NSRecursiveLock
②.5 信号量
信号量是一种更高级的同步机制，互斥锁可以说是semaphore在仅取值0/1时的特例，信号量可以有更多的取值空间，用来实现更加复杂的同步，而不单单是线程间互斥
dispatch_semaphore
②.6 读写锁
读写锁实际是一种特殊的自旋锁，它把对共享资源的访问者划分成读者和写者，读者只对共享资源进行读访问，写者则需要对共享资源进行写操作.这种锁相对于自旋锁而言，能提高并发性，因为在多处理器系统中，它允许同时有多个读者来访问共享资源，最大可能的读者数为实际的CPU数
- 写者是排他性的，⼀个读写锁同时只能有⼀个写者或多个读者（与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.由此可以得出结论：
-
atomic保证变量在取值和赋值时的线程安全 - 但不能保证
self.index+1也是安全的 - 如果改成
self.index=i是能保证setter方法的线程安全的
③ @synchronized（互斥递归锁）
@synchronized可能是日常开发中用的比较多的一种互斥锁，因为它的使用比较简单，但并不是在任意场景下都能使用@synchronized，且它的性能较低
接下来就通过源码探索来看一下@synchronized在使用中的注意事项
- 通过
汇编能发现@synchronized就是实现了objc_sync_enter和objc_sync_exit两个方法
- 通过
clang也能得到一些信息：
- 通过加
objc_sync_enter符号断点，查看底层所在的源码库，通过断点发现在objc源码中，即libobjc.A.dylib
③.1 objc_sync_enter & objc_sync_exit 分析
打开objc4-818.2源码，搜索objc_sync_enter
- 如果
obj存在，则通过id2data方法获取相应的SyncData，对threadCount、lockCount进行递增操作 - 如果
obj不存在，则调用objc_sync_nil，通过符号断点得知，这个方法里面什么都没做，直接return了
在objc4-818.2源码中搜索objc_sync_exit
- 如果
obj存在，则调用id2data方法获取对应的SyncData，对threadCount、lockCount进行递减操作 - 如果
obj为nil，什么也不做
通过上面两个实现逻辑的对比，发现它们有一个共同点，在obj存在时，都会通过id2data方法，获取SyncData
③.2 SyncData
进入SyncData的定义，是一个结构体，主要用来表示一个线程data，类似于链表结构，有next指向，且封装了recursive_mutex_t属性，可以确认@synchronized确实是一个递归互斥锁
进入SyncCache的定义，也是一个结构体，用于存储线程，其中list[0]表示当前线程的链表data，主要用于存储SyncData和lockCount
③.3 id2data 分析
进入id2data源码，从上面的分析，可以看出，这个方法是加锁和解锁都复用的方法
- 1.首先在
tls即线程缓存中查找- 在
tls_get_direct方法中以线程为key，通过KVC的方式获取与之绑定的SyncData，即线程data.其中的tls（），表示本地局部的线程缓存. - 判断
获取的data是否存在，以及判断data中是否能找到对应的object. - 如果都找到了，在
tls_get_direct方法中以KVC的方式获取lockCount，用来记录对象被锁了几次（即锁的嵌套次数）. - 如果
data中的threadCount小于等于0，或者lockCount小于等于0时，则直接崩溃. - 通过传入的
why，判断操作类型- 如果是
ACQUIRE，表示加锁，则进行lockCount++，并保存到tls缓存. - 如果是
RELEASE，表示释放，则进行lockCount--，并保存到tls缓存.如果lockCount等于0，从tls中移除线程data. - 如果是
CHECK，则什么也不做.
- 如果是
- 在
- 2.如果
tls中没有，则在cache缓存中查找。- 通过
fetch_cache方法查找cache缓存中是否有线程 - 如果有，则遍历
cache总表，读取出线程对应的SyncCacheItem - 从
SyncCacheItem中取出data，然后后续步骤与tls的匹配是一致的
- 通过
- 3.如果
cache中也没有，即第一次进来，则创建SyncData，并存储到相应缓存中- 如果在
cache中找到线程，且与object相等，则进行赋值、以及threadCount++ - 如果在
cache中没有找到，则threadCount等于1
- 如果在
所以在id2data方法中，主要分为三种情况：
- 1.第一次进来，没有锁
threadCount = 1lockCount = 1- 存储到
tls
- 2.不是第一次进来，且是同一个线程
-
tls中有数据，则lockCount++ - 存储到
tls
-
- 3.不是第一次进来，且是不同线程
-
全局线程空间进行查找线程 threadCount++lockCount++- 存储到
cache
-
③.4 tls和cache表结构
针对tls和cache缓存，底层的表结构如下所示
-
哈希表结构中通过SyncList结构来组装多线程的情况 -
SyncData通过链表的形式组装,记录当前可重入的情况 - 下层通过
tls线程缓存、cache缓存来进行处理 - 底层主要有两个东西：
lockCount、threadCount,解决了递归互斥锁，解决了嵌套可重入
③.5 @synchronized 坑点
下面代码这样写，会有什么问题？
运行结果发现，运行就崩溃
崩溃的主要原因是testArray在某一瞬间变成了nil，从@synchronized底层流程知道，如果加锁的对象成了nil，是锁不住的，相当于下面这种情况，block内部不停的retain、release，会在某一瞬间上一个还未release，下一个已经准备release，这样会导致野指针的产生
我们发现确实出现过度释放，出现野指针.所以我们一般使用@synchronized (self)，主要是因为_testArray的持有者是self
- 过度释放：对象已经不存在了，还进行
release，即多次release - 野指针：
指针指向的对象已经被回收掉了，这个指针就叫做野指针.
解决方案：
- 对
self进行同步锁，这个似乎太臃肿了 - 使用
NSLock
③.6 @synchronized 总结
-
@synchronized在底层封装的是一把递归锁，所以这个锁是递归互斥锁 -
@synchronized的可重入，即可嵌套，主要是由于lockCount和threadCount的搭配 -
@synchronized使用链表的原因是链表方便下一个data的插入 - 但是由于
底层中链表查询、缓存的查找以及递归，是非常耗内存以及性能的，导致性能低，所以在前文中，该锁的排名在最后 - 但是目前该锁的使用频率仍然很高，主要是因为
方便简单，且不用解锁 - 不能使用
非OC对象作为加锁对象，因为其object的参数为id -
@synchronized (self)这种适用于嵌套次数较少的场景.这里锁住的对象也并不永远是self，这里需要读者注意 - 如果
锁嵌套次数较多，即锁self过多，会导致底层的查找非常耗时，因为其底层是链表进行查找，所以性能较差，此时可以使用NSLock、信号量等
④ 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的代码中，会有什么问题？
- 在未加锁之前，其中的
current=9、10有很多条，导致数据混乱，主要原因是多线程导致的
-
如果像下面这样加锁，会有什么问题？
其运行结果如下
会出现一直等待的情况，主要是因为嵌套使用的递归，使用NSLock（简单的互斥锁，如果没有回来，会一直睡觉等待），即会存在一直加lock，等不到unlock的堵塞情况
所以，针对这种情况，可以使用以下方式解决
- 移动加锁位置
- 使用
@synchronized
- 使用递归锁
NSRecursiveLock
⑤ pthread_mutex
pthread_mutex就是互斥锁本身 —— 当锁被占用，而其他线程申请锁时，不是使用忙等，而是阻塞线程并睡眠
使用如下：
// 导入头文件
#import
// 全局声明互斥锁
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的封装
-
NSCondition是对mutex和cond的一种封装（cond就是用于访问和操作特定类型数据的指针） -
wait操作会阻塞线程，使其进入休眠状态，直至超时 -
signal操作是唤醒一个正在休眠等待的线程 -
broadcast会唤醒所有正在等待的线程
⑧ 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是NSCondition的封装 -
NSConditionLock可以设置锁条件，即condition值，而NSCondition只是信号的通知
以下面代码为例，调试NSConditionLock底层流程
- 在
conditionLock部分打上相应断点，运行（需要在真机上运行：模拟器上运行的是Intel指令，而真机上运行的是arm指令）,开启汇编调式
-
register read读取寄存器，其中x0是接收者self，x1是cmd
- 在
objc_msgSend处加断点，再次读寄存器 x0 --register read x0，此时执行到了[conditionLock lockWhenCondition:2];
- 读
x1，即register read x1,然后发现读不出来，因为x1存储的是sel，并不是对象类型，可以通过进行强转为SEL读取
- 加符号断点
-[NSConditionLock lockWhenCondition:]、-[NSConditionLock lockWhenCondition:beforeDate:],然后查看bl、b等跳转- 读取寄存器 x0、x2是当前的
lockWhenCondition:beforeDate:的参数，实际走的是[conditionLock lockWhenCondition:1];
- 读取寄存器 x0、x2是当前的
* 通过汇编可知，`x2`移动到了`x21`
到这里后，我们调试的目的主要有两个：NSCondition + lock 以及condition与value的值匹配
**NSCondition + lock验证 **
- 继续执行，在
bl处断住，读取寄存器x0，此时是跳转至NSCondition
- 读取
x1，即po (SEL)0x00000001e6e0a271
所以可以验证NSConditionLock在底层调用的是NSCondition的lock方法
condition与value的值匹配
- 继续执行，跳到
ldr，即通过一个方法，拿到了condition 2的属性值，存储到x8中register read x19-
po (SEL)0x0000000281d376d0-- x19的地址+0x10
-
register read x8，此时的x8中存储的是2
-
cmp x8, x21，意思是将x8和x21匹配，即2和1匹配，并不匹配
- 第二次来到
cmp x8, x21，此时的x8、x21是匹配的 ，即[conditionLock lockWhenCondition:2];
此时是x8 和 x21 是匹配的，通过断点也可以体现
验证总结一下:
-
线程 1调用[NSConditionLock lockWhenCondition:]，此时此刻因为不满足当前条件，所以会进入waiting状态，当前进入到waiting时，会释放当前的互斥锁. - 此时当前的
线程 3调用[NSConditionLock lock:]，本质上是调用[NSConditionLock lockBeforeDate:]，这里不需要比对条件值，所以线程 3会打印 - 接下来
线程 2执行[NSConditionLock lockWhenCondition:]，因为满足条件值，所以线程2会打印，打印完成后会调用[NSConditionLock unlockWithCondition:],这个时候将value设置为1，并发送boradcast, 此时线程 1接收到当前的信号，唤醒执行并打印. - 自此当前打印为
线程 3->线程 2 -> 线程 1 -
[NSConditionLock lockWhenCondition:];这里会根据传入的condition 值和 Value 值进行对比，如果不相等，这里就会阻塞，进入线程池，否则的话就继续代码执行[NSConditionLock unlockWithCondition:],这里会先更改当前的 value 值，然后进行广播，唤醒当前的线程
⑨ dispatch_semaphore
在iOS之武功秘籍⑬: 多线程原理与GCD和NSOperation篇章已经对信号量进行过讲解
⑩ 总结
-
OSSpinLock自旋锁由于安全性问题，在iOS10之后已经被废弃，其底层的实现用os_unfair_lock替代- 使用
OSSpinLock获取锁时，会处于忙等待状态 - 而
os_unfair_lock是处于休眠状态
- 使用
-
atomic原子锁自带一把自旋锁，只能保证setter、getter时的线程安全，在日常开发中使用更多的还是nonatomic修饰属性-
atomic：当属性在调用setter、getter方法时，会加上自旋锁osspinlock，用于保证同一时刻只能有一个线程调用属性的读或写，避免了属性读写不同步的问题.由于是底层编译器自动生成的互斥锁代码，会导致效率相对较低 -
nonatomic：当属性在调用setter、getter方法时，不会加上自旋锁，即线程不安全.由于编译器不会自动生成互斥锁代码，可以提高效率
-
-
@synchronized在底层维护了一个哈希表进行线程data的存储，通过链表表示可重入（即嵌套）的特性，虽然性能较低，但由于简单好用，使用频率很高 -
NSLock、NSRecursiveLock底层是对pthread_mutex的封装 -
NSCondition和NSConditionLock是条件锁，底层都是对pthread_mutex的封装，当满足某一个条件时才能进行操作，和信号量dispatch_semaphore类似
三、锁的使用场景
- 如果只是
简单的使用，例如涉及线程安全，使用NSLock即可 - 如果是
循环嵌套，推荐使用@synchronized，主要是因为使用递归锁的性能不如使用@synchronized的性能（因为在@synchronized中无论怎么重入，都没有关系，而NSRecursiveLock可能会出现崩溃现象） - 在
循环嵌套中，如果对递归锁掌握的很好，则建议使用递归锁，因为性能好 - 如果是
循环嵌套，并且还有多线程影响时，例如有等待、死锁现象时，建议使用@synchronized
写在后面
和谐学习,不急不躁.我还是我,颜色不一样的烟火.