__block NSMutableArray *array;
self.lock = [[NSLock alloc] init];
for (int i = 0; i < 10000; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{

        [self.lock lock];

        array = [NSMutableArray array];

        [self.lock unlock];

    });

}

for (int i = 0; i < 10; 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);

    });

}

for (int i = 0; i < 10; 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);

            }

        };

        [self.lock lock];
testMethod(10);

        [self.lock unlock];

    });

}

for (int i = 0; i < 10; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
static void (^testMethod)(int);

        testMethod = ^(int value){

            [self.recursiveLock lock];
if (value > 0) {
NSLog(@"current value = %d",value);
testMethod(value - 1);

            }

            [self.recursiveLock unlock];

        };
testMethod(10);

    });

}

但是在执行testMethod一次（也有可能是多次）递归调用后没有继续输出：

由于NSRecursiveLock不支持多线程可递归。所以改为@synchronized：

    for (int i = 0; i < 10; i++) {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
static void (^testMethod)(int);

            testMethod = ^(int value){

                @synchronized (self) {
if (value > 0) {
NSLog(@"current value = %d",value);
testMethod(value - 1);

                    }

                }

            };
testMethod(10);

        });

    }

就能完美解决问题了。

NSRecursiveLock 解决了 NSLock 递归问题，@synchronized 解决了 NSRecursiveLock 多线程可递归问题问题。

2.3 原理分析

NSLock与NSRecursiveLock是定义在Foundation框架中的，Foundation框架并没有开源。有三种方式来探索：

• 分析Foundation动态库的汇编代码。
• 断点跟踪加锁解锁流程。
• Swift Foundation源码分析。虽然Foundation框架本身没有，但是苹果开源了Swift Foundation的代码。原理是想通的。swift-corelibs-foundation

当然有兴趣可以尝试编译可运行版本进行调试 swift-foundation 源码编译

在Foundation中lock与unlock是NSLocking协议提供的方法：

@protocol NSLocking
- (void)lock;
- (void)unlock;
@end

在Swift Foundation源码中同样有NSLocking协议：

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

}

2.3.1 NSLock 源码分析

底层是对pthread_mutex_init的封装。lock和unlock同样是对pthread_mutex_lock与pthread_mutex_unlock的封装：

通过宏定义可以看到Swift的跨平台支持。

2.3.2 NSRecursiveLock 源码分析

内部是对PTHREAD_MUTEX_RECURSIVE的封装。lock与unlock同样是对pthread_mutex_lock与pthread_mutex_unlock的封装。

三、NSCondition 原理

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

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

3.1 生产者-消费者 案例

- (void)testNSCondition {
//创建生产-消费者
for (int i = 0; i < 10; i++) {
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{

            [self test_producer];

        });
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{

            [self test_consumer];

        });

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{

            [self test_consumer];

        });
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{

            [self test_producer];

        });

    }

}

- (void)test_producer{

    [self.condition lock];
self.ticketCount = self.ticketCount + 1;
NSLog(@"生产 + 1 剩余: %zd",self.ticketCount);

    [self.condition signal]; // 信号

    [self.condition unlock];

}

- (void)test_consumer{

    [self.condition lock];
if (self.ticketCount == 0) {
NSLog(@"等待 剩余: %zd",self.ticketCount);

        [self.condition wait];

    }
//消费行为，要在等待条件判断之后
self.ticketCount -= 1;
NSLog(@"消费 - 1 剩余: %zd ",self.ticketCount);

    [self.condition unlock];

}

输出：

生产 + 1 剩余: 1

消费 - 1 剩余: 0 

等待 剩余: 0

生产 + 1 剩余: 1

消费 - 1 剩余: 0 

等待 剩余: 0

等待 剩余: 0

等待 剩余: 0

生产 + 1 剩余: 1

消费 - 1 剩余: 0 

等待 剩余: 0

生产 + 1 剩余: 1

消费 - 1 剩余: 0 

等待 剩余: 0

等待 剩余: 0

生产 + 1 剩余: 1

消费 - 1 剩余: 0 

生产 + 1 剩余: 1

消费 - 1 剩余: 0 

生产 + 1 剩余: 1

消费 - 1 剩余: 0 

等待 剩余: 0

等待 剩余: 0

生产 + 1 剩余: 1

消费 - 1 剩余: 0 

生产 + 1 剩余: 1

消费 - 1 剩余: 0 

等待 剩余: 0

生产 + 1 剩余: 1

消费 - 1 剩余: 0 

生产 + 1 剩余: 1

消费 - 1 剩余: 0 

生产 + 1 剩余: 1

生产 + 1 剩余: 2

消费 - 1 剩余: 1 

消费 - 1 剩余: 0 

生产 + 1 剩余: 1

生产 + 1 剩余: 2

生产 + 1 剩余: 3

消费 - 1 剩余: 2 

生产 + 1 剩余: 3

消费 - 1 剩余: 2 

生产 + 1 剩余: 3

消费 - 1 剩余: 2 

消费 - 1 剩余: 1 

生产 + 1 剩余: 2

生产 + 1 剩余: 3

消费 - 1 剩余: 2 

消费 - 1 剩余: 1 

消费 - 1 剩余: 0 

因为有condition的存在保证了消费行为是在对应的生产行为之后。在这个过程中会有消费等待行为，signal信号通知消费。

• 生产和消费的加锁保证了各个事务的额安全。
• wait和signal保证了事务之间的安全。

3.2 源码分析

内部也是对pthread_mutex_init的包装，多了一个pthread_cond_init。

open func lock() {
pthread_mutex_lock(mutex)

}


open func unlock() {
pthread_mutex_unlock(mutex)

}


open func wait() {
pthread_cond_wait(cond, mutex)

}


open func signal() {
pthread_cond_signal(cond)

}


open func broadcast() {
pthread_cond_broadcast(cond)

}

代码中去掉了windows相关宏逻辑：

• NSCondition：锁（pthread_mutex_t） + 线程检查器（pthread_cond_t）
• 锁（pthread_mutex_t）：lock(pthread_mutex_lock) + unlock(pthread_mutex_unlock)
• 线程检查器（pthread_cond_t）：wait(pthread_cond_wait) + signal(pthread_cond_signal)

四、NSConditionLock 使用和原理

NSConditionLock也是锁，一旦一个线程获得锁，其他线程一定等待。它同样遵循NSLocking协议，相关API:

- (void)lockWhenCondition:(NSInteger)condition;
- (void)unlockWithCondition:(NSInteger)condition;
- (BOOL)lockWhenCondition:(NSInteger)condition beforeDate:(NSDate *)limit;

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

4.1案例

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];
sleep(1);
NSLog(@"2");

    [conditionLock unlockWithCondition:1];

});

dispatch_async(dispatch_get_global_queue(0, 0), ^{

   [conditionLock lock];
NSLog(@"3");

   [conditionLock unlock];

});

上面的案例2一定比1先执行，2与3之间无序。
输出：3 2 1，如果任务2的优先级改为High则输出顺序变为2 1 3。

那么有以下疑问：

• 1.NSConditionLock 与 NSCondition有关系么？
• 2.NSConditionLock初始化的时候condition是什么？
• 3.lockWhenCondition是如何控制的？
• 4.unlockWithCondition是如何控制的？

4.2 断点调试分析逻辑

在拿不到源码以及拿不到动态库的情况下，断点分析调用流程是一个比较好的方案。
分别在测试代码中打下以下断点：

运行工程到达断点后下符号断点-[NSConditionLock initWithCondition:]过掉断点:

这个时候就进入了initWithCondition的汇编实现。在汇编中对所有的b（跳转指令）下断点配合寄存器的值跟踪流程。

• -[NSConditionLock initWithCondition:]:

• 可以通过lldb读取寄存器的值，也可以查看全部寄存器中对应的值。

过掉断点继续：

最终返回了创建的NSConditionLock对象，它持有NSCondition对象以及初始化传的condition参数2。
-[NSConditionLock initWithCondition:]流程：

-[NSConditionLock initWithCondition:]

    -[xxx init]

    -[NSConditionLock init]

    -[NSConditionLock zone]

    +[NSCondition allocWithZone:]

    -[NSCondition init]

-[NSConditionLock lockWhenCondition:]：
同样添加-[NSConditionLock lockWhenCondition:]符号断点：

调用了-[NSCondition unlock]，这个时候继续过断点就又会回到线程4，调用逻辑和线程3相同。

完整调用逻辑如下：

线程4
-[NSConditionLock lockWhenCondition:]
+[NSDate distantFuture]
-[NSConditionLock lockWhenCondition:beforeDate:]
-[NSCondition lock]
-[NSCondition waitUntilDate:]

            线程3
-[NSConditionLock lockWhenCondition:]
+[NSDate distantFuture]
-[NSConditionLock lockWhenCondition:beforeDate:]
-[NSCondition lock]
-[NSCondition unlock]

                    返回1（true）
-[NSConditionLock unlockWithCondition:]
-[NSCondition lock]
-[NSCondition broadcast]
-[NSCondition unlock]
//回到线程4
-[NSCondition unlock]

        返回1（true）
-[NSConditionLock unlockWithCondition:]
-[NSCondition lock]
-[NSCondition broadcast]
-[NSCondition unlock]

流程总结：

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

作者：HotPotCat
链接：https://www.jianshu.com/p/8f8e5f0d0b23