美文网首页iOS
iOS 锁的原理

iOS 锁的原理

作者: 木扬音 | 来源:发表于2021-06-20 16:06 被阅读0次
    • 【互斥锁】:用于多线程编程中,防止多条线程对统一资源读写,通过将代码切割成一个个临界区而达成

      • @synchronized
      • NSLock
      • pthread_mutex
    • 【自旋锁】:线程会一直检测锁变量是否可用,因为线程在这过程一直保持执行,所以线程会处于忙等状态,一旦获取了自旋锁,线程会一直持有该锁,直至显式释放自旋锁。

      • OSSpinLock
      • atomic
    • 【条件锁】条件变量,当进程中的某些资源要求不满足时就进入休眠,加锁,当资源分配到了就解锁,继续运行

      • NSCondition
      • pthread_mutex
    • 【递归锁】同一线程可以加锁很多次而不会死锁,带有递归性质的互斥锁

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

    • 【读写锁】特殊的自旋锁,并发性更高

    锁性能对比图

    OSSpinLock(自旋锁) --> dispatch_semaphore(信号量) --> phread_mutex(互斥锁) --> NSLock(互斥锁) --> NSCondition(条件锁) --> pthread_mutex(recursive)(互斥递归锁) --> NSRecursiveLock(递归锁) --> NSConditionLock(条件锁) --> @synchronized(互斥锁)

    1、OSSpinLock(自旋锁)

    自从OSSpinLock出现安全问题,在iOS10之后就被废弃了。自旋锁之所以不安全,是因为获取锁后,线程会一直处于忙等待,造成了任务的优先级反转

    其中的忙等待机制可能会造成高优先级任务一直running等待,占用时间片,而低优先级的任务无法抢占时间片,会造成一直不能完成,锁未释放的情况

    在OSSpinLock被弃用后,其替代方案是内部封装了os_unfair_lock,而os_unfair_lock在加锁时会处于休眠状态,而不是自旋锁的忙等状态

    2、atomic

    atomic是OC中的属性修饰符,自旋锁,在mac开发中使用的多

    setter方法

    在底层中setter方法会根据不同的属性修饰符调用不同方法,最后会统一调用reallySetProperty方法

    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加锁,spinlock在底层抛弃以前的OSSpinLock,使用os_unfair_lock替代实现加锁,同时为了防止哈希冲突,实现了加盐

    using spinlock_t = mutex_tt<LOCKDEBUG>;
    
    class mutex_tt : nocopy_t {
        os_unfair_lock mLock;
        ...
    }
    

    getter方法

    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、@synchronize(互斥递归锁)

    • 通过汇编调试,可以发现@synchronize在执行过程中,从objc_sync_enter开始到objc_sync_exit结束

      image.png
    • 通过clang查看底层编译

      image.png

    objc_sync_enter源码

    • 如果obj存在,通过id2data方法获取对应的SyncData,对threadCount、lockCount进行递增
    • 如果obj不存在,调用objc_sync_nil,可以通过下符号断点得知,改方法直接return了
    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;
    }
    

    objc_sync_exit源码

    • 如果obj存在,调用id2data获取对应的SyncData,对threadCount、lockCount进行递减
    • 如果obj不存在,直接return
    // 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;
    }
    

    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;
    

    SyncCache分析

    SyncCache也是结构体,用于存储线程,其中list[0]表示当前线程的链表data,主要存储SyncDatalockCount

    typedef struct {
        SyncData *data;
        unsigned int lockCount;  // number of times THIS THREAD locked this block
    } SyncCacheItem;
    
    typedef struct SyncCache {
        unsigned int allocated;
        unsigned int used;
        SyncCacheItem list[0];
    } SyncCache;
    

    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;
    }
    
    • 【第一步】在线程缓存中查找

      • tls_get_direct方法中传入线程Key,通过KVC的方式获得绑定的SyncData,其中tls()表示本地局部的线程缓存
      • 判断获取的线程data是否存在,以及线程data中是否能找到对应的object
      • 如果存在,在tls_get_direct方法中通过KVC方法获取lockCount,记录对象被锁几次(锁的嵌套次数)
      • 如果线程data中threadCount <= 0或者lockCount <= 0,直接奔溃
      • 通过传入的why判断操作类型
        • 如果是ACQUIRE,加锁,lockCount++,保存到线程缓存中
        • 如果是RELEASE,解锁,lockCount--,保存到线程缓存中,如果 lockCount==0,从线程缓存中移除
        • 如果是CHECK,什么也不做,直接return
    • 【第二步】在cache缓存中查找

      • 通过fetch_cache方法查找cache缓存中是否有线程
      • 如果有,遍历cache总表,对出线程对应的SyncCacheItem
      • SyncCacheItem中取出线程data
      • 判断线程data的后续操作和【第一步】判断一致
    • 【第三步】如果cache中也没有,即第一次进来,创建SyncData,并存储到线程缓存中

      • 如果cache中找到线程,且与object相等,则进行赋值、threadCount++
      • 如果cache没有找到线程,threadCount==1

    总结

    • @synchronized·在底层通过lockCount、threadCount,解决了递归互斥锁和嵌套可重用,所以这个锁是递归互斥锁`

    • 使用链表结构,方便下一个data插入

    • 由于底层中有链表查询、缓存查询和递归,所有内存和性能开销大,所有如果嵌套次数过多,会导致底层查找麻烦,非常耗费性能,但是使用简单,不用手动解锁

    • 不能使用非oc对象加锁,加锁对象应该一直存在内存中,不能中途释放,否则会奔溃

    • 底层流程

      • 【第一次进入,没有锁】

        • threadCount = 1、lockCount = 1
        • 存储到tls线程缓存
      • 【不是第一次进入,且是同一个线程】

        • tls线程缓存中有数据,则lockCount++
        • 存储到tls线程缓存

      -【不是第一次进入,且是不同线程】
      - 根据线程Key全局线程空间查找对应线程
      - threadCount ++、lockCount++
      - 存储到cache

    tls和cache缓存结构

    NSLock

    NSLock底层是封装了pthread_mutex,遵循了NSLocking协议,使用如下

    NSLock *lock = [[NSLock alloc] init];
    [lock lock];
    [lock unlock];
    
    • NSLock是简单的互斥锁,不能嵌套递归使用,不然会出现一直等待的情况

    NSRecursiveLock

    NSRecursiveLock递归互斥锁, 用于解决循环嵌套,在底层也是对pthread_mutex的封装,底层实现和NSLock一致,区别在init时候,NSRecursiveLock的标识是PTHREAD_MUTEX_RECURSIVE,而NSLock的标识是默认的

    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);
    

    NSCondition

    NSCondition条件锁,和信号量类似,线程需要满足条件才会继续执行,否则会堵塞等待,线程进入休眠,直到条件满足,常用于生成消费者模型

    • NSCondition对象实际是一个和一个线程检测器
      • :检测条件时保护数据源,执行条件时引发任务
      • 线程检测器:根据条件决定是否继续执行线程,否则阻塞
    • 底层也是pthread_mutex的封装
      • NSCondition是对mutexcond的一种封装(cond是一种用于访问和操作特定类型数据的指针)
    //初始化
    NSCondition *condition = [[NSCondition alloc] init]
    
    //一般用于多线程同时访问、修改同一个数据源,保证在同一 时间内数据源只被访问、修改一次,其他线程的命令需要在lock 外等待,只到 unlock ,才可访问
    [condition lock];
    
    //与lock 同时使用
    [condition unlock];
    
    //让当前线程处于等待状态
    [condition wait];
    
    //CPU发信号告诉线程不用在等待,可以继续执行
    [condition signal];
    

    NSConditionLock

    NSConditionLock条件锁,一旦一个线程获得锁,其他线程一定等待,其本质是NSCondition + Lock,是对NSCondition的封装,可以设置锁条件,而NSCondition只是信号的通知

    //初始化
    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就是整数,内部通过整数比较条件
    

    锁性能总结

    • OSSpinLock自旋锁由于安全性问题,在iOS10之后已经被废弃,在底层使用os_unfair_lock替代

      • OSSpinLock:线程会处于忙等状态
      • os_unfair_lock:线程会处于休眠状态
    • atomic原子锁,自带自旋锁,保证setter、getter方法的线程安全

      • 属性在调用setter、getter方法时,会自动加锁osspinlock自旋锁,避免属性读写不同步
    • @synchronized在底层维护了一个哈希表用来存在线程data,通过链表表示可重用(嵌套)特性,性能低,但是简单好用,多线程下适用性强

    • NSLock、NSRecursiveLock是互斥锁,底层都是对pthread_mutex的封装,区别在于init时的标识符不一样NSLock不能用于嵌套递归,而NSRecursiveLock可以

    • NSCondition 、NSConditionLock是条件锁,底层都是对pthread_mutex的封装,当满足某一个条件时才能进行操作,和信号量dispatch_semaphore类似

    相关文章

      网友评论

        本文标题:iOS 锁的原理

        本文链接:https://www.haomeiwen.com/subject/jwqhyltx.html