22、锁

一、锁的分类

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

推荐阅读更多精彩内容

  • iOS 底层原理 文章汇总[https://www.jianshu.com/p/412b20d9a0f6] 本文主...
    Style_月月阅读 2,097评论 5 11
  • 本文主要介绍常见的锁,以及synchronized、NSLock、递归锁、条件锁的底层分析 锁 借鉴一张锁的性能数...
    辉辉岁月阅读 530评论 0 5
  • 今天主要学习了flex布局,学习笔记如下: 1.指定flex布局: display:flex(任意容器)...
    riku_lu阅读 1,719评论 2 3
  • 插打法原为少林六合门打法,一代宗师万籁声将少林六合门、罗汉门、自然门等内外家之所长融为一家,自然门本无固定招式,然...
    梁山的洛奇阅读 2,245评论 1 2
  • 董多娇第226天坚持分享,焦点相信,每个人在每一刻都会为自己做出一个决定与选择,是他们当时认为最合适自己的,所以任...
    良知良能良知良能阅读 1,374评论 1 1