22、锁

作者: ChenL | 来源:发表于2021-05-14 17:17 被阅读0次

一、锁的分类

image.png

从上图可以获得：锁的性能排行榜高到低

OSSpinLock（自旋锁）> dispatch_semaphore（信号量）> pthread_mutex （互斥锁）> NSLock （互斥锁）> NSCondition （条件锁）> pthread_mutex（recursive 互斥递归锁）> NSRecursiveLock（递归锁）> NSConditionLock （条件锁） > @syschronized（互斥锁）

1、自旋锁

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

OSSPinLock
atomic

2、互斥锁

一种用于多线程编程中，防止两条线同时对同一个公共资源进行读取的机制，该目的是通过将代码切成一个个临界区而达成。

@synchornized
NSLock
pthread_mutex

3、条件锁

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

NSCondition
NSConditionLock

4、递归锁

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

pthread_mutex(recursive)
NSRecursiveLock

5、信号量

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

dispatch_semaphore

6、读写锁

读写锁实际是一种特殊的自旋锁。

将共享资源的访问分成读者和写者，读者只对共享资源进行读访问，写者则需要对共享资源进行写操作，这种锁相对于自旋锁而言，能提高并发性

一个读写锁同时只能有一个写者或者多个读者，但不能既有读者又有写者，在读写锁保持期间也是抢占失效的
如果读写锁当前没有读者，也没有写者，那么写者可以立刻获得读写锁，否则它必须自旋在那里，直到没有任何写者或者读者，如果读写锁没有写者，那么读者可以立

其实基本的锁主要包括三类：自旋锁互斥锁读写锁
其他的如：条件锁、递归锁、信号量都是上层的封装和实现

1、OSSpinLock 自旋锁

OSSpinLock 在iOS10 之后就被抛弃了，由于出现了安全问题，是因为：获取锁后，线程会一直处于忙等待，造成了任务的优先级反转

其中的忙等待机制可能会造成高优先级任务一直running 等待，占用时间片，而低优先级额任务无法抢占时间片，会造成一直不能完成，锁未释放的情况

在 OSSpinLock 被弃用后，其替代方案是内部封装os_unfair_lock, 而 os_unfair_lock 在加锁时会处于休眠状态，而不是自旋锁额忙等状态。

2、atomic 原子锁

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

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

static inline void reallySetProperty(id self, SEL _cmd, id newValue, ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy)
{
   ...
   id *slot = (id*) ((char*)self + offset);
   ...

    if (!atomic) {//未加锁
        oldValue = *slot;
        *slot = newValue;
    } else {//加锁
        spinlock_t& slotlock = PropertyLocks[slot];
        slotlock.lock();
        oldValue = *slot;
        *slot = newValue;        
        slotlock.unlock();
    }
    ...
}

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

using spinlock_t = mutex_tt<LOCKDEBUG>;
class mutex_tt : nocopy_t {
    os_unfair_lock mLock;
    ...
}

3、synchronsized （互斥递归锁）

@synchronsized 的坑点

 - (void)testSync{
    _testArray = [NSMutableArray array];
    for (int i = 0; i < 200000; i++) {
        dispatch_async(dispatch_get_global_queue(0, 0), ^{
            @synchronized (self.testArray) {
                self.testArray = [NSMutableArray array];
            }
        });
    }
}

运行结果，会出现崩溃

崩溃主要原因：

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

_testArray = [NSMutableArray array];
for (int i = 0; i < 200000; i++) {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        _testArray = [NSMutableArray array];
    });
}

我们一般使用 @synchronsized(self),主要因为_testArray的持有者 self

注意：野指针 VS 过度释放

野指针：是指由于过度释放产生的指针还在进行操作
过度释放：每次都会retain 和release

总结一下：

1、@synchronized 在底层封装的是一把递归锁，所以是 递归互斥锁

2、@synchronized 的可重入，即可嵌套，主要是由于lockCount 和 threadCount 的搭配

3、@synchronized 使用链表的原因是：链表方便下一个data的插入

4、但是由于底层中链表查询、缓存的查找以及递归，是非常耗内存以及性能的，导致性能低，所以在前文中，该锁的排名在最后

5、但是目前该锁的使用频率仍然很高，主要是因为方便简单，且不用解锁

6、不能使用 非OC对象 作为加锁对象，因为其object 的参数为id

7、@synchornied（self）这种适用于 嵌套次数较少 的场景。这里锁住的对象也并不永远是self

8、如果锁嵌套次数较多，即锁self过多，会导致底层的查找非常麻烦，因为其底层是链表进行查找，所以会相对比较麻烦，所以此时可以使用NSLock、信号量

4、NSLock

NSLock 是对下层pthread_mutex 的封装

NSLock *lock = [[NSLock alloc] init];
[lock lock];
[lock unlock];

由于OC的Foundation源码不开源，可以通过swfit的开源框架Foundation 来分析NSLock的底层实现。

image.png

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

弊端分析：

for (int i= 0; i<100; i++) {
    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);
    });
}

在未加锁之前，其中的 current = 9、10 有很多条，导致数据混乱（多线程导致的）

image.png

如下加锁之后

NSLock *lock = [[NSLock alloc] init];
for (int i= 0; i<100; i++) {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        static void (^testMethod)(int);
        testMethod = ^(int value){
            [lock lock];
            if (value > 0) {
              NSLog(@"current value = %d",value);
              testMethod(value - 1);
            }
        };
        testMethod(10);
        [lock unlock];
    });
}

image.png

会出现一直等待的情况，主要是因为嵌套使用的递归，使用 NSLock （简单的互斥锁，如果没有回来，会一直睡觉等待），即会存在一直加Lock，等不到unlock的堵塞情况
所以，针对这种情况，可以使用以下方式解决：

@synchronized

for (int i= 0; i<100; i++) {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        static void (^testMethod)(int);
        testMethod = ^(int value){
            @synchronized (self) {
                if (value > 0) {
                  NSLog(@"current value = %d",value);
                  testMethod(value - 1);
                }
            }
        };
        testMethod(10); 
    });
}

或者递归锁 NSRecursiveLock

NSRecursiveLock *recursiveLock = [[NSRecursiveLock alloc] init];
 for (int i= 0; i<100; i++) {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        static void (^testMethod)(int);
        [recursiveLock lock];
        testMethod = ^(int value){
            if (value > 0) {
              NSLog(@"current value = %d",value);
              testMethod(value - 1);
            }
            [recursiveLock unlock];
        };
        testMethod(10);
    });
}

5、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);

6、NSRecursiveLock

递归锁，NSRecursiveLock 在底层也是对pthread_mutex 的封装

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

7、NSCondition

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

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

锁：为了当检测条件保护数据源，执行条件引发的任务
线程检查器：主要是根据条件决定是否继续运行线程，即线程是否被阻塞

//初始化
NSCondition *condition = [[NSCondition alloc] init]

//一般用于多线程同时访问、修改同一个数据源，保证在同一 时间内数据源只被访问、修改一次，其他线程的命令需要在lock 外等待，只到 unlock ，才可访问
[condition lock];

//与lock 同时使用
[condition unlock];

//让当前线程处于等待状态
[condition wait];

//CPU发信号告诉线程不用在等待，可以继续执行
[condition signal];

分析：

NSCondition 是对 mutex 和 cond 的一种封装（cnd 就是用于访问和操作特定类型数据的指针）
wait 操作会阻塞线程，使其进入休眠状态，直至超时
signal 操作是唤醒一个正在休眠等待的线程
broadcast 会唤醒所有正在等待的线程

8、NSConditionLock

NSConditionLock 是条件锁，一旦一个线程获得锁，其他线程一定等待，相比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时间];

//其中所谓的condition就是整数，内部通过整数比较条件

锁的使用场景

1、如果只是简单的使用，例如涉及线程安全，使用NSLock 即可

2、如果是循环嵌套，推荐使用 @synchornized，主要是因为使用递归锁的性能不如使用@synchornized的性能（因为在synchornized中无论怎么重入，都没有关系,而NSRecuriveLock 可能会出现崩溃）

3、在循环嵌套中，如果对递归锁掌握的很好，则可以使用递归锁，因为性能好

4、如果是循环嵌套，并且还有多线程影响时，例如等待、死锁现象，建议使用@synchornized

22、锁

一、锁的分类

1、自旋锁

2、互斥锁

3、条件锁

4、递归锁

5、信号量

6、读写锁

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

22、锁

一、锁的分类

1、 自旋锁

2、互斥锁

3、条件锁

4、递归锁

5、信号量

6、读写锁

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

1、自旋锁