iOS底层探索之多线程(十六)——锁分析(NSLock、NSCo

⾃旋锁：线程反复检查锁变量是否可⽤。由于线程在这⼀过程中保持执⾏，因此是⼀种忙等待。⼀旦获取了⾃旋锁，线程会⼀直保持该锁，直⾄显式释放⾃旋锁。 ⾃旋锁避免了进程上下⽂的调度开销，因此对于线程只会阻塞很短时间的场合是有效的。
互斥锁：是⼀种⽤于多线程编程中，防⽌两条线程同时对同⼀公共资源（⽐如全局变量）进⾏读写的机制。该⽬的通过将代码切⽚成⼀个⼀个的临界区⽽达成互斥的作用。

属于互斥锁的有：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];
        });
    }
}

不加锁的时候运行

多线程访问

没有加锁，多线程访问，直接奔溃了，那么现在去加锁看看结果如何呢？

加锁

NSLock

加锁的情况下，就不会奔溃，保证了线程的安全。

举例 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 的对象实际上作为⼀个锁和⼀个线程检查器

更多内容持续更新

🌹 喜欢就点个赞吧👍🌹

🌹 觉得有收获的，可以来一波，收藏+关注，评论 + 转发，以免你下次找不到我😁🌹

🌹欢迎大家留言交流，批评指正，互相学习😁，提升自我🌹

iOS底层探索之多线程(十六)——锁分析(NSLock、NSCo

回顾

1. 关于锁的介绍

1.1 锁的分类

1.2 锁的归类

2. NSLock

3. NSRecursiveLock

4. NSCondition

4.总结

猜你喜欢

热点阅读