iOS开发中的锁

锁的分类

根据资源申请者的表现形式，锁分为：自旋锁 和 互斥锁

自旋锁： 不引起调用者的休眠，如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是否该自旋锁的保持者已经释放了锁，相当于进入了一个while循环。

互斥锁: 如果资源已经被占用，资源申请者就进入休眠状态。

锁🔐的分类.jpg

• 优缺点比较

自旋锁不会使线程状态发生切换，互斥锁在获取不到锁的时候会选择sleep。
互斥锁获取锁分为两阶段，第一阶段在用户态采用spinlock锁总线的方式获取一次锁，如果成功立即返回；否则进入第二阶段，调用系统的futex锁去sleep，当锁可用后被唤醒，继续竞争锁。

自旋锁优点：没有昂贵的系统调用，一直处于用户态，执行速度快。
自旋锁缺点：一直占用cpu，而且在执行过程中还会锁bus总线，锁总线时其他处理器不能使用总线。

互斥锁优点：不会忙等，得不到锁会sleep。
互斥锁缺点：sleep时会陷入到内核态，需要昂贵的系统调用。

• 使用准则

自旋锁使用准则：临界区尽量简短，控制在100行代码以内，不要有显式或者隐式的系统调用，调用的函数也尽量简短。例如，不要在临界区中调用read,write,open等会产生系统调用的函数，也不要去sleep；strcpy，memcpy等函数慎用，依赖于数据的大小。

自旋锁

spinlock又称自旋锁，线程通过busy-wait-loop的方式来获取锁，任时刻只有一个线程能够获得锁，其他线程忙等待直到获得锁。spinlock在多处理器多线程环境的场景中有很广泛的使用，一般要求使用spinlock的临界区尽量简短，这样获取的锁可以尽快释放，以满足其他忙等的线程。Spinlock和mutex不同，spinlock不会导致线程的状态切换(用户态->内核态)，但是spinlock使用不当(如临界区执行时间过长)会导致cpu busy飙高。

在iOS中，自旋锁我们用的是OSSpinLock
我们结合一个具体的场景来使用一些。用存钱和取钱的问题。

@interface OSSpinLockDemo()
@property (assign, nonatomic) OSSpinLock moneyLock;
@property (assign, nonatomic) int money;
@end

@implementation OSSpinLockDemo

- (instancetype)init
{
    if (self = [super init]) {
        self.money = 100;
        self.moneyLock = OS_SPINLOCK_INIT;
    }
    return self;
}

/**
 存钱、取钱演示
 */
- (void)moneyTest
{
    
    dispatch_queue_t queue = dispatch_get_global_queue(0, 0);
    
    dispatch_async(queue, ^{
        for (int i = 0; i < 10; i++) {
            [self saveMoney];
        }
    });
    
    dispatch_async(queue, ^{
        for (int i = 0; i < 10; i++) {
            [self drawMoney];
        }
    });
}

- (void)drawMoney
{
    OSSpinLockLock(&_moneyLock);
    
    [self __drawMoney];
    
    OSSpinLockUnlock(&_moneyLock);
}

- (void)saveMoney
{
    OSSpinLockLock(&_moneyLock);
    
    [self __saveMoney];
    
    OSSpinLockUnlock(&_moneyLock);
}

//存钱
- (void)__saveMoney
{
    int oldMoney = self.money;
    sleep(.2);
    oldMoney += 50;
    self.money = oldMoney;
    
    NSLog(@"存50，还剩%d元 - %@", oldMoney, [NSThread currentThread]);
}

//取钱
- (void)__drawMoney
{
    int oldMoney = self.money;
    sleep(.2);
    oldMoney -= 20;
    self.money = oldMoney;
    
    NSLog(@"取20，还剩%d元 - %@", oldMoney, [NSThread currentThread]);
}
@end

我们来看下使用OSSpinLock的情况，在加锁的地方打断点，然后点击任务栏Debug->Debug Worlflow->Always Show Disassembly。在xcode的lldb下使用si命令让汇编代码一步一步的执行，观察等待锁的线程状态：

OSSpinLock.jpg
在_OSSpinLockLockSlow方法里，我们可以看到汇编指令会反复的在这两个地址之间执行，jmp 跳转到上面的执行过地址，类似一个while循环，线程处在一个忙等状态。

不再安全的OSSpinLock

在 iOS 10.0系统之后，系统维护了 5 个不同的线程优先级/QoS: background，utility，default，user-initiated，user-interactive。高优先级线程始终会在低优先级线程前执行，一个线程不会受到比它更低优先级线程的干扰。这种线程调度算法会产生潜在的线程优先级反转问题，从而破坏了 spin lock。

具体来说，如果一个低优先级的线程获得锁并访问共享资源，这时一个高优先级的线程也尝试获得这个锁，它会处于 spin lock 的忙等状态从而占用大量 CPU。此时低优先级线程无法与高优先级线程争夺 CPU 时间，从而导致任务迟迟完不成、无法释放 lock。这并不只是理论上的问题，libobjc 已经遇到了很多次这个问题了，于是苹果的工程师停用了 OSSpinLock。

当然除非开发者能保证访问锁的线程全部都处于同一优先级，否则 iOS 系统中所有类型的自旋锁都不能再使用了。

os_unfair_lock

在iOS10之后apple废弃了OSSpinLock自旋锁，使用os_unfair_lock来替代。
在OSSpinLock的api注释中明确指出这是一个自旋锁，那么它的替代方案是一把什么类型的锁呢？

@interface OSSpinLockDemo()
@property (assign, nonatomic) os_unfair_lock moneyLock;
@property (assign, nonatomic) int money;
@end

@implementation OSSpinLockDemo

- (instancetype)init
{
    if (self = [super init]) {
        self.money = 100;
        self.moneyLock = OS_UNFAIR_LOCK_INIT;
    }
    return self;
}

/**
 存钱、取钱演示
 */
- (void)moneyTest
{
    
    dispatch_queue_t queue = dispatch_get_global_queue(0, 0);
    
    dispatch_async(queue, ^{
        for (int i = 0; i < 10; i++) {
            [self saveMoney];
        }
    });
    
    dispatch_async(queue, ^{
        for (int i = 0; i < 10; i++) {
            [self drawMoney];
        }
    });
}

- (void)drawMoney
{
    os_unfair_lock_lock(&_moneyLock);
    
    [self __drawMoney];
    
    os_unfair_lock_lock(&_moneyLock);
}

- (void)saveMoney
{
    os_unfair_lock_lock(&_moneyLock);
    
    [self __saveMoney];
    
    os_unfair_lock_lock(&_moneyLock);
}

//存钱
- (void)__saveMoney
{
    int oldMoney = self.money;
    sleep(.2);
    oldMoney += 50;
    self.money = oldMoney;
    
    NSLog(@"存50，还剩%d元 - %@", oldMoney, [NSThread currentThread]);
}

//取钱
- (void)__drawMoney
{
    int oldMoney = self.money;
    sleep(.2);
    oldMoney -= 20;
    self.money = oldMoney;
    
    NSLog(@"取20，还剩%d元 - %@", oldMoney, [NSThread currentThread]);
}
@end

下面我们来看使用os_unfair_lock的情况，在加锁的地方打断点，然后点击任务栏Debug->Debug Worlflow->Always Show Disassembly。在xcode的lldb下使用si命令让汇编代码一步一步的执行，观察等待锁的线程状态：。

unfair_Loack.jpg

可以在_os_unfair_lock_slow里看到这句__ulock_wait。syscall调用了系统内核的函数，使得线程进入休眠状态，不再占用CPU资源。所以根据上面描述分析的汇编，我们也能从汇编层的逻辑看到自旋锁和互斥锁的区别,同时也看出代替 OSSpinLock的os_unfair_lock属于互斥锁。

互斥锁

从上面我们了解到os_unfair_lock是一种互斥锁。除了os_unfair_lock，我们iOS中常用到的互斥锁还有很多种。
从业务的不同场景来分析，互斥锁可以大概分为四种：普通锁、递归锁、条件锁、读写锁。

互斥锁

对于这些锁的使用我这里就不阐述，针对一些经典的取钱存钱、取票问题，我分别用上述的各种锁演示了一遍。代码见最后。

锁的demo

锁的作用主要就是对于一些访问资源的保护，在实际应用中，不仅只有锁的手段去进行保护，比如队列、信号量这些手段也可以达到保护的效果。

补充: 在属性中我们经常提到的atomic，其底层就是用的自旋锁OSSpinlock，在属性的setter、getter方法的运算逻辑进行加锁解锁。由于我们会经常的使用到属性，这样的话就会频繁占用到大量的cup，损耗性能。而且atomic也不能保证完全的数据安全，所以在开发中我们基本不去使用atomic进行修饰属性。

iOS的锁🔐Demo