iOS中锁的分析

image.jpeg

** @synchronized ** 递归互斥锁

// objc_sync_enter lock 加锁
// objc_sync_exit 解锁
recursive_mutex_t 递归锁
1、当如果锁的是nil，那么久直接retrun返回
2、SyncData 进行了两种方案，一种是从栈里面保存这个锁，一种是用cache里面保存这把锁
objc_sync_enter & objc_sync_exit 分析

• 进入objc_sync_enter源码实现

• 如果obj存在，则通过id2data方法获取相应的SyncData，对threadCount、lockCount进行递增操作

• 如果obj不存在，则调用objc_sync_nil，通过符号断点得知，这个方法里面什么都没做，直接return了

  image.jpeg

image.jpeg

data->mutex.lock();//加锁

• 进入objc_sync_exit源码实现

• 如果obj存在，则调用id2data方法获取对应的SyncData，对threadCount、lockCount进行递减操作

• 如果obj为nil，什么也不做

• image.jpeg

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

image.jpeg

【第一步】首先在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，则什么也不做

** 【第二步】如果tls中没有，则在cache缓存中查找*

• 通过fetch_cache方法查找cache缓存中是否有线程

• 如果有，则遍历cache总表，读取出线程对应的SyncCacheItem

• 从SyncCacheItem中取出data，然后后续步骤与tls的匹配是一致的

  【第三步】如果cache中也没有，即第一次进来，则创建SyncData，并存储到相应缓存中

如果在cache中找到线程，且与object相等，则进行赋值、以及threadCount++
如果在cache中没有找到，则threadCount等于1

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

【第一次进来，没有锁】：

• threadCount = 1
• lockCount = 1
• 存储到tls 【不是第一次进来，且是同一个线程】
• tls中有数据，则lockCount++
• 存储到tls 【不是第一次进来，且是不同线程】
• 全局线程空间进行查找线程
• threadCount++
• lockCount++
• 存储到cache 总结
• @synchronized在底层封装的是一把递归锁，所以这个锁是递归互斥锁，底层通过TLS缓存和cache缓存
• @synchronized的可重入，即可嵌套，主要是由于lockCount 和 threadCount的搭配
• @synchronized使用链表的原因是链表方便下一个data的插入，
• 但是由于底层中链表查询、缓存的查找以及递归，是非常耗内存以及性能的，导致性能低，所以在前文中，该锁的排名在最后
• 但是目前该锁的使用频率仍然很高，主要是因为方便简单，且不用解锁
• 不能使用非OC对象作为加锁对象，因为其object的参数为id
• @synchronized (self)这种适用于嵌套次数较少的场景。这里锁住的对象也并不永远是self，这里需要读者注意
• 如果锁嵌套次数较多，即锁self过多，会导致底层的查找非常麻烦，因为其底层是链表进行查找，所以会相对比较麻烦，所以此时可以使用NSLock、信号量等

NSLock

image.jpeg

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

image.jpeg

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

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

NSRecursiveLock

NSRecursiveLock在底层也是对pthread_mutex的封装

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

image.jpeg

NSCondition

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

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

• 锁主要 为了当检测条件时保护数据源，执行条件引发的任务

• 线程检查器主要是根据条件决定是否继续运行线程，即线程是否被阻塞

  
  image.jpeg

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

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

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

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

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

NSConditionLock

NSConditionLock是条件锁，一旦一个线程获得锁，其他线程一定等待

相比NSConditionLock而言，NSCondition使用比较麻烦，所以推荐使用NSConditionLock，其使用如下

image.jpeg

NSConditionLock，其本质就是NSCondition + Lock

线程 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 值，然后进行广播，唤醒当前的线程