iOS-底层原理27：锁的原理

作者: AcmenL | 来源:发表于2021-04-05 21:50 被阅读0次

本文主要介绍常见的锁，以及synchronized、NSLock、递归锁、条件锁的底层分析

锁

借鉴一张锁的性能数据对比图，如下所示：

锁性能对比

可以看出，图中锁的性能从高到底依次是：OSSpinLock(自旋锁) > dispatch_semaphone(信号量) > pthread_mutex(互斥锁) > NSLock(互斥锁) > NSCondition(条件锁) -> pthread_mutex(recursive 互斥递归锁) > NSRecursiveLock(递归锁) > NSConditionLock(条件锁) > synchronized(互斥锁)

图中的锁大致可以分为以下几类：

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

* OSSpinLock
* atomic

2、【互斥锁】互斥锁是一种用于多线程编程中，防止两条线程同时对同一公共资源（例如全局变量）进行读写的机制，该目的是通过将代码切成一个个临界区而达成

* @synchronized
* NSLock
* pthread_mutex

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

* NSCondition
* NSConditionLock

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

* pthread_mutex(recursive)
* NSRecursiveLock

5、【信号量】信号量是一种更高级的同步机制，互斥锁可以说是semaphore在仅取值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;
    ...
}

getter方法中对atomic的处理，同setter是大致相同的

id objc_getProperty(id self, SEL _cmd, ptrdiff_t offset, BOOL atomic) {
    if (offset == 0) {
        return object_getClass(self);
    }

    // Retain release world
    id *slot = (id*) ((char*)self + offset);
    if (!atomic) return *slot;
        
    // Atomic retain release world
    spinlock_t& slotlock = PropertyLocks[slot];
    slotlock.lock();//加锁
    id value = objc_retain(*slot);
    slotlock.unlock();//解锁
    
    // for performance, we (safely) issue the autorelease OUTSIDE of the spinlock.
    return objc_autoreleaseReturnValue(value);
}

3、synchronized（互斥递归锁）

step1: 开启汇编调试，发现@synchronized在执行过程中，会走底层的objc_sync_enter 和 objc_sync_exit方法

可以通过clang查看底层代码

step2: 通过对objc_sync_enter方法符号断点，查看底层所在的源码库，通过断点发现在objc源码中，即libobjc.A.dylib

3.1 objc_sync_enter & objc_sync_exit 分析

step1: 进入objc_sync_enter源码实现

int objc_sync_enter(id obj)
{
    int result = OBJC_SYNC_SUCCESS;

    if (obj) {//传入不为nil
        SyncData* data = id2data(obj, ACQUIRE);//重点
        ASSERT(data);
        data->mutex.lock();//加锁
    } else {//传入nil
        // @synchronized(nil) does nothing
        if (DebugNilSync) {
            _objc_inform("NIL SYNC DEBUG: @synchronized(nil); set a breakpoint on objc_sync_nil to debug");
        }
        objc_sync_nil();
    }

    return result;
}

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

step2: 进入objc_sync_exit源码实现

// End synchronizing on 'obj'. 结束对“ obj”的同步
// Returns OBJC_SYNC_SUCCESS or OBJC_SYNC_NOT_OWNING_THREAD_ERROR
int objc_sync_exit(id obj)
{
    int result = OBJC_SYNC_SUCCESS;
    
    if (obj) {//obj不为nil
        SyncData* data = id2data(obj, RELEASE); 
        if (!data) {
            result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
        } else {
            bool okay = data->mutex.tryUnlock();//解锁
            if (!okay) {
                result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
            }
        }
    } else {//obj为nil时，什么也不做
        // @synchronized(nil) does nothing
    }
    return result;
}

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

通过上面两个实现逻辑的对比，发现它们有一个共同点，在obj存在时，都会通过id2data方法，获取SyncData

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

typedef struct alignas(CacheLineSize) SyncData {
    struct SyncData* nextData;//类似链表结构
    DisguisedPtr<objc_object> object;
    int32_t threadCount;  // number of THREADS using this block
    recursive_mutex_t mutex;//递归锁
} SyncData;

3.2 id2data 分析

进入id2data源码，从上面的分析，可以看出，这个方法是加锁和解锁都复用的方法

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 //tls（Thread Local Storage，本地局部的线程缓存）
    // 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);//lockCount = 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;
}

//未完

iOS-底层原理27：锁的原理

锁

1、OSSpinLock（自旋锁）

2、atomic（原子锁）

3、synchronized（互斥递归锁）

3.1 objc_sync_enter & objc_sync_exit 分析

3.2 id2data 分析

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

iOS