美文网首页底层
iOS-OC底层23:锁的原理

iOS-OC底层23:锁的原理

作者: MonKey_Money | 来源:发表于2020-11-11 16:51 被阅读0次

    概念

    自旋锁:

    线程反复检查锁变量是否可用。由于线程在这一过程中保持执行, 因此是一种忙等待。一旦获取了自旋锁,线程会一直保持该锁,直至显式释 放自旋锁。 自旋锁避免了进程上下文的调度开销,因此对于线程只会阻塞很 短时间的场合是有效的。###互斥锁
    是一种用于多线程编程中,防止两条线程同时对同一公共资源(比 如全局变量)进行读写的机制。该目的通过将代码切片成一个一个的临界区而达成。互斥锁有NSLock,pthread_mutex,@synchronized

    条件锁:

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

    递归锁

    就是同一个线程可以加锁N次而不会引发死锁,NSRecursiveLock,pthread_mutex(recursive)

    信号量(semaphore)

    是一种更高级的同步机制,互斥锁可以说是semaphore在仅取值0/1时的特例。信号量可以有更多的取值空间,用来实现更加复杂的同步,而不单单是线程间互斥。dispatch_semaphore
    其实基本的锁就包括了三类 自旋锁 互斥锁 读写锁,
    其他的比如条件锁,递归锁,信号量都是上层的封装和实现!

    读写锁

    读写锁实际是一种特殊的自旋锁,它把对共享资源的访问者划分成读者和写者,读者只对共享资源 进行读访问,写者则需要对共享资源进行写操作。这种锁相对于自旋锁而言,能提高并发性,因为在多处理器系统中,它允许同时有多个读者来访问共享资源,最大可能的读者数为实际的逻辑CPU 数。写者是排他性的,一个读写锁同时只能有一个写者或多个读者(与CPU数相关),但不能同时既有读者又有写者。在读写锁保持期间也是抢占失效的。
    如果读写锁当前没有读者,也没有写者,那么写者可以立刻获得读写锁,否则它必须自旋在那里,直到没有任何写者或读者。如果读写锁没有写者,那么读者可以立即获得该读写锁,否则读者必须自旋在那里,直到写者释放该读写锁。
    一次只有一个线程可以占有写模式的读写锁, 但是可以有多个线程同时占有读模式的读写锁. 正是因为这个特性,当读写锁是写加锁状态时, 在这个锁被解锁之前, 所有试图对这个锁加锁的线程都会被阻塞.当读写锁在读加锁状态时, 所有试图以读模式对它进行加锁的线程都可以得到访问权, 但是如果线程希望以写模式对此锁进行加锁, 它必须直到所有的线程释放锁.通常, 当读写锁处于读模式锁住状态时, 如果有另外线程试图以写模式加锁, 读写锁通常会阻塞随后的读模式锁请求, 这样可以避免读模式锁⻓期占用, 而等待的写模式锁请求⻓期阻塞.
    读写锁适合于对数据结构的读次数比写次数多得多的情况. 因为, 读模式锁定时可以共享, 以写模式锁住时意味着独占, 所以读写锁又叫共享-独占锁.

    include <pthread.h>

    int pthread_rwlock_init(pthread_rwlock_t *restrict rwlock, const pthread_rwlockattr_t *restrict attr);
    int pthread_rwlock_destroy(pthread_rwlock_t *rwlock)
    成功则返回0, 出错则返回错误编号.
    同互斥量以上, 在释放读写锁占用的内存之前, 需要先通过pthread_rwlock_destroy对读写锁进行清理工作, 释
    放由init分配的资源.

    include <pthread.h>

    int pthread_rwlock_rdlock(pthread_rwlock_t *rwlock);
    int pthread_rwlock_wrlock(pthread_rwlock_t *rwlock);
    int pthread_rwlock_unlock(pthread_rwlock_t *rwlock);
    成功则返回0, 出错则返回错误编号.
    这3个函数分别实现获取读锁, 获取写锁和释放锁的操作. 获取锁的两个函数是阻塞操作, 同样, 非阻塞的函数为:

    include <pthread.h>

    int pthread_rwlock_tryrdlock(pthread_rwlock_t *rwlock);
    int pthread_rwlock_trywrlock(pthread_rwlock_t *rwlock);
    成功则返回0, 出错则返回错误编号.
    非阻塞的获取锁操作, 如果可以获取则返回0, 否则返回错误的EBUSY.


    image.png

    synchronized

    没用synchronized之前

    - (void)lg_testSaleTicket{
        dispatch_async(dispatch_get_global_queue(0, 0), ^{
            for (int i = 0; i < 5; i++) {
                [self saleTicket];
            }
        });
        
        dispatch_async(dispatch_get_global_queue(0, 0), ^{
            for (int i = 0; i < 5; i++) {
                [self saleTicket];
            }
        });
        
        dispatch_async(dispatch_get_global_queue(0, 0), ^{
            for (int i = 0; i < 3; i++) {
                [self saleTicket];
            }
        });
        
        dispatch_async(dispatch_get_global_queue(0, 0), ^{
            for (int i = 0; i < 10; i++) {
                [self saleTicket];
            }
        });
    }
    - (void)saleTicket{        
            if (self.ticketCount > 0) {
                self.ticketCount--;
                sleep(0.1);
                NSLog(@"当前余票还剩:%ld张",self.ticketCount);
                
            }else{
                NSLog(@"当前车票已售罄");
            }
    }
    

    打印结果

     当前余票还剩:19张
     当前余票还剩:18张
    当前余票还剩:16张
    当前余票还剩:16张
    乱序执行
    当前余票还剩:4张
     当前余票还剩:3张
     当前余票还剩:2张
     当前余票还剩:2张
     当前余票还剩:1张
     当前余票还剩:0张
     当前车票已售罄
    

    修改后

    - (void)saleTicket{
        @synchronized (self) {
            
            if (self.ticketCount > 0) {
                self.ticketCount--;
                sleep(0.1);
                NSLog(@"当前余票还剩:%ld张",self.ticketCount);
                
            }else{
                NSLog(@"当前车票已售罄");
            }
    
        }
    
    }
    //打印结果
    当前余票还剩:19
    当前余票还剩:18
    //顺序执行
    当前余票还剩:1
    当前余票还剩:0
    当前车票已售罄
    当前车票已售罄
    当前车票已售罄
    

    synchronized到底做了什么事呢?下面我们来探索一下
    通过clang看synchronized的实现过程

    int main2(){
        NSObject *objec = [NSObject new];
        @synchronized (objec) {
            
        }
        return  1;
    }
    clang后
        NSObject *objec = ((NSObject *(*)(id, SEL))(void *)objc_msgSend)((id)objc_getClass("NSObject"), sel_registerName("new"));
        { id _rethrow = 0; id _sync_obj = (id)objec; objc_sync_enter(_sync_obj);
    try {
        struct _SYNC_EXIT { _SYNC_EXIT(id arg) : sync_exit(arg) {}
        ~_SYNC_EXIT() {objc_sync_exit(sync_exit);}
        id sync_exit;
        } _sync_exit(_sync_obj);
    
    
        } catch (id e) {_rethrow = e;}
    { struct _FIN { _FIN(id reth) : rethrow(reth) {}
        ~_FIN() { if (rethrow) objc_exception_throw(rethrow); }
        id rethrow;
        } _fin_force_rethow(_rethrow);}
    }
    

    首先下符号断点确定objc_sync_enter和objc_sync_exit所在的库,可知在libobjc.A.dylib,然后看源码

    objc_sync_enter

    int objc_sync_enter(id obj)
    {
        int result = OBJC_SYNC_SUCCESS;
    
        if (obj) {
            SyncData* data = id2data(obj, ACQUIRE);
            ASSERT(data);
            data->mutex.lock();
        } else {
            // @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获取一个对象data,然后对data的mutex进行lock,如果obj没有值,@synchronized(nil)什么都不做

    objc_sync_exit

    int objc_sync_exit(id obj)
    {
        int result = OBJC_SYNC_SUCCESS;
        
        if (obj) {
            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 {
            // @synchronized(nil) does nothing
        }
        
        return result;
    }
    

    如果obj为nil,则@synchronized加锁失败,if通过id2data取到的data为空则返回
    OBJC_SYNC_NOT_OWNING_THREAD_ERROR,如果data的mutex开锁失败也返回OBJC_SYNC_NOT_OWNING_THREAD_ERROR,成功则返回OBJC_SYNC_SUCCESS。

    对重要函数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
        // Check per-thread single-entry fast cache for matching object
        bool fastCacheOccupied = NO;
        SyncData *data = (SyncData *)tls_get_direct(SYNC_DATA_DIRECT_KEY);
        if (data) {
            fastCacheOccupied = YES;
    
            if (data->object == object) {
                // Found a match in fast cache.
                uintptr_t lockCount;
    
                result = data;
                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: {
                    lockCount++;
                    tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);
                    break;
                }
                case 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);
        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->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) {
                if ( p->object == object ) {
                    result = p;
                    // atomic because may collide with concurrent RELEASE
                    OSAtomicIncrement32Barrier(&result->threadCount);
                    goto done;
                }
                if ( (firstUnused == NULL) && (p->threadCount == 0) )
                    firstUnused = p;
            }
        
            // no SyncData currently associated with object
            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) {
                // 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;
    }
    

    1.第一次objc_sync_enter
    从线程局部存储中寻找,没有找到从fetch_cache中也没有找到,listp也没有该对象的元素,则重新创建,然后存储起来。
    2.同一线程同一对象第二次objc_sync_enter
    可以从线程局部存储(TS L)中直接找到,然后对lockCount++,存储都tls中
    3.不同线程的同一个对象objc_sync_enter
    因为不是同一线程,我们无法从tsl中直接找到,在fetch_cache能找不到,因为fetch_cache也是在tsl中找的,遍历对象的listp列表,对对象的threadCount加1.
    4.不同线程的同一个对象objc_sync_exit
    我们能从fetch_cache找到对象,然后对lockCount减1,如果threadCount和lockCount都等于0,则让threadCount减去1

    SyncData对象分析

    recursive_mutex_t 递归互斥锁
    nextData 形成连表效果
    threadCount 记录线程个数。
    object 存储对象的hash值

    synchronized注意点

    1.synchronized 性能问题,
    2.synchronized锁的对象的声明周期
    3.如果在多个地方synchronized同一个对象,则查找更慢,性能更差

    TLS 线程相关解释

    线程局部存储(Thread Local Storage,TLS): 是操作系统为线程单独提供的私有空间,通常只有有限的容量。Linux系统下通常通过pthread库中的
    pthread_key_create()、pthread_getspecific()、pthread_setspecific()、pthread_key_delete()

    代码示例

    - (void)lg_testRecursive{
     
        for (int i= 0; i<100; i++) {
            
            dispatch_async(dispatch_get_global_queue(0, 0), ^{
    
                static void (^testMethod)(int);
    
                testMethod = ^(int value){
                        if (value > 0) {
                          NSLog(@"current value = %d",value);
                          testMethod(value - 1);
                        }
                    
                };
                testMethod(10);
            });
        }  
    }
    

    打印结果可想可知,杂乱无章。我们想让有规律的打印
    1.用NSLock加锁
    如果我们这样加锁

                testMethod = ^(int value){
                    [lock lock];
                        if (value > 0) {
                          NSLog(@"current value = %d",value);
                          testMethod(value - 1);
                        }
                    [lock unlock];         
                };
    
    

    我们只能得到打印10,这是为什么呢?通过分析我们一直在层层加锁,而没有解锁,
    我们修改加锁方式

                [lock lock];
                testMethod(10);
                [lock unlock];
    
    

    但是这种会出现堵塞,因为只有每次循环完从10到1再第一次循环。
    2.我们用NSRecursiveLock加锁

        for (int i= 0; i<100; i++) {       
            dispatch_async(dispatch_get_global_queue(0, 0), ^{
                static void (^testMethod)(int);
                [recursiveLock lock];
                testMethod = ^(int value){
                    if (value > 0) {
                      NSLog(@"current value = %d",value);
                      testMethod(value - 1);
                    }
                    [recursiveLock unlock];
                };
                testMethod(10);
            });
        }
    

    打印正常

    NSLock底层实现

    NSLock是Foundation的类,由于OC的Foundation没有开源,我们看swift源码。
    NSLock遵循NSLocking协议

    public protocol NSLocking {
        func lock()
        func unlock()
    }
    

    NSLock底层封装了pthread_mutex所以NSLcok是互斥锁
    NSLock的lock:实际上是对pthread_mutex进行锁操作。
    NSLock的unlock:对pthread_mutex解锁并进行广播。

    NSRecursiveLock的底层实现

    NSRecursiveLock的实现和NSLock大致相同,只是在随pthread_mutex初始化的时候设置了递归参数

     pthread_mutexattr_init(attrs)
      pthread_mutexattr_settype(attrs, Int32(PTHREAD_MUTEX_RECURSIVE))
       pthread_mutex_init(mutex, attrs)
    

    NSCondition使用和底层实现

    NSCondition使用

    NSCondition的使用是在卖烧饼,当有烧饼时才会卖给顾客,如果没有烧饼,顾客要等一会。如果没有顾客,店主也会做。

    - (void)lg_testConditon{
            _testCondition = [[NSCondition alloc] init];
        //创建生产-消费者
        for (int i = 0; i < 50; i++) {
            dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
                [self lg_producer];
            });
            dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
                [self lg_consumer];
            });
            
            dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
                [self lg_consumer];
            });
            dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
                [self lg_producer];
            });
            
        }
    }
    
    - (void)lg_producer{
         [_testCondition lock];
        self.ticketCount = self.ticketCount + 1;
        NSLog(@"生产一个 现有 count %zd",self.ticketCount);
        [_testCondition signal];
        [_testCondition unlock];
    
    }
    - (void)lg_consumer{
        
        // 线程安全
         [_testCondition lock];
        if (self.ticketCount == 0) {
            NSLog(@"等待 count %zd",self.ticketCount);
            // 保证正常流程
             [_testCondition wait];
        }
        self.ticketCount -= 1;
        NSLog(@"消费一个 还剩 count %zd ",self.ticketCount);
        [_testCondition unlock];
    }
    

    NSCondition的底层实现

    NSCondition是对pthread_mutex和pthread_cond的封装
    lock和unlock是对pthread_mutex的操作。
    wait和signal是对pthread_cond的wait和signal操作。
    broadcast对pthread_cond_broadcast,对cond进行signal,唤醒所有等待的线程
    NSCondition 的对象实际上作为一个锁和一个线程检查器:锁主要 为了当检测条件时保护数据源,执行条件引发的任务;线程检查器 主要是根据条件决定是否继续运行线程,即线程是否被阻塞
    1:[condition lock];//一般用于多线程同时访问、修改同一个数据源,保证在同一 时间内数据源只被访问、修改一次,其他线程的命令需要在lock 外等待,只到 unlock ,才可访问
    2:[condition unlock];//与lock 同时使用
    3:[condition wait];//让当前线程处于等待状态
    4:[condition signal];//CPU发信号告诉线程不用在等待,可以继续执行

    NSConditionLock

    NSConditionLock的底层是对NSCondition的封装
    1.1 NSConditionLock 是锁,一旦一个线程获得锁,其他线程一定等待
    1.2 [xxxx lock]; 表示 xxx 期待获得锁,如果没有其他线程获得锁(不需要判断内部的 condition) 那它能执行此行以下代码,如果已经有其他线程获得锁(可能是条件锁,或者无条件 锁),则等待,直至其他线程解锁
    1.3 [xxx lockWhenCondition:A条件]; 表示如果没有其他线程获得该锁,但是该锁内部的 condition不等于A条件,它依然不能获得锁,仍然等待。如果内部的condition等于A条件,并且 没有其他线程获得该锁,则进入代码区,同时设置它获得该锁,其他任何线程都将等待它代码的 完成,直至它解锁。
    1.4 [xxx unlockWithCondition:A条件]; 表示释放锁,同时把内部的condition设置为A条件
    1.5 return = [xxx lockWhenCondition:A条件 beforeDate:A时间]; 表示如果被锁定(没获得 锁),并超过该时间则不再阻塞线程。但是注意:返回的值是NO,它没有改变锁的状态,这个函 数的目的在于可以实现两种状态下的处理
    1.6 所谓的condition就是整数,内部通过整数比较条件

    NSConditionLock总结

    线程 1 调用[NSConditionLock lockWhenCondition:],此时此刻因为不满足当前条件,所以会进入 waiting 状态,当前进入到 waiting 时,会释放当前的互斥锁。
    此时当前的线程 3 调用[NSConditionLock lock:],本质上是调用 [NSConditionLock
    lockBeforeDate:],这里不需要比对条件值,所以线程 3 会打印
    接下来线程 2 执行[NSConditionLock lockWhenCondition:],因为满足条件值,所以线程
    2 会打印,打印完成后会调用[NSConditionLock unlockWithCondition:],这个时候讲
    value 设置为 1,并发送 boradcast, 此时线程 1 接收到当前的信号,唤醒执行并打印。
    自此当前打印为 线程 3->线程 2 -> 线程 1。
    [NSConditionLock lockWhenCondition:]:这里会根据传入的 condition 值和 Value 值进行对比,如果不相等,这里就会阻塞,进入线程池,否则的话就继续代码执行
    [NSConditionLock unlockWithCondition:]: 这里会先更改当前的 value 值,然后进行广播,唤醒当前的线程

    相关文章

      网友评论

        本文标题:iOS-OC底层23:锁的原理

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