iOS-底层原理 26锁的原理

本文主要介绍常见的锁，以及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的操作

1.  
   static inline void reallySetProperty(id self, SEL _cmd, id newValue, ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy)
2.  
   {
3.  
   ...
4.  
   id *slot = (id*) ((char*)self offset);
5.  
   ...
6.  
    
7.  
   if (!atomic) {//未加锁
8.  
   oldValue = *slot;
9.  
   *slot = newValue;
10.  
    } else {//加锁
11.  
    spinlock_t& slotlock = PropertyLocks[slot];
12.  
    slotlock.lock();
13.  
    oldValue = *slot;
14.  
    *slot = newValue;
15.  
    slotlock.unlock();
16.  
    }
17.  
    ...
18.  
    }

从源码中可以看出，对于atomic修饰的属性，进行了spinlock_t加锁处理，但是在前文中提到OSSpinLock已经废弃了，这里的spinlock_t在底层是通过os_unfair_lock替代了OSSpinLock实现的加锁。同时为了防止哈希冲突，还是用了加盐操作

1.  
   using spinlock_t = mutex_tt<LOCKDEBUG>;
2.  
    
3.  
   class mutex_tt : nocopy_t {
4.  
   os_unfair_lock mLock;
5.  
   ...
6.  
   }

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

1.  
   id objc_getProperty(id self, SEL _cmd, ptrdiff_t offset, BOOL atomic) {
2.  
   if (offset == 0) {
3.  
   return object_getClass(self);
4.  
   }
5.  
    
6.  
   // Retain release world
7.  
   id *slot = (id*) ((char*)self offset);
8.  
   if (!atomic) return *slot;
9.  
    
10.  
    // Atomic retain release world
11.  
    spinlock_t& slotlock = PropertyLocks[slot];
12.  
    slotlock.lock();//加锁
13.  
    id value = objc_retain(*slot);
14.  
    slotlock.unlock();//解锁
15.  
     
16.  
    // for performance, we (safely) issue the autorelease OUTSIDE of the spinlock.
17.  
    return objc_autoreleaseReturnValue(value);
18.  
    }

3、synchronized（互斥递归锁）

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

  

• 也可以通过clang，查看底层编译代码

  

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

objc_sync_enter & objc_sync_exit 分析

• 进入objc_sync_enter源码实现

  • 如果obj存在，则通过id2data方法获取相应的SyncData，对threadCount、lockCount进行递增操作

  • 如果obj不存在，则调用objc_sync_nil，通过符号断点得知，这个方法里面什么都没做，直接return了

1.  
   int objc_sync_enter(id obj)
2.  
   {
3.  
   int result = OBJC_SYNC_SUCCESS;
4.  
    
5.  
   if (obj) {//传入不为nil
6.  
   SyncData* data = id2data(obj, ACQUIRE);//重点
7.  
   ASSERT(data);
8.  
   data->mutex.lock();//加锁
9.  
   } else {//传入nil
10.  
    // @synchronized(nil) does nothing
11.  
    if (DebugNilSync) {
12.  
    _objc_inform("NIL SYNC DEBUG: @synchronized(nil); set a breakpoint on objc_sync_nil to debug");
13.  
    }
14.  
    objc_sync_nil();
15.  
    }
16.  
     
17.  
    return result;
18.  
    }

• 进入objc_sync_exit源码实现

  • 如果obj存在，则调用id2data方法获取对应的SyncData，对threadCount、lockCount进行递减操作

  • 如果obj为nil，什么也不做

1.  
   // End synchronizing on 'obj'. 结束对“ obj”的同步
2.  
   // Returns OBJC_SYNC_SUCCESS or OBJC_SYNC_NOT_OWNING_THREAD_ERROR
3.  
   int objc_sync_exit(id obj)
4.  
   {
5.  
   int result = OBJC_SYNC_SUCCESS;
6.  
    
7.  
   if (obj) {//obj不为nil
8.  
   SyncData* data = id2data(obj, RELEASE);
9.  
   if (!data) {
10.  
    result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
11.  
    } else {
12.  
    bool okay = data->mutex.tryUnlock();//解锁
13.  
    if (!okay) {
14.  
    result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
15.  
    }
16.  
    }
17.  
    } else {//obj为nil时，什么也不做
18.  
    // @synchronized(nil) does nothing
19.  
    }
20.  
    return result;
21.  
    }

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

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

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

• 进入SyncCache的定义，也是一个结构体，用于存储线程，其中list[0]表示当前线程的链表data，主要用于存储SyncData和lockCount

1.  
   typedef struct {
2.  
   SyncData *data;
3.  
   unsigned int lockCount; // number of times THIS THREAD locked this block
4.  
   } SyncCacheItem;
5.  
    
6.  
   typedef struct SyncCache {
7.  
   unsigned int allocated;
8.  
   unsigned int used;
9.  
   SyncCacheItem list[0];
10.  
    } SyncCache;

id2data 分析

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

1.  
   static SyncData* id2data(id object, enum usage why)
2.  
   {
3.  
   spinlock_t *lockp = &LOCK_FOR_OBJ(object);
4.  
   SyncData **listp = &LIST_FOR_OBJ(object);
5.  
   SyncData* result = NULL;
6.  
    
7.  
   #if SUPPORT_DIRECT_THREAD_KEYS //tls（Thread Local Storage，本地局部的线程缓存）
8.  
   // Check per-thread single-entry fast cache for matching object
9.  
   bool fastCacheOccupied = NO;
10.  
    //通过KVC方式对线程进行获取 线程绑定的data
11.  
    SyncData *data = (SyncData *)tls_get_direct(SYNC_DATA_DIRECT_KEY);
12.  
    //如果线程缓存中有data，执行if流程
13.  
    if (data) {
14.  
    fastCacheOccupied = YES;
15.  
    //如果在线程空间找到了data
16.  
    if (data->object == object) {
17.  
    // Found a match in fast cache.
18.  
    uintptr_t lockCount;
19.  
     
20.  
    result = data;
21.  
    //通过KVC获取lockCount，lockCount用来记录 被锁了几次，即 该锁可嵌套
22.  
    lockCount = (uintptr_t)tls_get_direct(SYNC_COUNT_DIRECT_KEY);
23.  
    if (result->threadCount <= 0 || lockCount <= 0) {
24.  
    _objc_fatal("id2data fastcache is buggy");
25.  
    }
26.  
     
27.  
    switch(why) {
28.  
    case ACQUIRE: {
29.  
    //objc_sync_enter走这里，传入的是ACQUIRE -- 获取
30.  
    lockCount ;//通过lockCount判断被锁了几次，即表示 可重入（递归锁如果可重入，会死锁）
31.  
    tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);//设置
32.  
    break;
33.  
    }
34.  
    case RELEASE:
35.  
    //objc_sync_exit走这里，传入的why是RELEASE -- 释放
36.  
    lockCount--;
37.  
    tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);
38.  
    if (lockCount == 0) {
39.  
    // remove from fast cache
40.  
    tls_set_direct(SYNC_DATA_DIRECT_KEY, NULL);
41.  
    // atomic because may collide with concurrent ACQUIRE
42.  
    OSAtomicDecrement32Barrier(&result->threadCount);
43.  
    }
44.  
    break;
45.  
    case CHECK:
46.  
    // do nothing
47.  
    break;
48.  
    }
49.  
     
50.  
    return result;
51.  
    }
52.  
    }
53.  
    #endif
54.  
     
55.  
    // Check per-thread cache of already-owned locks for matching object
56.  
    SyncCache *cache = fetch_cache(NO);//判断缓存中是否有该线程
57.  
    //如果cache中有，方式与线程缓存一致
58.  
    if (cache) {
59.  
    unsigned int i;
60.  
    for (i = 0; i < cache->used; i ) {//遍历总表
61.  
    SyncCacheItem *item = &cache->list[i];
62.  
    if (item->data->object != object) continue;
63.  
     
64.  
    // Found a match.
65.  
    result = item->data;
66.  
    if (result->threadCount <= 0 || item->lockCount <= 0) {
67.  
    _objc_fatal("id2data cache is buggy");
68.  
    }
69.  
     
70.  
    switch(why) {
71.  
    case ACQUIRE://加锁
72.  
    item->lockCount ;
73.  
    break;
74.  
    case RELEASE://解锁
75.  
    item->lockCount--;
76.  
    if (item->lockCount == 0) {
77.  
    // remove from per-thread cache 从cache中清除使用标记
78.  
    cache->list[i] = cache->list[--cache->used];
79.  
    // atomic because may collide with concurrent ACQUIRE
80.  
    OSAtomicDecrement32Barrier(&result->threadCount);
81.  
    }
82.  
    break;
83.  
    case CHECK:
84.  
    // do nothing
85.  
    break;
86.  
    }
87.  
     
88.  
    return result;
89.  
    }
90.  
    }
91.  
     
92.  
    // Thread cache didn't find anything.
93.  
    // Walk in-use list looking for matching object
94.  
    // Spinlock prevents multiple threads from creating multiple
95.  
    // locks for the same new object.
96.  
    // We could keep the nodes in some hash table if we find that there are
97.  
    // more than 20 or so distinct locks active, but we don't do that now.
98.  
    //第一次进来，所有缓存都找不到
99.  
    lockp->lock();
100.  
      
101.  
     {
102.  
     SyncData* p;
103.  
     SyncData* firstUnused = NULL;
104.  
     for (p = *listp; p != NULL; p = p->nextData) {//cache中已经找到
105.  
     if ( p->object == object ) {//如果不等于空，且与object相似
106.  
     result = p;//赋值
107.  
     // atomic because may collide with concurrent RELEASE
108.  
     OSAtomicIncrement32Barrier(&result->threadCount);//对threadCount进行
109.  
     goto done;
110.  
     }
111.  
     if ( (firstUnused == NULL) && (p->threadCount == 0) )
112.  
     firstUnused = p;
113.  
     }
114.  
      
115.  
     // no SyncData currently associated with object 没有与当前对象关联的SyncData
116.  
     if ( (why == RELEASE) || (why == CHECK) )
117.  
     goto done;
118.  
      
119.  
     // an unused one was found, use it 第一次进来，没有找到
120.  
     if ( firstUnused != NULL ) {
121.  
     result = firstUnused;
122.  
     result->object = (objc_object *)object;
123.  
     result->threadCount = 1;
124.  
     goto done;
125.  
     }
126.  
     }
127.  
      
128.  
     // Allocate a new SyncData and add to list.
129.  
     // XXX allocating memory with a global lock held is bad practice,
130.  
     // might be worth releasing the lock, allocating, and searching again.
131.  
     // But since we never free these guys we won't be stuck in allocation very often.
132.  
     posix_memalign((void **)&result, alignof(SyncData), sizeof(SyncData));//创建赋值
133.  
     result->object = (objc_object *)object;
134.  
     result->threadCount = 1;
135.  
     new (&result->mutex) recursive_mutex_t(fork_unsafe_lock);
136.  
     result->nextData = *listp;
137.  
     *listp = result;
138.  
      
139.  
     done:
140.  
     lockp->unlock();
141.  
     if (result) {
142.  
     // Only new ACQUIRE should get here.
143.  
     // All RELEASE and CHECK and recursive ACQUIRE are
144.  
     // handled by the per-thread caches above.
145.  
     if (why == RELEASE) {
146.  
     // Probably some thread is incorrectly exiting
147.  
     // while the object is held by another thread.
148.  
     return nil;
149.  
     }
150.  
     if (why != ACQUIRE) _objc_fatal("id2data is buggy");
151.  
     if (result->object != object) _objc_fatal("id2data is buggy");
152.  
      
153.  
     #if SUPPORT_DIRECT_THREAD_KEYS
154.  
     if (!fastCacheOccupied) { //判断是否支持栈存缓存，支持则通过KVC形式赋值 存入tls
155.  
     // Save in fast thread cache
156.  
     tls_set_direct(SYNC_DATA_DIRECT_KEY, result);
157.  
     tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)1);//lockCount = 1
158.  
     } else
159.  
     #endif
160.  
     {
161.  
     // Save in thread cache 缓存中存一份
162.  
     if (!cache) cache = fetch_cache(YES);//第一次存储时，对线程进行了绑定
163.  
     cache->list[cache->used].data = result;
164.  
     cache->list[cache->used].lockCount = 1;
165.  
     cache->used ;
166.  
     }
167.  
     }
168.  
      
169.  
     return result;
170.  
     }
171.  
      

• 【第一步】首先在tls即线程缓存中查找。

  • 如果是ACQUIRE，表示加锁，则进行lockCount ，并保存到tls缓存

  • 如果是RELEASE，表示释放，则进行lockCount--，并保存到tls缓存。如果lockCount 等于 0，从tls中移除线程data

  • 如果是CHECK，则什么也不做

  • 在tls_get_direct方法中以线程为key，通过KVC的方式获取与之绑定的SyncData，即线程data。其中的tls（），表示本地局部的线程缓存，

  • 判断获取的data是否存在，以及判断data中是否能找到对应的object

  • 如果都找到了，在tls_get_direct方法中以KVC的方式获取lockCount，用来记录对象被锁了几次（即锁的嵌套次数）

  • 如果data中的threadCount 小于等于0，或者 lockCount 小于等于0时，则直接崩溃

  • 通过传入的why，判断是操作类型

• 【第二步】如果tls中没有，则在cache缓存中查找

  • 通过fetch_cache方法查找cache缓存中是否有线程

  • 如果有，则遍历cache总表，读取出线程对应的SyncCacheItem

  • 从SyncCacheItem中取出data，然后后续步骤与tls的匹配是一致的

• 【第三步】如果cache中也没有，即第一次进来，则创建SyncData，并存储到相应缓存中

  • 如果在cache中找到线程，且与object相等，则进行赋值、以及threadCount

  • 如果在cache中没有找到，则threadCount等于1

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

• 【第一次进来，没有锁】：

  • threadCount = 1

  • lockCount = 1

  • 存储到tls

• 【不是第一次进来，且是同一个线程】

  • tls中有数据，则lockCount

  • 存储到tls

• 【不是第一次进来，且是不同线程】

  • 全局线程空间进行查找线程

  • threadCount

  • lockCount

  • 存储到cache

tls和cache表结构
针对tls和cache缓存，底层的表结构如下所示

tls和cache缓存结构

• 哈希表结构中通过SyncList结构来组装多线程的情况

• SyncData通过链表的形式组装当前可重入的情况

• 下层通过tls线程缓存、cache缓存来进行处理

• 底层主要有两个东西：lockCount、threadCount,解决了递归互斥锁，解决了嵌套可重入

@synchronized 坑点

下面代码这样写，会有什么问题？

1.  
   - (void)cjl_testSync{
2.  
   _testArray = [NSMutableArray array];
3.  
   for (int i = 0; i < 200000; i ) {
4.  
   dispatch_async(dispatch_get_global_queue(0, 0), ^{
5.  
   @synchronized (self.testArray) {
6.  
   self.testArray = [NSMutableArray array];
7.  
   }
8.  
   });
9.  
   }
10.  
    }

运行结果发现，运行就崩溃

崩溃的主要原因是testArray在某一瞬间变成了nil，从@synchronized底层流程知道，如果加锁的对象成了nil，是锁不住的，相当于下面这种情况，block内部不停的retain、release，会在某一瞬间上一个还未release，下一个已经准备release，这样会导致野指针的产生

1.  
   _testArray = [NSMutableArray array];
2.  
   for (int i = 0; i < 200000; i ) {
3.  
   dispatch_async(dispatch_get_global_queue(0, 0), ^{
4.  
   _testArray = [NSMutableArray array];
5.  
   });
6.  
   }

可以根据上面的代码，打开edit scheme -> run -> Diagnostics中勾选Zombie Objects ，来查看是否是僵尸对象，结果如下所示

我们一般使用@synchronized (self)，主要是因为_testArray的持有者是self

注意：野指针 vs 过渡释放

• 野指针：是指由于过渡释放产生的指针还在进行操作

• 过渡释放：每次都会retain 和 release

总结

• @synchronized在底层封装的是一把递归锁，所以这个锁是递归互斥锁

• @synchronized的可重入，即可嵌套，主要是由于lockCount 和 threadCount的搭配

• @synchronized使用链表的原因是链表方便下一个data的插入，

• 但是由于底层中链表查询、缓存的查找以及递归，是非常耗内存以及性能的，导致性能低，所以在前文中，该锁的排名在最后

• 但是目前该锁的使用频率仍然很高，主要是因为方便简单，且不用解锁

• 不能使用非OC对象作为加锁对象，因为其object的参数为id

• @synchronized (self)这种适用于嵌套次数较少的场景。这里锁住的对象也并不永远是self，这里需要读者注意

• 如果锁嵌套次数较多，即锁self过多，会导致底层的查找非常麻烦，因为其底层是链表进行查找，所以会相对比较麻烦，所以此时可以使用NSLock、信号量等

4、NSLock

NSLock是对下层pthread_mutex的封装，使用如下

1.  
   NSLock *lock = [[NSLock alloc] init];
2.  
   [lock lock];
3.  
   [lock unlock];

直接进入NSLock定义查看，其遵循了NSLocking协议，下面来探索NSLock的底层实现

NSLock 底层分析

• 通过加符号断点lock分析，发现其源码在Foundation框架中，

  由于OC的Foundation框架不开源，所以这里借助Swift的开源框架Foundation来 分析NSLock的底层实现，其原理与OC是大致相同的
  通过源码实现可以看出，底层是通过pthread_mutex互斥锁实现的。并且在init方法中，还做了一些其他操作，所以在使用NSLock时需要使用init初始化

回到前文的性能图中，可以看出NSLock的性能仅次于 pthread_mutex（互斥锁），非常接近

使用弊端

请问下面block嵌套block的代码中，会有什么问题？

1.  
   for (int i= 0; i<100; i ) {
2.  
   dispatch_async(dispatch_get_global_queue(0, 0), ^{
3.  
   static void (^testMethod)(int);
4.  
   testMethod = ^(int value){
5.  
   if (value > 0) {
6.  
   NSLog(@"current value = %d",value);
7.  
   testMethod(value - 1);
8.  
   }
9.  
   };
10.  
    testMethod(10);
11.  
    });
12.  
    }

• 在未加锁之前，其中的current=9、10有很多条，导致数据混乱，主要原因是多线程导致的

• 如果像下面这样加锁，会有什么问题？

1.  
   NSLock *lock = [[NSLock alloc] init];
2.  
   for (int i= 0; i<100; i ) {
3.  
   dispatch_async(dispatch_get_global_queue(0, 0), ^{
4.  
   static void (^testMethod)(int);
5.  
   testMethod = ^(int value){
6.  
   [lock lock];
7.  
   if (value > 0) {
8.  
   NSLog(@"current value = %d",value);
9.  
   testMethod(value - 1);
10.  
    }
11.  
    };
12.  
    testMethod(10);
13.  
    [lock unlock];
14.  
    });
15.  
    }

其运行结果如下

会出现一直等待的情况，主要是因为嵌套使用的递归，使用NSLock（简单的互斥锁，如果没有回来，会一直睡觉等待），即会存在一直加lock，等不到unlock 的堵塞情况

所以，针对这种情况，可以使用以下方式解决

• 使用@synchronized

1.  
   for (int i= 0; i<100; i ) {
2.  
   dispatch_async(dispatch_get_global_queue(0, 0), ^{
3.  
   static void (^testMethod)(int);
4.  
   testMethod = ^(int value){
5.  
   @synchronized (self) {
6.  
   if (value > 0) {
7.  
   NSLog(@"current value = %d",value);
8.  
   testMethod(value - 1);
9.  
   }
10.  
    }
11.  
    };
12.  
    testMethod(10);
13.  
    });
14.  
    }

• 使用递归锁NSRecursiveLock

1.  
   NSRecursiveLock *recursiveLock = [[NSRecursiveLock alloc] init];
2.  
   for (int i= 0; i<100; i ) {
3.  
   dispatch_async(dispatch_get_global_queue(0, 0), ^{
4.  
   static void (^testMethod)(int);
5.  
   [recursiveLock lock];
6.  
   testMethod = ^(int value){
7.  
   if (value > 0) {
8.  
   NSLog(@"current value = %d",value);
9.  
   testMethod(value - 1);
10.  
    }
11.  
    [recursiveLock unlock];
12.  
    };
13.  
    testMethod(10);
14.  
    });
15.  
    }

5、pthread_mutex

pthread_mutex就是互斥锁本身，当锁被占用，其他线程申请锁时，不会一直忙等待，而是阻塞线程并睡眠

1.  
   // 导入头文件
2.  
   #import <pthread.h>
3.  
    
4.  
   // 全局声明互斥锁
5.  
   pthread_mutex_t _lock;
6.  
    
7.  
   // 初始化互斥锁
8.  
   pthread_mutex_init(&_lock, NULL);
9.  
    
10.  
    // 加锁
11.  
    pthread_mutex_lock(&_lock);
12.  
    // 这里做需要线程安全操作
13.  
    // 解锁
14.  
    pthread_mutex_unlock(&_lock);
15.  
     
16.  
    // 释放锁
17.  
    pthread_mutex_destroy(&_lock);

6、NSRecursiveLock

NSRecursiveLock在底层也是对pthread_mutex的封装，可以通过swift的Foundation源码查看

对比NSLock 和 NSRecursiveLock，其底层实现几乎一模一样，区别在于init时，NSRecursiveLock有一个标识PTHREAD_MUTEX_RECURSIVE，而NSLock是默认的

递归锁主要是用于解决一种嵌套形式，其中循环嵌套居多

7、NSCondition

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

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

• 锁主要 为了当检测条件时保护数据源，执行条件引发的任务

• 线程检查器主要是根据条件决定是否继续运行线程，即线程是否被阻塞

使用

1.  
   //初始化
2.  
   NSCondition *condition = [[NSCondition alloc] init]
3.  
    
4.  
   //一般用于多线程同时访问、修改同一个数据源，保证在同一 时间内数据源只被访问、修改一次，其他线程的命令需要在lock 外等待，只到 unlock ，才可访问
5.  
   [condition lock];
6.  
    
7.  
   //与lock 同时使用
8.  
   [condition unlock];
9.  
    
10.  
    //让当前线程处于等待状态
11.  
    [condition wait];
12.  
     
13.  
    //CPU发信号告诉线程不用在等待，可以继续执行
14.  
    [condition signal];

底层分析

通过swift的Foundation源码查看NSCondition的底层实现

1.  
   open class NSCondition: NSObject, NSLocking {
2.  
   internal var mutex = _MutexPointer.allocate(capacity: 1)
3.  
   internal var cond = _ConditionVariablePointer.allocate(capacity: 1)
4.  
   //初始化
5.  
   public override init() {
6.  
   pthread_mutex_init(mutex, nil)
7.  
   pthread_cond_init(cond, nil)
8.  
   }
9.  
   //析构
10.  
    deinit {
11.  
    pthread_mutex_destroy(mutex)
12.  
    pthread_cond_destroy(cond)
13.  
     
14.  
    mutex.deinitialize(count: 1)
15.  
    cond.deinitialize(count: 1)
16.  
    mutex.deallocate()
17.  
    cond.deallocate()
18.  
    }
19.  
    //加锁
20.  
    open func lock() {
21.  
    pthread_mutex_lock(mutex)
22.  
    }
23.  
    //解锁
24.  
    open func unlock() {
25.  
    pthread_mutex_unlock(mutex)
26.  
    }
27.  
    //等待
28.  
    open func wait() {
29.  
    pthread_cond_wait(cond, mutex)
30.  
    }
31.  
    //等待
32.  
    open func wait(until limit: Date) -> Bool {
33.  
    guard var timeout = timeSpecFrom(date: limit) else {
34.  
    return false
35.  
    }
36.  
    return pthread_cond_timedwait(cond, mutex, &timeout) == 0
37.  
    }
38.  
    //信号，表示等待的可以执行了
39.  
    open func signal() {
40.  
    pthread_cond_signal(cond)
41.  
    }
42.  
    //广播
43.  
    open func broadcast() {
44.  
    // 汇编分析 - 猜 (多看多玩)
45.  
    pthread_cond_broadcast(cond) // wait signal
46.  
    }
47.  
    open var name: String?
48.  
    }

其底层也是对下层pthread_mutex的封装

• NSCondition是对mutex和cond的一种封装（cond就是用于访问和操作特定类型数据的指针）

• wait操作会阻塞线程，使其进入休眠状态，直至超时

• signal操作是唤醒一个正在休眠等待的线程

• broadcast会唤醒所有正在等待的线程

8、NSConditionLock

NSConditionLock是条件锁，一旦一个线程获得锁，其他线程一定等待

相比NSConditionLock而言，NSCondition使用比较麻烦，所以推荐使用NSConditionLock，其使用如下

1.  
   //初始化
2.  
   NSConditionLock *conditionLock = [[NSConditionLock alloc] initWithCondition:2];
3.  
    
4.  
   //表示 conditionLock 期待获得锁，如果没有其他线程获得锁(不需要判断内部的 condition) 那它能执行此行以下代码，如果已经有其他线程获得锁(可能是条件锁，或者无条件 锁)，则等待，直至其他线程解锁
5.  
   [conditionLock lock];
6.  
    
7.  
   //表示如果没有其他线程获得该锁，但是该锁内部的 condition不等于A条件，它依然不能获得锁，仍然等待。如果内部的condition等于A条件，并且 没有其他线程获得该锁，则进入代码区，同时设置它获得该锁，其他任何线程都将等待它代码的 完成，直至它解锁。
8.  
   [conditionLock lockWhenCondition:A条件];
9.  
    
10.  
    //表示释放锁，同时把内部的condition设置为A条件
11.  
    [conditionLock unlockWithCondition:A条件];
12.  
     
13.  
    // 表示如果被锁定(没获得 锁)，并超过该时间则不再阻塞线程。但是注意:返回的值是NO,它没有改变锁的状态，这个函 数的目的在于可以实现两种状态下的处理
14.  
    return = [conditionLock lockWhenCondition:A条件 beforeDate:A时间];
15.  
     
16.  
    //其中所谓的condition就是整数，内部通过整数比较条件

NSConditionLock，其本质就是NSCondition Lock，以下是其swift的底层实现，

1.  
   open class NSConditionLock : NSObject, NSLocking {
2.  
   internal var _cond = NSCondition()
3.  
   internal var _value: Int
4.  
   internal var _thread: _swift_CFThreadRef?
5.  
    
6.  
   public convenience override init() {
7.  
   self.init(condition: 0)
8.  
   }
9.  
    
10.  
    public init(condition: Int) {
11.  
    _value = condition
12.  
    }
13.  
     
14.  
    open func lock() {
15.  
    let _ = lock(before: Date.distantFuture)
16.  
    }
17.  
     
18.  
    open func unlock() {
19.  
    _cond.lock()
20.  
    _thread = nil
21.  
    _cond.broadcast()
22.  
    _cond.unlock()
23.  
    }
24.  
     
25.  
    open var condition: Int {
26.  
    return _value
27.  
    }
28.  
     
29.  
    open func lock(whenCondition condition: Int) {
30.  
    let _ = lock(whenCondition: condition, before: Date.distantFuture)
31.  
    }
32.  
     
33.  
    open func `try`() -> Bool {
34.  
    return lock(before: Date.distantPast)
35.  
    }
36.  
     
37.  
    open func tryLock(whenCondition condition: Int) -> Bool {
38.  
    return lock(whenCondition: condition, before: Date.distantPast)
39.  
    }
40.  
     
41.  
    open func unlock(withCondition condition: Int) {
42.  
    _cond.lock()
43.  
    _thread = nil
44.  
    _value = condition
45.  
    _cond.broadcast()
46.  
    _cond.unlock()
47.  
    }
48.  
     
49.  
    open func lock(before limit: Date) -> Bool {
50.  
    _cond.lock()
51.  
    while _thread != nil {
52.  
    if !_cond.wait(until: limit) {
53.  
    _cond.unlock()
54.  
    return false
55.  
    }
56.  
    }
57.  
    _thread = pthread_self()
58.  
    _cond.unlock()
59.  
    return true
60.  
    }
61.  
     
62.  
    open func lock(whenCondition condition: Int, before limit: Date) -> Bool {
63.  
    _cond.lock()
64.  
    while _thread != nil || _value != condition {
65.  
    if !_cond.wait(until: limit) {
66.  
    _cond.unlock()
67.  
    return false
68.  
    }
69.  
    }
70.  
    _thread = pthread_self()
71.  
    _cond.unlock()
72.  
    return true
73.  
    }
74.  
     
75.  
    open var name: String?
76.  
    }

通过源码可以看出

• NSConditionLock是NSCondition的封装

• NSConditionLock可以设置锁条件，即condition值，而NSCondition只是信号的通知

调试验证

以下面代码为例，调试NSConditionLock底层流程

1.  
   - (void)cjl_testConditonLock{
2.  
   // 信号量
3.  
   NSConditionLock *conditionLock = [[NSConditionLock alloc] initWithCondition:2];
4.  
    
5.  
   dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
6.  
   [conditionLock lockWhenCondition:1]; // conditoion = 1 内部 Condition 匹配
7.  
   // -[NSConditionLock lockWhenCondition: beforeDate:]
8.  
   NSLog(@"线程 1");
9.  
   [conditionLock unlockWithCondition:0];
10.  
    });
11.  
     
12.  
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0), ^{
13.  
     
14.  
    [conditionLock lockWhenCondition:2];
15.  
    sleep(0.1);
16.  
    NSLog(@"线程 2");
17.  
    // self.myLock.value = 1;
18.  
    [conditionLock unlockWithCondition:1]; // _value = 2 -> 1
19.  
    });
20.  
     
21.  
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
22.  
     
23.  
    [conditionLock lock];
24.  
    NSLog(@"线程 3");
25.  
    [conditionLock unlock];
26.  
    });
27.  
    }

• 在conditionLock部分打上响应断点，运行（需要在真机上运行：模拟器上运行的是Intel指令，而真机上运行的是arm指令）

• 断住，开启汇编调试

• register read 读取寄存器，其中 x0是接收者 self ，x1是cmd

• 在objc_msgSend处加断点，再次读寄存器 x0 -- register read x0，此时执行到了[conditionLock lockWhenCondition:2];

  

• 读x1，即 register read x1 ,然后发现读不出来，因为x1存储的是sel，并不是对象类型，可以通过进行强转为SEL读取

  

• 加符号断点-[NSConditionLock lockWhenCondition:]、-[NSConditionLock lockWhenCondition:beforeDate:],然后查看bl、b等跳转

  • 读取寄存器 x0、x2是当前的lockWhenCondition:beforeDate:的参数，实际走的是[conditionLock lockWhenCondition:1];

  • 通过汇编可知，x2移动到了x21
    到这里后，我们调试的目的主要有两个：NSCondition lock 以及condition与value的值匹配

NSCondition lock验证

• 继续执行，在bl处断住，读取寄存器 x0 ，此时是跳转至NSCondition

• 读取 x1，即 po (SEL)0x00000001c746e484

  

所以可以验证NSConditionLock在底层调用的是NSCondition的lock方法

condition与value的值匹配

• 继续执行，跳到ldr ，即通过一个方法，拿到了 condition 2 的属性值，存储到x8中

  • register read x19

  • po (SEL)0x0000000283d0d220 -- x19的地址 0x10

  • register read x8，此时的x8中存储的是 2

  • cmp x8, x21，意思是将 x8和 x21匹配，即 2 和 1匹配，并不匹配

• 第二次来到cmp x8, x21，此时的x8、x21 是匹配的 ，即[conditionLock lockWhenCondition:2];

  此时是x8 和 x21 是匹配的

demo分析汇总

• 线程 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 值，然后进行广播，唤醒当前的线程

性能总结

• OSSpinLock自旋锁由于安全性问题，在iOS10之后已经被废弃，其底层的实现用os_unfair_lock替代

  • 使用OSSpinLock及所示，会处于忙等待状态

  • 而os_unfair_lock是处于休眠状态

• atomic原子锁自带一把自旋锁，只能保证setter、getter时的线程安全，在日常开发中使用更多的还是nonatomic修饰属性

  • atomic：当属性在调用setter、getter方法时，会加上自旋锁osspinlock，用于保证同一时刻只能有一个线程调用属性的读或写，避免了属性读写不同步的问题。由于是底层编译器自动生成的互斥锁代码，会导致效率相对较低

  • nonatomic：当属性在调用setter、getter方法时，不会加上自旋锁，即线程不安全。由于编译器不会自动生成互斥锁代码，可以提高效率

• @synchronized在底层维护了一个哈希表进行线程data的存储，通过链表表示可重入（即嵌套）的特性，虽然性能较低，但由于简单好用，使用频率很高

• NSLock、NSRecursiveLock底层是对pthread_mutex的封装

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

锁的使用场景

• 如果只是简单的使用，例如涉及线程安全，使用NSLock即可

• 如果是循环嵌套，推荐使用@synchronized，主要是因为使用递归锁的 性能 不如 使用@synchronized的性能（因为在synchronized中无论怎么重入，都没有关系，而NSRecursiveLock可能会出现崩溃现象）

• 在循环嵌套中，如果对递归锁掌握的很好，则建议使用递归锁，因为性能好

• 如果是循环嵌套，并且还有多线程影响时，例如有等待、死锁现象时，建议使用@synchronized

这篇好文章是转载于：学新通技术网