【iOS】锁的原理

前言

上一篇的博客我们学习和梳理了一些关于多线程的基础知识，在使用多线程的时候，我们为了保证线程安全会使用锁，这篇文章我们来探索一下锁的使用原理

锁

锁的性能

从上图我们可以得知锁的性能从高到低依次为：OSSpinLock(自旋锁) -> dispatch_semaphone（信号量） -> pthread_mutex（互斥锁） -> NSLock（互斥锁） -> NSCondition（条件锁） -> pthread_mutex（recursive 互斥递归锁） -> NSRecursiveLock（递归锁） -> NSConditionLock（条件锁） -> synchronized（互斥锁）

锁的归类

自旋锁

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

OSSpinLock
atomic

互斥锁

互斥锁是一种用于多线程编程中，防止两条线程同时对同一公共资源（例如全局变量）进行读写的机制，该目的是通过将代码切成一个个临界区而达成。当获取锁操作失败时，线程会进入睡眠，等待锁释放时被唤醒

pthread_mutex
NSLock
@synchronized

条件锁

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

NSCondition
NSConditionLock

递归锁

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

pthread_mutex(recursive)
NSRecursiveLock

信号量

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

dispatch_semaphore

读写锁

读写锁是一种高级的线程同步机制，它通过区分读操作 和写操作 来优化并发性能，特别适合读多写少的场景。核心工作原理如下图：

总结

其实在iOS中锁的基本种类只有两种：互斥锁、自旋锁，其他的比如条件锁、递归锁、信号量都是上层的封装和实现

细说锁

自旋锁

OSSpinLock

这是一个不安全的锁，在iOS10之后就被废弃了，不安全的原因是：在获取锁后，线程会一直处于忙等待，可能造成任务优先级的反转。

自旋锁的工作原理是，在一个线程尝试获取已被其他线程占有的自旋锁时不会被阻塞，而是在一个小的循环中一直检查锁的状态，直到获取到锁，这种机制称为"忙等待"。

这种机制可能造成的问题是：假设有一个低优先级任务持有一个锁，而一个高优先级任务在等待获取这个锁，通常情况下高优先级任务应该可以抢占低优先级任务的时间片，但是由于低优先级任务一直在忙等待中运行，它会一直占用CPU时间片 ，高优先级任务无法抢占，从而就导致了优先级反转

也就是说使用OSSpinLock会导致低优先级任务先执行

os_unfair_lock

os_unfair_lock被苹果用来解决OSSpinLock不够安全的问题

objectivec 复制代码

//创建一个锁
os_unfair_lock_t unfairLock;
//初始化
unfairLock = &(OS_UNFAIR_LOCK_INIT);
//加锁
os_unfair_lock_lock(unfairLock);
//解锁
os_unfair_lock_unlock(unfairLock);

可以看到不会再发生优先级反转

atomic

atomic 是OC属性的修饰符，自带一把自旋锁，但一般都不使用atomic ，而使用nonatomic

根据属性关键字的不同，setter和getter方法会调用不同的方法，但最后会统一调用reallySetProperty

这里就根据是否是atomic分别进行了是否有锁的操作。

互斥锁

pthread_mutex

pthread_mutex就是互斥锁本身

objectivec 复制代码

// 导入头文件
#import <pthread.h>

// 全局声明互斥锁
pthread_mutex_t _lock;

// 初始化互斥锁
pthread_mutex_init(&_lock, NULL);

// 加锁
pthread_mutex_lock(&_lock);
// 这里做需要线程安全操作
// 解锁 
pthread_mutex_unlock(&_lock);

// 释放锁
pthread_mutex_destroy(&_lock);

@synchronized（互斥递归锁）

@synchronized可能是日常开发中用的比较多的一种互斥锁，因为它的使用比较简单，但并不是在任意场景下都能使用@synchronized，且它的性能较低

@synchronized源码的实现核心就是objc_sync_enter和objc_sync_exit两个函数

首先看objc_sync_enter函数：

如果obj存在，则通过id2data方法获取相应的SyncData，对threadCount、lockCount进行递增操作
如果obj不存在，则调用objc_sync_nil，通过符号断点可知，这个方法里面什么都没做，直接return了

objc_sync_exit函数：

如果obj存在，则调用id2data方法获取对应的SyncData，对threadCount、lockCount进行递减操作
如果obj为nil，什么也不做

这两个方法的共同点是：当obj存在时，通过id2data方法，获取SyncData

SyncData

SyncData是一个结构体，主要用来表示一个线程data，类似于链表结构，有next指向，且封装了recursive_mutex_t属性，可以确认@synchronized确实是一个递归互斥锁

另一个相关的结构体SyncCache，用于存储线程，其中list[0]表示当前线程的链表data，主要用于存储SyncData和lockCount

id2data 分析

id2data方法是加锁和解锁都复用的方法

objectivec 复制代码

static SyncData* id2data(id object, enum usage why)
{
    spinlock_t *lockp = &LOCK_FOR_OBJ(object);
    SyncData **listp = &LIST_FOR_OBJ(object);
    SyncData* result = NULL;

#if SUPPORT_DIRECT_THREAD_KEYS
    // Check per-thread single-entry fast cache for matching object
    bool fastCacheOccupied = NO;
    //通过KVC方式对线程进行获取 线程绑定的data
    SyncData *data = (SyncData *)tls_get_direct(SYNC_DATA_DIRECT_KEY);
    //如果线程缓存中有data，执行if流程
    if (data) {
        fastCacheOccupied = YES;
        //如果在线程空间找到了data
        if (data->object == object) {
            // Found a match in fast cache.
            uintptr_t lockCount;

            result = data;
            //通过KVC获取lockCount，lockCount用来记录 被锁了几次，即 该锁可嵌套
            lockCount = (uintptr_t)tls_get_direct(SYNC_COUNT_DIRECT_KEY);
            if (result->threadCount <= 0  ||  lockCount <= 0) {
                _objc_fatal("id2data fastcache is buggy");
            }

            switch(why) {
            case ACQUIRE: {
                //objc_sync_enter走这里，传入的是ACQUIRE -- 获取
                lockCount++;//通过lockCount判断被锁了几次，即表示可重入（递归锁如果不可重入，会死锁）
                tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);
                break;
            }
            case RELEASE:
                //objc_sync_exit走这里，传入的why是RELEASE -- 释放
                lockCount--;
                tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);
                if (lockCount == 0) {
                    // remove from fast cache
                    tls_set_direct(SYNC_DATA_DIRECT_KEY, NULL);
                    // atomic because may collide with concurrent ACQUIRE
                    OSAtomicDecrement32Barrier(&result->threadCount);
                }
                break;
            case CHECK:
                // do nothing
                break;
            }

            return result;
        }
    }
#endif

    // Check per-thread cache of already-owned locks for matching object
    SyncCache *cache = fetch_cache(NO);//判断缓存中是否有该线程
    //如果cache中有，方式与线程缓存一致
    if (cache) {
        unsigned int i;
        for (i = 0; i < cache->used; i++) { //遍历总表
            SyncCacheItem *item = &cache->list[i];
            if (item->data->object != object) continue;

            // Found a match.
            result = item->data;
            if (result->threadCount <= 0  ||  item->lockCount <= 0) {
                _objc_fatal("id2data cache is buggy");
            }
                
            switch(why) {
            case ACQUIRE: //加锁
                item->lockCount++;
                break;
            case RELEASE: //解锁
                item->lockCount--;
                if (item->lockCount == 0) {
                    // remove from per-thread cache 从cache中清除使用标记
                    cache->list[i] = cache->list[--cache->used];
                    // atomic because may collide with concurrent ACQUIRE
                    OSAtomicDecrement32Barrier(&result->threadCount);
                }
                break;
            case CHECK:
                // do nothing
                break;
            }

            return result;
        }
    }

    // Thread cache didn't find anything.
    // Walk in-use list looking for matching object
    // Spinlock prevents multiple threads from creating multiple 
    // locks for the same new object.
    // We could keep the nodes in some hash table if we find that there are
    // more than 20 or so distinct locks active, but we don't do that now.
    //第一次进来，所有缓存都找不到
    lockp->lock();

    {
        SyncData* p;
        SyncData* firstUnused = NULL;
        for (p = *listp; p != NULL; p = p->nextData) { //cache中已经找到
            if ( p->object == object ) { //如果不等于空，且与object相似
                result = p; //赋值
                // atomic because may collide with concurrent RELEASE
                OSAtomicIncrement32Barrier(&result->threadCount); //对threadCount进行++
                goto done;
            }
            if ( (firstUnused == NULL) && (p->threadCount == 0) )
                firstUnused = p;
        }
    
        // no SyncData currently associated with object 没有与当前对象关联的SyncData
        if ( (why == RELEASE) || (why == CHECK) )
            goto done;
    
        // an unused one was found, use it 第一次进来，没有找到
        if ( firstUnused != NULL ) {
            result = firstUnused;
            result->object = (objc_object *)object;
            result->threadCount = 1;
            goto done;
        }
    }

    // Allocate a new SyncData and add to list.
    // XXX allocating memory with a global lock held is bad practice,
    // might be worth releasing the lock, allocating, and searching again.
    // But since we never free these guys we won't be stuck in allocation very often.
    posix_memalign((void **)&result, alignof(SyncData), sizeof(SyncData));//创建赋值
    result->object = (objc_object *)object;
    result->threadCount = 1;
    new (&result->mutex) recursive_mutex_t(fork_unsafe_lock);
    result->nextData = *listp;
    *listp = result;
    
 done:
    lockp->unlock();
    if (result) {
        // Only new ACQUIRE should get here.
        // All RELEASE and CHECK and recursive ACQUIRE are 
        // handled by the per-thread caches above.
        if (why == RELEASE) {
            // Probably some thread is incorrectly exiting 
            // while the object is held by another thread.
            return nil;
        }
        if (why != ACQUIRE) _objc_fatal("id2data is buggy");
        if (result->object != object) _objc_fatal("id2data is buggy");

#if SUPPORT_DIRECT_THREAD_KEYS
        if (!fastCacheOccupied) { //判断是否支持栈存缓存，支持则通过KVC形式赋值 存入tls
            // Save in fast thread cache
            tls_set_direct(SYNC_DATA_DIRECT_KEY, result);
            tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)1);
        } else 
#endif
        {
            // Save in thread cache 缓存中存一份
            if (!cache) cache = fetch_cache(YES);//第一次存储时，对线程进行了绑定
            cache->list[cache->used].data = result;
            cache->list[cache->used].lockCount = 1;
            cache->used++;
        }
    }

    return result;
}


BREAKPOINT_FUNCTION(
    void objc_sync_nil(void)
);

1.首先在tls即线程缓存中查找
- 在tls_get_direct方法中以线程为key，通过KVC的方式获取与之绑定的SyncData，即线程data.其中的tls（），表示本地局部的线程缓存.
- 判断获取的data是否存在，以及判断data中是否能找到对应的object.
- 如果都找到了，在tls_get_direct方法中以KVC的方式获取lockCount，用来记录对象被锁了几次（即锁的嵌套次数）.
- 如果data中的threadCount 小于等于0，或者 lockCount 小于等于0时，则直接崩溃.
- 通过传入的why判断操作类型
  - 如果是ACQUIRE，表示加锁，则进行lockCount++，并保存到tls缓存.
  - 如果是RELEASE，表示释放，则进行lockCount--，并保存到tls缓存.如果lockCount 等于 0，从tls中移除线程data.
  - 如果是CHECK，则什么也不做.
2.如果tls

中没有，则在cache缓存中查找。
- 通过fetch_cache方法查找cache缓存中是否有线程
- 如果有，则遍历cache总表，读取出线程对应的SyncCacheItem
- 从SyncCacheItem中取出data，然后后续步骤与tls的匹配是一致的
3.如果cache中也没有，即第一次进来，则创建SyncData，并存储到相应缓存中
- 如果在cache中找到线程，且与object相等，则进行赋值、以及threadCount++
- 如果在cache中没有找到，则threadCount等于1

所以在id2data方法中，主要分为三种情况：

1.第一次进来，没有锁
- threadCount = 1
- lockCount = 1
- 存储到tls
2.不是第一次进来，且是同一个线程
- tls中有数据，则lockCount++
- 存储到tls
3.不是第一次进来，且是不同线程
- 全局线程空间进行查找线程
- threadCount++
- lockCount++
- 存储到cache

总结

因为@synchronized在底层封装的是一把递归锁，所以这个锁是递归互斥锁
@synchronized使用链表的原因是为了方便下一个data的插入
由于链表的查询与缓存的查找十分消耗性能，因此该锁的性能排名比较低下
但是因为使用起来方便简单，不用解锁，使用率还是比较高的
不能用非OC对象作为加锁对象，因为object的参数为id
@synchronized (self)这种适用于嵌套次数较少的场景。这里锁住的对象也并不永远是self，这里需要读者注意

NSLock

对于嵌套次数较多的情况，我们就可以使用NSLock来避免@synchronized导致的性能下降的问题

NSLock是对下层pthread_mutex的封装，因此也是一个非递归互斥锁

在使用非递归锁时,如果发生了递归调用,线程不会死锁,而是会被阻塞(堵塞)

从苹果官方文档中可知：在同一线程上调用NSLock的两次lock方法将永久锁定线程

NSLock的使用如下：

NSRecursiveLock

NSRecursiveLock是NSLock的子类，在底层也是对pthread_mutex的封装，区别在于它允许同一个线程多次对锁进行加锁操作而不会造成死锁。

但是在不同线程获取同一把锁时，仍然有可能造成死锁

条件锁

NSCondition

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

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

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

基本使用：

来看一个典型的生产者-消费者的例子

如果产品不足就用wait告诉当前线程需要等待，也就是阻塞线程，直到signal通知线程可以继续往下走

(void)wait 阻塞当前线程，使线程进入休眠，等待唤醒信号。调用前必须已加锁。
(void)waitUntilDate 阻塞当前线程，使线程进入休眠，等待唤醒信号或者超时。调用前必须已加锁。
(void)signal 唤醒一个正在休眠的线程，如果要唤醒多个，需要调用多次。如果没有线程在等待，则什么也不做。调用前必须已加锁。
(void)broadcast 唤醒所有在等待的线程。如果没有线程在等待，则什么也不做。调用前必须已加锁。

NSConditionLock

NSConditionLock是条件锁，一旦一个线程获得锁，其他线程一定等待，其本质就是NSCondition + Lock ，基本使用：

实际使用的示例如下：

锁的使用场景

如果只是简单的使用，例如涉及线程安全，使用NSLock即可
如果是循环嵌套，推荐使用@synchronized，主要是因为使用递归锁的性能不如使用@synchronized的性能（因为在@synchronized中无论怎么重入，都没有关系，而NSRecursiveLock可能会出现崩溃现象）
在循环嵌套中，如果对递归锁掌握的很好，则建议使用递归锁，因为性能好
如果是循环嵌套，并且还有多线程影响时，例如有等待、死锁现象时，建议使用@synchronized