iOS 开发，各种锁你了解多少？NSLock、NSCondtion、NSRecursiveLock.......
回顾
在之前的一篇博客中，介绍了锁的种类，在上一篇博客中已经对@synchronized锁进行了源码分析，还有其他的一些锁没有介绍，那么本篇博客就分析一下其他的一些锁！
iOS底层探索之多线程(六)—GCD源码分析(sync 同步函数、async 异步函数)
iOS底层探索之多线程(八)—GCD源码分析(函数的同步性、异步性、单例)
iOS底层探索之多线程(十四)—关于@synchronized锁你了解多少?
iOS底层探索之多线程(十五)—@synchronized源码分析
1. 关于锁的介绍
1.1 锁的分类
-
⾃旋锁：线程反复检查锁变量是否可⽤。由于线程在这⼀过程中保持执⾏，因此是⼀种忙等待。⼀旦获取了⾃旋锁，线程会⼀直保持该锁，直⾄显式释放⾃旋锁。⾃旋锁避免了进程上下⽂的调度开销，因此对于线程只会阻塞很短时间的场合是有效的。 -
互斥锁：是⼀种⽤于多线程编程中，防⽌两条线程同时对同⼀公共资源（⽐如全局变量）进⾏读写的机制。该⽬的通过将代码切⽚成⼀个⼀个的临界区⽽达成互斥的作用。
属于互斥锁的有：NSLock 、pthread_mutex 、 @synchronized等
1.2 锁的归类
-
条件锁：就是条件变量，当进程的某些资源要求不满⾜时就进⼊休眠，也就是锁住了。当资源被分配到了，条件锁打开，进程继续运⾏，如：NSCondition、NSConditionLock -
递归锁：就是同⼀个线程可以加锁N次⽽不会引发死锁，如：NSRecursiveLock、pthread_mutex(recursive) -
信号量（semaphore）：是⼀种更⾼级的同步机制，互斥锁可以说是semaphore在仅取值0/1时的特例。信号量可以有更多的取值空间，⽤来实现更加复杂的同步，⽽不单单是线程间互斥，如：dispatch_semaphore
锁的归类其实基本的锁就包括了三类: ⾃旋锁 互斥锁 读写锁，其他的⽐如条件锁，递归锁，信号量都是上层的封装和实现！
-
读写锁：读写锁实际是⼀种特殊的互斥锁，它把对共享资源的访问者划分成读者和写者，读者只对共享资源进⾏读访问，写者则需要对共享资源进⾏写操作。
2. NSLock
- 举例1
有如下代码：
- (void)is_crash{
NSLog(@"reno");
for (int i = 0; i < 10000; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
_testArray = [NSMutableArray array];
});
}
}
- 不加锁的时候运行
没有加锁，多线程访问，直接奔溃了，那么现在去加锁看看结果如何呢？
- 加锁
加锁的情况下，就不会奔溃，保证了线程的安全。
- 举例 2
NSLog(@"jpreno");
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);
});
- 打印结果
打印结果没有任何问题，那么加个 for循环呢？
现在出现了，打印的数据混乱了，也就是多线程访问了，那么解决办法，就是加锁，那么加在哪里呢？大部分人会加在这里，如下：
那么加在上图中，会正常打印吗？现在还不得而知，现在我们去运行一下代码来看看吧！
从运行打印结果来看，数据还是错乱了，很显然
NSLock 的锁的位置没有加对地方，那么正确✅的加锁位置在哪里呢？请看👇：只有把锁加在如图中位置即可解决问题，或者直接加在
testMethod(10)这个地方也是可以的。
[jp_lock lock];//加锁
testMethod(10);
[jp_lock unlock];//解锁
一般加锁，大家都喜欢和业务代码写在一起，如下：
这里一直递归，一直加锁，没有解锁，相当于死锁，只是程序还没有崩溃而已，那么为什么呢？NSLock不支持递归加锁，没有递归性。
3. NSRecursiveLock
我们还记得有个锁——NSRecursiveLock，这个锁的性能也是还不错的，并且支持递归性，使用如下：
NSRecursiveLock虽然有递归性，但是不支持多线程的可递归，只运行一次就崩溃了。所以这个时候，有靓仔肯定想到了用@synchronized这把锁了，是的，这把锁是符合递归和多线程特性的。
通过添加
@synchronized这个锁，很完美的解决了问题，NSRecursiveLock是解决了 NSLock的不可递归性，这里使用@synchronized是解决了NSRecursiveLock不可多线程性。
4. NSCondition
NSCondition 的对象实际上作为⼀个锁和⼀个线程检查器。
- 锁主要为了当检测条件时保护数据源，执⾏条件引发的任务；
- 线程检查器主要是根据条件决定是否继续运⾏线程，即线程是否被阻塞。
1：[condition lock] :⼀般⽤于多线程同时访问、修改同⼀个数据源，保证在同⼀
时间内数据源只被访问、修改⼀次，其他线程的命令需要在lock 外等待，只到
unlock ，才可访问
2：[condition unlock]:与lock同时使⽤
3：[condition wait]:让当前线程处于等待状态
4：[condition signal]:CPU发信号告诉线程不⽤在等待，可以继续执⾏。
现在举个生产者和消费者的例子，代码如下：
- (void)viewDidLoad {
[super viewDidLoad];
self.ticketCount = 0;
_testCondition = [[NSCondition alloc] init];
[self jp_testConditon];
}
#pragma mark -- NSCondition
- (void)jp_testConditon{
//创建生产-消费者
for (int i = 0; i < 50; i++) {
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
[self jp_producer];
});
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
[self jp_consumer];
});
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
[self jp_consumer];
});
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
[self jp_producer];
});
}
}
- (void)jp_producer{
self.ticketCount = self.ticketCount + 1;
NSLog(@"生产一个 现有 count %zd",self.ticketCount);
}
- (void)jp_consumer{
if (self.ticketCount == 0) {
NSLog(@"等待 count %zd",self.ticketCount);
}
self.ticketCount -= 1;
NSLog(@"消费一个 还剩 count %zd ",self.ticketCount);
}
运行结果，如下：
从运行结果，可以看到出现了负数的情况，我生产者生产的东西你都消费完了，已经没有了，你还在消费，就出现了线程不安全访问的事故了。
所以我们要保证生产线、消费线数据的安全，就需要进行加锁处理，以保证多线程安全，但这只是它们内部的得到保证了，但是它们之间存在消费关系，比如生产的库存没有了，不得通知，消费者进行等待，生产好了再通知消费者来消费买单。
现在进行加锁改造，如下：
(void)jp_producer{
[_testCondition lock]; // 操作的多线程影响
self.ticketCount = self.ticketCount + 1;
NSLog(@"生产一个 现有 count %zd",self.ticketCount);
[_testCondition signal]; // 发送信号，通知消费者，我这里生产好，你可以来消费了
[_testCondition unlock];
}
- (void)jp_consumer{
[_testCondition lock]; // 操作的多线程影响
if (self.ticketCount == 0) {
NSLog(@"等待 count %zd",self.ticketCount);
[_testCondition wait];// 等待生产者 生产东西
}
//注意消费行为，要在等待条件判断之后
self.ticketCount -= 1;
NSLog(@"消费一个 还剩 count %zd ",self.ticketCount);
[_testCondition unlock];
}
现在再来看看，加锁之后的结果，是否安全呢？如下：
很明显，加锁之后的打印是正常的，没有出现负数，数据是安全的！
- 如果产品不足就
[_testCondition wait]进行等待，使得消费者停止消费 - 用
[_testCondition signal]模拟现在有生产了，可以来消费了，向等待的线程发送信号，通知来消费
4.总结
- 多线程访问，需要保证数据的安全，可以继续加锁处理
-
NSLock不支持递归加锁 -
NSRecursiveLock虽然有递归性，但没有多线程特性 -
NSCondition的对象实际上作为⼀个锁和⼀个线程检查器
更多内容持续更新
🌹 喜欢就点个赞吧👍🌹
🌹 觉得有收获的，可以来一波，收藏+关注，评论 + 转发，以免你下次找不到我😁🌹
🌹欢迎大家留言交流，批评指正，互相学习😁，提升自我🌹
