Objective-C中不同方式实现锁

文章目录

1. 一些多线程的基础知识
2. 简单易用的条件锁 @synchronized
3. 使用C语言的pthread_mutex_t实现的互斥锁
4. 使用GCD来实现的”锁”
5. 自旋锁 OSSpinLock
6. 使用NSLock实现的锁
7. NSRecursiveLock递归锁
8. NSCondition
9. NSConditionLock条件锁
10. NSDistributedLock分布式锁
11. 多线程中的常见术语

为什么需要使用锁，当然熟悉多线程的你，自然不会对它觉得陌生。

那你在代码中是否很好的使用了锁的机制呢？你又知道几种实现锁的方法呢？

今天一起来探讨一下Objective-C中几种不同方式实现的锁，在这之前我们先构建一个测试用的类，假想它是我们的一个共享资源，method1与method2是互斥的，代码如下：

@implementation TestObj
- (void)method1
{
    NSLog(@"%@",NSStringFromSelector(_cmd));
}
- (void)method2
{
    NSLog(@"%@",NSStringFromSelector(_cmd));    
}
@end

一些多线程的基础知识

时间片轮转调度算法

了解多线程加锁必须知道时间片轮转调度算法，才能深切理解其原理、性能瓶颈。

现代操作系统在管理普通线程时，通常采用时间片轮转算法(Round Robin，简称 RR)。每个线程会被分配一段时间片(quantum)，通常在 10-100 毫秒左右。当线程用完属于自己的时间片以后，就会被操作系统挂起，放入等待队列中，直到下一次被分配时间片，如果线程在时间片结束前阻塞或结束，则CPU当即进行切换。由于线程切换需要时间，如果时间片太短，会导致大量CPU时间浪费在切换上；而如果这个时间片如果太长，会使得其它线程等待太久；

原子操作

狭义上的原子操作表示一条不可打断的操作，也就是说线程在执行操作过程中，不会被操作系统挂起，而是一定会执行完（理论上拥有CPU时间片无限长）。在单处理器环境下，一条汇编指令显然是原子操作，因为中断也要通过指令来实现，但一句高级语言的代码却不是原子的，因为它最终是由多条汇编语言完成，CPU在进行时间片切换时，大多都会在某条代码的执行过程中。
但在多核处理器下，则需要硬件支持，没了解过具体实现。

自旋锁和互斥锁

都属于CPU时间分片算法下的实现保护共享资源的一种机制。都实现互斥操作，加锁后仅允许一个访问者。

区别在于自旋锁不会使线程进入wait状态，而通过轮训不停查看是否该自旋锁的持有者已经释放的锁；对应的，互斥锁在出现锁已经被占用的情况会进入wait状态，CPU会当即切换时间片。

自旋锁实现原理

简单的while循环

lock = 0;
do{
    while(test_and_set(&lock));
    临界区
    lock = 0;
    其余部分
} while(1)

test_and_set用来保证条件判断的原子性操作，lock为旗标。

自旋锁的一大缺陷是会使得线程处于忙等状态。因为如果临界区执行时间过长，其它线程就会在当前整个时间片一直处于忙等状态，浪费大量CPU时间。所以，如果临界区时间很短，可以使用自旋锁，否则建议使用互斥锁。

互斥锁的实现原理

互斥锁在出现锁的争夺时，未获得锁的线程会主动让出时间片，阻塞线程并睡眠，需要进行上下文切换，CPU会切换其它线程继续操作。

主动让出时间片并不总是代表效率高。让出时间片会导致操作系统切换到另一个线程，这种上下文切换通常需要 10 微秒左右，而且至少需要两次切换。如果等待时间很短，比如只有几个微秒，忙等就比线程睡眠更高效。

信号量的实现

int sem_wait (sem_t *sem) {  
  int *futex = (int *) sem;
  if (atomic_decrement_if_positive (futex) > 0)
    return 0;
  int err = lll_futex_wait (futex, 0);
    return -1;
)

信号量和互斥锁类似，都是在获取锁失败后线程进入wait状态，CPU会切换时间片。

信号量在最终都是调用一个sem_wait方法，并原子性的判断信号量，如果对其-1后依然大于0，则直接返回，继续临界区操作，否则进入等待状态。

简单易用的条件锁 @synchronized

当然在Objective-C中你还可以用@synchronized指令快速的实现锁：

//主线程中
TestObj *obj = [[TestObj alloc] init];
//线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    @synchronized(obj){
        [obj method1];
        sleep(10);
    }
});
//线程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    sleep(1);
    @synchronized(obj){
        [obj method2];
    }
});

@synchronized指令使用的obj为该锁的唯一标识，只有当标识相同时，才为满足互斥，如果线程2中的@synchronized(obj)改为@synchronized(other),刚线程2就不会被阻塞，@synchronized指令实现锁的优点就是我们不需要在代码中显式的创建锁对象，便可以实现锁的机制，但作为一种预防措施，@synchronized块会隐式的添加一个异常处理例程来保护代码，该处理例程会在异常抛出的时候自动的释放互斥锁。所以如果不想让隐式的异常处理例程带来额外的开销，你可以考虑使用锁对象。

@synchronized 实际上是把修饰对象当做锁来使用。这是通过一个哈希表来实现的，OC 在底层使用了一个互斥锁的数组(你可以理解为锁池)，通过对对象去哈希值来得到对应的互斥锁。

使用C语言的pthread_mutex_t实现的互斥锁

//主线程中
TestObj *obj = [[TestObj alloc] init];
__block pthread_mutex_t mutex;
pthread_mutex_init(&mutex, NULL);
//线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    pthread_mutex_lock(&mutex);
    [obj method1];
    sleep(5);
    pthread_mutex_unlock(&mutex);
});
//线程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    sleep(1);
    pthread_mutex_lock(&mutex);
    [obj method2];
    pthread_mutex_unlock(&mutex);
});

pthread_mutex_t定义在pthread.h，所以记得#include

pthread 表示 POSIX thread，定义了一组跨平台的线程相关的 API，pthread_mutex 表示互斥锁。互斥锁的实现原理与信号量非常相似，不是使用忙等，而是阻塞线程并睡眠，需要进行上下文切换。

互斥锁的常见用法如下:

pthread_mutexattr_t attr;  
pthread_mutexattr_init(&attr);  
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL);  // 定义锁的属性
pthread_mutex_t mutex;  
pthread_mutex_init(&mutex, &attr) // 创建锁
pthread_mutex_lock(&mutex); // 申请锁  
    // 临界区
pthread_mutex_unlock(&mutex); // 释放锁

对于 pthread_mutex 来说，它的用法和之前没有太大的改变，比较重要的是锁的类型，可以有 PTHREAD_MUTEX_NORMAL、PTHREAD_MUTEX_ERRORCHECK、PTHREAD_MUTEX_RECURSIVE 等等，具体的特性就不做解释了，网上有很多相关资料。

一般情况下，一个线程只能申请一次锁，也只能在获得锁的情况下才能释放锁，多次申请锁或释放未获得的锁都会导致崩溃。假设在已经获得锁的情况下再次申请锁，线程会因为等待锁的释放而进入睡眠状态，因此就不可能再释放锁，从而导致死锁。

然而这种情况经常会发生，比如某个函数申请了锁，在临界区内又递归调用了自己。辛运的是 pthread_mutex 支持递归锁，也就是允许一个线程递归的申请锁，只要把 attr 的类型改成 PTHREAD_MUTEX_RECURSIVE 即可。

使用GCD来实现的”锁”

//主线程中
TestObj *obj = [[TestObj alloc] init];
dispatch_semaphore_t semaphore = dispatch_semaphore_create(1);
//线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
    [obj method1];
    sleep(10);
    dispatch_semaphore_signal(semaphore);
});
//线程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    sleep(1);
    dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
    [obj method2];
    dispatch_semaphore_signal(semaphore);
});

信号量dispatch_semaphore被称为spinlock的替代方案。（引 http://blog.ibireme.com/2016/01/16/spinlock_is_unsafe_in_ios/）

使用方法非常简单，dispatch_semaphore_create(1)为创建信号，数字表示可以同时几个线程使用信号。为1表示同步使用。上述代码如果此处标2就和没设置信号量一样，并发自行运行。如果设置为0，则一律等待overTime时自动释放，所有代码都不执行，理论上也具有同步作用，就是慢点…

dispatch_semaphore_wait中传入的timeout表示最长加锁时间，此处sleep如果为4，则在3s后会自动释放锁，其它线程可以获取信号并继续运行。

和厕所坑位类似，dispatch_semaphore_create(1)表示只有1个坑位，timeout = dispatch_time(DISPATCH_TIME_NOW, 3.0f * NSEC_PER_SEC)表示坑位只能占用3秒。无论是否当前线程，坑位都一致。可以在同一线程频繁调用dispatch_semaphore_wait，在只有一个坑位且没有dispatch_semaphore_signal信号情况下，会等到每次的timeout。所以理论上可以不成对出现。

自旋锁 OSSpinLock

__block OSSpinLock oslock = OS_SPINLOCK_INIT;
    
//线程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
   NSLog(@"线程2 准备上锁");
   OSSpinLockLock(&oslock);
   NSLog(@"线程2");
   OSSpinLockUnlock(&oslock);
   NSLog(@"线程2 解锁成功");
});
//线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0), ^{
   NSLog(@"线程1 准备上锁");
   OSSpinLockLock(&oslock);
   NSLog(@"线程1 sleep");
   sleep(4);
   NSLog(@"线程1");
   OSSpinLockUnlock(&oslock);
   NSLog(@"线程1 解锁成功");
});

虽然YY大神 http://blog.ibireme.com/ 说其已经不再安全，但GCD在多线程实际应用过程中，未发现问题，并行线程只要获取到oslock，其它线程一律阻塞（非睡眠），直到之前获取的解锁为止，上述代码QUEUE优先级相差较大，在实际使用中未发生高优先级忙等状态。

低优先级线程拿到锁时，高优先级线程进入忙等(busy-wait)状态，消耗大量 CPU 时间，从而导致低优先级线程拿不到 CPU 时间，也就无法完成任务并释放锁。这种问题被称为优先级反转。

可以在同一线程无限制上锁，但必须成对出现解锁，否则会死锁。可以在同一线程无限制调用解锁，但如果没有获取锁，解锁代码无效。

结论：QUEUE的优先级和CPU调度的线程优先级可能并不是一回事，实际运用GCD来进行多线程开发时，可以应用自旋锁进行数据同步。

使用NSLock实现的锁

//主线程中
TestObj *obj = [[TestObj alloc] init];
NSLock *lock = [[NSLock alloc] init];
//线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    [lock lock];
    [obj method1];
    sleep(10);
    [lock unlock];
});
//线程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    sleep(1);//以保证让线程2的代码后执行
    [lock lock];
    [obj method2];
    [lock unlock];
});

看到打印的结果了吗，你会看到线程1锁住之后，线程2会一直等待走到线程1将锁置为unlock后，才会执行method2方法。

NSLock是Cocoa提供给我们最基本的锁对象，这也是我们经常所使用的，除lock和unlock方法外，NSLock还提供了tryLock和lockBeforeDate:两个方法，前一个方法会尝试加锁，如果锁不可用(已经被锁住)，刚并不会阻塞线程，并返回NO。lockBeforeDate:方法会在所指定Date之前尝试加锁，如果在指定时间之前都不能加锁，则返回NO。

NSLock 只是在内部封装了一个 pthread_mutex，属性为 PTHREAD_MUTEX_ERRORCHECK，它会损失一定性能换来错误提示。理论上 NSLock 和 pthread_mutex 拥有相同的运行效率，实际由于封装的原因，会略慢一点，由于有缓存存在，相差不会很多，属于相同数量级。

NSRecursiveLock递归锁

平时我们在代码中使用锁的时候，最容易犯的一个错误就是造成死锁，而容易造成死锁的一种情形就是在递归或循环中，如下代码:

//主线程中
NSLock *theLock = [[NSLock alloc] init];
TestObj *obj = [[TestObj alloc] init];
//线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    static void(^TestMethod)(int);
    TestMethod = ^(int value)
    {
        [theLock lock];
        if (value > 0)
        {
            [obj method1];
            sleep(5);
            TestMethod(value-1);
        }
        [theLock unlock];
    };
    TestMethod(5);
});
//线程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    sleep(1);
    [theLock lock];
    [obj method2];
    [theLock unlock];
});

以上的代码中，就是一种典型的死锁情况，因为在线程1中的递归block中，锁会被多次的lock，所以自己也被阻塞了，由于以上的代码非常的简短，所以很容易能识别死锁，但在较为复杂的代码中，就不那么容易发现了，那么如何在递归或循环中正确的使用锁呢？

此处的theLock如果换用NSRecursiveLock对象，问题便得到解决了，NSRecursiveLock类定义的锁可以在同一线程多次lock，而不会造成死锁。递归锁会跟踪它被多少次lock。每次成功的lock都必须平衡调用unlock操作。只有所有的锁住和解锁操作都平衡的时候，锁才真正被释放给其他线程获得。

NSRecursiveLock 与 NSLock 的区别在于内部封装的 pthread_mutex_t 对象的类型不同，NSRecursiveLock 的类型为 PTHREAD_MUTEX_RECURSIVE。

NSCondition

顾明思意，条件锁，一种生产者—消费者模型。

它通常用于标明共享资源是否可被访问或者确保一系列任务能按照指定的执行顺序执行。如果一个线程试图访问一个共享资源，而正在访问该资源的线程将其条件设置为不可访问，那么该线程会被阻塞，直到正在访问该资源的线程将访问条件更改为可访问状态或者说给被阻塞的线程发送信号后，被阻塞的线程才能正常访问这个资源。

NSConditionLock条件锁

当我们在使用多线程的时候，有时一把只会lock和unlock的锁未必就能完全满足我们的使用。因为普通的锁只能关心锁与不锁，而不在乎用什么钥匙才能开锁，而我们在处理资源共享的时候，多数情况是只有满足一定条件的情况下才能打开这把锁：

//主线程中
NSConditionLock *theLock = [[NSConditionLock alloc] init];
//线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    for (int i=0;i<=2;i++)
    {
        [theLock lock];
        NSLog(@"thread1:%d",i);
        sleep(2);
        [theLock unlockWithCondition:i];
    }
});
//线程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    [theLock lockWhenCondition:2];
    NSLog(@"thread2");
    [theLock unlock];
});

在线程1中的加锁使用了lock，所以是不需要条件的，所以顺利的就锁住了，但在unlock的使用了一个整型的条件，它可以开启其它线程中正在等待这把钥匙的临界地，而线程2则需要一把被标识为2的钥匙，所以当线程1循环到最后一次的时候，才最终打开了线程2中的阻塞。

但即便如此，NSConditionLock也跟其它的锁一样，是需要lock与unlock对应的，只是lock,lockWhenCondition:与unlock，unlockWithCondition:是可以随意组合的，当然这是与你的需求相关的。

实际的实现原理就是里面封装了一个NSCondition对象，在lock时判断NSCondition对象的条件是否满足，不满足则wait，unlock时对发送NSCondition的broadcast，属于一个常见的生产者–消费者模型。

NSDistributedLock分布式锁

以上所有的锁都是在解决多线程之间的冲突，但如果遇上多个进程或多个程序之间需要构建互斥的情景该怎么办呢？这个时候我们就需要使用到NSDistributedLock了，从它的类名就知道这是一个分布式的Lock。

NSDistributedLock的实现是通过文件系统的，所以使用它才可以有效的实现不同进程之间的互斥，但NSDistributedLock并非继承于NSLock，它没有lock方法，它只实现了tryLock，unlock，breakLock，所以如果需要lock的话，你就必须自己实现一个tryLock的轮询，下面通过代码简单的演示一下吧：

程序A:

ispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    lock = [[NSDistributedLock alloc] initWithPath:@"/Users/mac/Desktop/earning__"];
    [lock breakLock];
    [lock tryLock];
    sleep(10);
    [lock unlock];
    NSLog(@"appA: OK");
});

程序B:

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    lock = [[NSDistributedLock alloc] initWithPath:@"/Users/mac/Desktop/earning__"];
    while (![lock tryLock]) {
        NSLog(@"appB: waiting");
        sleep(1);
    }
    [lock unlock];
    NSLog(@"appB: OK");
});

先运行程序A,然后立即运行程序B,根据打印你可以清楚的发现，当程序A刚运行的时候，程序B一直处于等待中，当大概10秒过后，程序B便打印出了appB:OK的输出，以上便实现了两上不同程序之间的互斥。

/Users/mac/Desktop/earning__是一个文件或文件夹的地址，如果该文件或文件夹不存在，那么在tryLock返回YES时，会自动创建该文件/文件夹。在结束的时候该文件/文件夹会被清除，所以在选择的该路径的时候，应该选择一个不存在的路径，以防止误删了文件。

参考：https://bestswifter.com/ios-lock/

多线程中的常见术语

条件(condition)
一个用来同步资源访问的结构。线程等待某一条件来决定是否被允许继续运行，直到其他线程显式的给该条件发送信号。
临界区(critical section)
同一时间只能不被一个线程执行的代码。
输入源(input source)
一个线程的异步事件源。输入源可以是基于端口的或手工触发，并且必须被附加到某一个线程的run loop上面。
可连接的线程(join thread)
退出时资源不会被立即回收的线程。可连接的线程在资源被回收之前必须被显式脱离或由其他线程连接。可连接线程提供了一个返回值给连接它的线程。
主线程(main thread)
当创建进程时一起创建的特定类型的线程。当程序的主线程退出，则程序即退出。
互斥锁(mutex)
提供共享资源互斥访问的锁。一个互斥锁同一时间只能被一个线程拥有。试图获取一个已经被其他线程拥有的互斥锁，会把当前线程置于休眠状态知道该锁被其他线程释放并让当前线程获得。
操作对象(operation object)
NSOperation类的实例。操作对象封装了和某一任务相关的代码和数据到一个执行单元里面。
操作队列(operation queue)
NSOperationQueue类的实例。操作队列管理操作对象的执行。
进程(process)
应用或程序的运行时实例。一个进程拥有独立于分配给其他程序的的内存空间和系统资源（包括端口权限）。进程总是包含至少一个线程（即主线程）和任意数量的额外线程。
递归锁(recursive lock)
可以被同一线程多次锁住的锁。
信号量(semaphore)
一个受保护的变量，它限制共享资源的访问。互斥锁(mutexes)和条件(conditions)都是不同类型的信号量。
任务(task)
要执行的工作数量。尽管一些技术(最显著的是Carbon 多进程服务—Carbon Multiprocessing Services)使用该术语的意义有时不同，但是最通用的用法是表明需要执行的工作数量的抽象概念。
线程(thread)
进程里面的一个执行过程流。每个线程都有它自己的栈空间，但除此之外同一进程的其他线程共享内存。

极致的技术博客

这是我用来记录平日学习笔记的地方，欢迎您的访问.