iOS底层-27：锁的原理

看了这么多的源码，相信大家对锁已经见得很多了。在iOS中有8大锁，他们的性能如下：

下面我们将会分析锁的底层原理，看看锁的性能为什么有好有坏？
在这之前，我们需要先了解一些名词：

TLS线程相关解释

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

互斥锁

在Posix Thread中定义了有一套专门用于线程同步的mutex函数。

mutex用于保证在任何时刻，都只有一个线程访问该对象。当获取锁操作失败的时候，线程会进入睡眠，等待锁释放时被唤醒。

1. 创建和销毁
A. Posix定义了一个宏PTHREAD_MUTEX_INITIALIZER来静态初始化互斥锁
B. int pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutexattr_t *mutexattr)
C. pthread_mutex_destroy()用于注销一个互斥锁

2. 互斥锁属性

3. 锁操作
int pthread_mutex_lock(pthread_mutex_t *mutex)
int pthread_mutex_unlock(pthread_mutex_t *mutex)
int pthread_mutex_trylock(pthread_mutex_t *mutex)
int pthread_mutex_trylock(pthread_mutex_t *mutex)语义和int pthread_mutex_lock(pthread_mutex_t *mutex) 类似，不同的是在锁已经被占据时返回busy而不是挂起等待

互斥锁分为递归锁和非递归锁。

@synchronized

• 递归互斥锁
• 可重入 嵌套
  准备一分简单的测试代码

- (void)viewDidLoad {
    [super viewDidLoad];
    
    for (int i = 0; i < 100; i++) {
        dispatch_async(dispatch_get_global_queue(0, 0), ^{
            [self addMethod];
        });
    }
  
}
- (void)addMethod {
    
    @synchronized (self) {
        self.number = [NSNumber numberWithInteger:(self.number.integerValue + 1)];
        NSLog(@"%@",self.number);
    }
}

由于加锁的原因，nunber的增长没有受到多线程的影响

• 在@synchronized出打上断点，然后bt堆栈
  
  
  并没有看出什么，接着我们打开Debug -->Debug Workflow —> Always Show Disassembly显示汇编，发现了一个没有见过的方法objc_sync_enter。
  

继续往下翻，还可以找到一个退出的方法objc_sync_exit

我们有理由怀疑这两个就是加锁和解锁的实际方法。也可以用clang编译，可以更直观的看到这两个方法。下面是我用clang编译出来的代码。

下面我们下一个符号断点，看看这两个方法在哪个源码中？

• 打开libobjc源码，搜索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;
}

• 查看SyncData

typedef struct alignas(CacheLineSize) SyncData {
    struct SyncData* nextData;
    DisguisedPtr object;
    int32_t threadCount;  // number of THREADS using this block
    recursive_mutex_t mutex;
} SyncData;

• 查看recursive_mutex_t

using recursive_mutex_t = recursive_mutex_tt;

这是一个递归锁的lock和unlock方法

• 查看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;
        //缓存中的data与传入的匹配
        if (data->object == object) {
            // Found a match in fast cache.
            uintptr_t lockCount;

            result = data;//通过COUNT_KEY获取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: {
                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
                //在全局缓存中找到意味着开辟了新的线程 threadCount ++ 
                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;
    
        // 第一次进来，没有找到
        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
        {
            // 把数据设置到缓存中
            if (!cache) cache = fetch_cache(YES);
            cache->list[cache->used].data = result;
            cache->list[cache->used].lockCount = 1;
            cache->used++;
        }
    }

    return result;
}

• 搜索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;
}

总结：

1. 第一次进来的时候，当前线程空间没有缓存，全局的线程缓存也不会有，首次赋值将threadCount、lockCount设置为1，保存在tls和cache中。
2. 下次同一个线程进来，在tls中找到，lockCount++ tls重新保存。
3. 下次不同线程进来，在cache中找到，lockCount++ 、threadCount++，tls和cache重新保存

正因为@synchronized需要在各种线程缓存中查找、设置、保存才导致性能不佳。
优点是方便简单，不用解锁

注意

使用@synchronized要注意的问题

1. 加锁的对象不能为nil

- (void)viewDidLoad {
    [super viewDidLoad];
    
    _mArr = [NSMutableArray array];
    for (int i = 0; i < 10000; i++) {
        dispatch_async(dispatch_get_global_queue(0, 0), ^{
            [self addMethod];
        });
    }
   

}
- (void)addMethod {
    
    @synchronized (_mArr) {
        _mArr = [NSMutableArray array];
    }
}

上面例子运行会出现崩溃。

打开Xcode中僵尸模式，更能说明问题。

再次运行

对一个已经释放了的对象发送release方法，才会崩溃。
这是因为_mArr一直在创建，新值retain，旧值release，_mArr在某一个时刻会置为nil，而@synchronized锁nil的时候会直接return，没有效果。一般我们都是锁self，他和_mArr生命周期一样，而且不会置为nil；当他置为nil的时候，_mArr也没有意义了。

• 当然self也不宜锁过多，如果所有的锁都锁self，底层缓存的链表里就到处都是self，不便查找也浪费性能。

将上述的锁换为NSLock，一样可以达到效果。

- (void)viewDidLoad {
    [super viewDidLoad];
    
    _mArr = [NSMutableArray array];
    
    [self addMethod];
   

}
- (void)addMethod {
    
    
    NSLock *lock = [[NSLock alloc] init];
    
    for (int i = 0; i < 10000; i++) {
        dispatch_async(dispatch_get_global_queue(0, 0), ^{
            
            [lock lock];
            _mArr = [NSMutableArray array];
            [lock unlock];
        });
    }
}

运行不会报错。

NSLock

NSLock使用的非常多，也很简单。

• 点击- (void)lock方法，进入NSLocking协议
  

往下翻我们可以看到NSLock、NSConditionLock、NSRecursiveLock和NSCondition都遵循NSLocking协议

• 通过符号断点查看NSLock的源码归属
  

  
  NSLock源码在Foundation库中，我们大家都知道Foundation没有开源，这里我们可以借助swfit开源代码。

• 搜索NSLock:找到源码
  

  
  我们可以看到init方法做了很多操作，我们使用的时候一定要调用init方法

• 向下查找lock方法
  

  
  直接调用pthread_mutex_lock互斥锁

• 向下查找unlock方法
  

  
  调用pthread_mutex_unlock解锁，然后让所有等待的线程wakeup。

NSLock只是简单的封装pthread，消耗了一点性能，所以它的性能略低于pthread

NSLock的弊端

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

上面的代码运行会出现问题，程序会一直等待。原因是NSLock只是一个普通的互斥锁，递归加锁会在还没有解锁的情况下重复加锁，造成死锁。

解决方案：

• 将NSLock锁移至递归的外面
  

  
  这种方法的堵塞情况可能会很差，它把所有的方法都锁住了。

• 换一个递归互斥锁

  
  

image.png

NSRecursiveLock

查看swfit的Foundation源码

• 搜索NSRecursiveLock
  

• 查找lock
  

• 查找unlock
  

  
  这两段代码和NSLock一模一样，那么为什么NSRecursiveLock是一个递归锁呢？

问题出在init方法中

将NSRecursiveLock标识为递归锁。

NSRecursiveLock的弊端

• 使用比较复杂，稍微写错位置可能就会崩溃。不如@synchronized简便

总结：

• 如果只是简单的加锁，优先使用NSLock，性能最好
• 嵌套加锁推荐使用@synchronized，如果你技术比较熟练使用NSRecursiveLock没有问题，那么它比@synchronized的性能更好。

NSCondition

NSCondition的对象实际上作为一个锁和一个线程检查器：锁主要为了当检测条件时保护数据源，执行条件引发的任务；线程检查器主要是根据条件决定是否继续运行线程，即线程是否被堵塞。

1. [condition lock]；//一般用于多线程同时访问、修改同一个数据源，保证在同一时间内数据源只被访问、修改一次，其他线程的命令需要在lock外等待，直到unlock才可访问
2. [condition unlock]；//与lock成对使用
3. [condition wait]；//让当前线程处于等待状态
4. [condition signal]；//CPU发信号告诉线程不用再等待，可以继续执行

例子

- (void)ly_testConditon{
    
    _testCondition = [[NSCondition alloc] init];
    //创建生产-消费者
    for (int i = 0; i < 50; i++) {
        dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
            [self ly_producer];
        });
        dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
            [self ly_consumer];
        });
        
        dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
            [self ly_consumer];
        });
        dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
            [self ly_producer];
        });
        
    }
}

- (void)ly_producer{
    [_testCondition lock];
    self.ticketCount = self.ticketCount + 1;
    NSLog(@"生产一个 现有 count %zd",self.ticketCount);
    [_testCondition signal];
    [_testCondition unlock];

}

- (void)ly_consumer{
    
    // 线程安全
     [_testCondition lock];

    if (self.ticketCount == 0) {
        NSLog(@"等待 count %zd",self.ticketCount);
        // 保证正常流程
         [_testCondition wait];
    }
    
    //注意消费行为，要在等待条件判断之后
    self.ticketCount -= 1;
    NSLog(@"消费一个 还剩 count %zd ",self.ticketCount);
    [_testCondition unlock];
}

NSConditionLock

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

例子

- (void)lg_testConditonLock{
    // 信号量
    NSConditionLock *conditionLock = [[NSConditionLock alloc] initWithCondition:2];
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
         [conditionLock lockWhenCondition:1];
        NSLog(@"线程 1");
         [conditionLock unlockWithCondition:0];
    });
    
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0), ^{
       
        [conditionLock lockWhenCondition:2];
        NSLog(@"线程 2");
        [conditionLock unlockWithCondition:1];
    });
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
       
       [conditionLock lock];
       NSLog(@"线程 3");
       [conditionLock unlock];
    });
}

这次我们换一种方式查看NSConditionLock的原理，我们直接查看汇编代码。

在下面断点处，打开汇编。

• 添加符号断点

  
  

• 进入汇编

  
  

• 往下翻断点在callq方法（call 一般是调用方法）

• register read 查看寄存器内容

可以看到调用了lockWhenCondition:beforeDate:方法

• 添加符号断点-[NSConditionLock lockWhenCondition:beforeDate:]
  

• 进入lockWhenCondition:beforeDate
  

  
  我们可以看到调用了lock方法，之后有调用了waitUntilDate:

NSConditionLock源码

• 搜索NSConditionLock
  
• 向下查看lock()方法
  
  
  实际调用的是lock(before limit: Date)
• lock(before limit: Date)

 open func lock(before limit: Date) -> Bool {
        _cond.lock()//[condition lock];
        while _thread != nil {
            if !_cond.wait(until: limit) {//当时间到达之后，不在等待了，直接unlock
                _cond.unlock()            //然而这里传入的时间是遥远的未来
                return false
            }
        }
#if os(Windows)
        _thread = GetCurrentThread()
#else
        _thread = pthread_self()//获取自身线程
#endif
        _cond.unlock()//[condition unlock];
        return true
    }

• 搜索unlock

    open func unlock() {
        _cond.lock()
#if os(Windows)
        _thread = INVALID_HANDLE_VALUE
#else
        _thread = nil
#endif
        _cond.broadcast()//广播
        _cond.unlock()////[condition unlock];
    }

• 搜索lock(whenCondition
  
  
  实际执行的是lock(whenCondition: before:
• 搜索lock(whenCondition:

  open func lock(whenCondition condition: Int, before limit: Date) -> Bool {
        _cond.lock()//[condition lock];
        while _thread != nil || _value != condition {//条件不匹配的时候，一直等待
            if !_cond.wait(until: limit) {
                _cond.unlock()
                return false
            }
        }
#if os(Windows)
        _thread = GetCurrentThread()
#else
        _thread = pthread_self()
#endif
        _cond.unlock()
        return true
    }

• 搜索unlock(withCondition

   open func unlock(withCondition condition: Int) {
        _cond.lock()
#if os(Windows)
        _thread = INVALID_HANDLE_VALUE
#else
        _thread = nil
#endif
        _value = condition//把_value设置为condition
        _cond.broadcast()//发出广播
        _cond.unlock()//
    }

• broadcast()

open func broadcast() {
#if os(Windows)
        WakeAllConditionVariable(cond)
#else
        pthread_cond_broadcast(cond) // wait  signal
#endif
    }

唤醒所有等待的线程。

总结

• 线程1 调用[conditionLock lockWhenCondition:]，此时因为不满足当前条件，所以会进入waiting状态，当前进入waiting状态会释放当前的互斥锁。
• 线程3 此时调用[conditionLock lock];实际上是调用[conditionLock lockBeforeDate:]，这里不需要条件对比，所以3会打印
• 接下来是线程2 执行[conditionLock lockWhenCondition:]，因为满足条件所以线程2会打印，打印完成后调用[conditionLock unlockWithCondition:1];，将value设置为1，并发送broadcast，此时线程1接到信号，条件也符合，线程1才会打印。
• [NSConditionLock lockWhenCondition:];这里会根据传入的condition与value进行对比，如果不相等就会阻塞；如果相等才会执行。
• [NSConditionLock unlockWithCondition:];这里会先改变value的值，然后进行广播，唤醒其他线程。

锁的归类

自旋锁

线程反复检查锁变量是否可用。由于线程在这一过程中保持执行，因此是一种忙等。一旦获取了自旋锁，线程会一直保持该锁，直至显示释放自旋锁。自旋锁避免了进程上下文的调度开销，因此对于线程只会阻塞很短的时间场合是有效的。

互斥锁

是用于多线程编程中，防止两条线程同时对同一公共资源（比如全局变量）进行读写的机制。通过将代码切片成一个个的临界区而达成
这里属于互斥锁的有：

• NSLock
• pthread_mutex
• @synchronized

条件锁

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

• NSCondition
• NSConditionLock

递归锁

就是同一个线程可以加锁N次，而不会引发死锁。

• NSRecursiveLock
• pthread_mutex(recursive)

信号量（semaphore）

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

读写锁

读写锁实际上是一种特殊的自旋锁，它把对公共资源的访问者分为读者和写者，读者只对共享资源进行读访问，写者才需要对共享资源进行写操作。这种锁相对于自旋锁，可以提高并发性。因为在多处理器系统中，它允许有多个读者来访问共享资源，最大可能的读者数为实际的逻辑CPU数。写者是排他性的，一个读写锁同时只能有一个写者或多个读者(与CPU数相关)，但不能同时既有读者又有写者。在读写锁保持期间也是抢占失效的。

如果读写锁当前没有读者也没有写者，那么写者可以立刻获得读写锁，否则它必须自旋在那里，直到没有任何写者或读者。如果读写锁没有写者，那么读者可以立即获得该读写锁，否则读者必须自旋在那里，直到写者释放该读写锁。