今天遇到的问题是使用NSCondition加条件锁的时候，没有了解清楚condition加锁的时机，造成了短暂的死锁。
下面的代码是一个标准的死锁案例：
NSCondition *condition = [[NSCondition alloc] init];
dispatch_async(dispatch_get_global_queue(0, 0), ^{
[condition lock];
NSLog(@"wait for products");
[condition waitUntilDate:[NSDate dateWithTimeIntervalSinceNow:1]];
if (_products > 0) {
_products -= 1;
NSLog(@"consume a product");
}
else {
NSLog(@"�timeout");
}
[condition unlock];
});
dispatch_async(dispatch_get_global_queue(0, 0), ^{
[condition lock];
[NSThread sleepForTimeInterval:3];
_products += 1;
NSLog(@"produce a product");
[condition signal];
[condition unlock];
});
这里在两个不同的线程进行产品的生产与消费，开始产品量为0，消费线程进入等待，等待时间为1s，1s后有可用产品则消费，否则超时；生产线程模拟耗时操作3s后产出第一个产品后，发送信号，解锁等待。
我们期待的结果应该是超时，因为等待1s后仍然没有产品可用，然而代码却不按套路出牌…
错误的结果
这里耗时操作的模拟是3s，如果真实的耗时操作时间很长，那么消费线程则会陷入无限等待中。
正确的代码只需要修改一行，在生产线程中将加锁[condition lock]与模拟耗时操作[NSThread sleepForTimeInterval:3]两行进行交换即可。原因在于condition的wait操作是一个先解锁后加锁的过程，在调用wait时会立即解锁，等待时间结束后再重新加锁，这样既保证了等待时可以由其他线程进行加锁，又保证了等待结束后的操作满足线程安全，而重新加锁的前提是此时没有其他线程对该condition加锁，但是我在生产线程中一开始就加了锁，那么消费线程在1s的等待时间结束后想要加锁时，生产线程仍然没有释放锁，因此造成了死锁。两行互换后，消费线程重新加锁时，生产线程的模拟耗时操作还没有结束，也未对condition进行加锁，这里的死锁打开了，也可以按照我们的需求进行了。
正确的结果
正确的代码如下：
NSCondition *condition = [[NSCondition alloc] init];
dispatch_async(dispatch_get_global_queue(0, 0), ^{
[condition lock];
NSLog(@"wait for products");
[condition waitUntilDate:[NSDate dateWithTimeIntervalSinceNow:1]];
if (_products > 0) {
_products -= 1;
NSLog(@"consume a product");
}
else {
NSLog(@"�timeout");
}
[condition unlock];
});
dispatch_async(dispatch_get_global_queue(0, 0), ^{
[NSThread sleepForTimeInterval:3];
[condition lock];
_products += 1;
NSLog(@"produce a product");
[condition signal];
[condition unlock];
});
结论
应该只针对竞争资源进行加锁，不应该包括其他逻辑代码。
