Objective-C中不同方式实现锁(二)

在上一文中，我们已经讨论过用Objective-C锁几种实现(跳转地址)，也用代码实际的演示了如何通过构建一个互斥锁来实现多线程的资源共享及线程安全，今天我们继续讨论锁的一些高级用法。

1.NSRecursiveLock递归锁

平时我们在代码中使用锁的时候，最容易犯的一个错误就是造成死锁，而容易造成死锁的一种情形就是在递归或循环中，如下代码:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

//主线程中 NSLock *theLock = [[NSLock alloc] init]; TestObj *obj = [[TestObj alloc] init]; //线程1 dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ static void(^TestMethod)(int); TestMethod = ^(int value) { [theLock lock]; if (value > 0) { [obj method1]; sleep(5); TestMethod(value-1); } [theLock unlock]; }; TestMethod(5); }); //线程2 dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ sleep(1); [theLock lock]; [obj method2]; [theLock unlock]; });

以上的代码中，就是一种典型的死锁情况，因为在线程1中的递归block中，锁会被多次的lock，所以自己也被阻塞了，由于以上的代码非常的简短，所以很容易能识别死锁，但在较为复杂的代码中，就不那么容易发现了，那么如何在递归或循环中正确的使用锁呢？此处的theLock如果换用NSRecursiveLock对象，问题便得到解决了，NSRecursiveLock类定义的锁可以在同一线程多次lock，而不会造成死锁。递归锁会跟踪它被多少次lock。每次成功的lock都必须平衡调用unlock操作。只有所有的锁住和解锁操作都平衡的时候，锁才真正被释放给其他线程获得。

2.NSConditionLock条件锁

当我们在使用多线程的时候，有时一把只会lock和unlock的锁未必就能完全满足我们的使用。因为普通的锁只能关心锁与不锁，而不在乎用什么钥匙才能开锁，而我们在处理资源共享的时候，多数情况是只有满足一定条件的情况下才能打开这把锁：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

//主线程中 NSConditionLock *theLock = [[NSConditionLock alloc] init]; //线程1 dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ for (int i=0;i<=2;i++) { [theLock lock]; NSLog(@"thread1:%d",i); sleep(2); [theLock unlockWithCondition:i]; } }); //线程2 dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ [theLock lockWhenCondition:2]; NSLog(@"thread2"); [theLock unlock]; });

在线程1中的加锁使用了lock，所以是不需要条件的，所以顺利的就锁住了，但在unlock的使用了一个整型的条件，它可以开启其它线程中正在等待这把钥匙的临界地，而线程2则需要一把被标识为2的钥匙，所以当线程1循环到最后一次的时候，才最终打开了线程2中的阻塞。但即便如此，NSConditionLock也跟其它的锁一样，是需要lock与unlock对应的，只是lock,lockWhenCondition:与unlock，unlockWithCondition:是可以随意组合的，当然这是与你的需求相关的。

3.NSDistributedLock分布式锁

以上所有的锁都是在解决多线程之间的冲突，但如果遇上多个进程或多个程序之间需要构建互斥的情景该怎么办呢？这个时候我们就需要使用到NSDistributedLock了，从它的类名就知道这是一个分布式的Lock，NSDistributedLock的实现是通过文件系统的，所以使用它才可以有效的实现不同进程之间的互斥，但NSDistributedLock并非继承于NSLock，它没有lock方法，它只实现了tryLock，unlock，breakLock，所以如果需要lock的话，你就必须自己实现一个tryLock的轮询，下面通过代码简单的演示一下吧：

程序A:

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{

1 2 3 4 5 6 7

lock = [[NSDistributedLock alloc] initWithPath:@"/Users/mac/Desktop/earning__"]; [lock breakLock]; [lock tryLock]; sleep(10); [lock unlock]; NSLog(@"appA: OK"); });

程序B:

1 2 3 4 5 6 7 8 9 10

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ lock = [[NSDistributedLock alloc] initWithPath:@"/Users/mac/Desktop/earning__"]; while (![lock tryLock]) { NSLog(@"appB: waiting"); sleep(1); } [lock unlock]; NSLog(@"appB: OK"); });

先运行程序A,然后立即运行程序B,根据打印你可以清楚的发现，当程序A刚运行的时候，程序B一直处于等待中，当大概10秒过后，程序B便打印出了appB:OK的输出，以上便实现了两上不同程序之间的互斥。/Users/mac/Desktop/earning__是一个文件或文件夹的地址，如果该文件或文件夹不存在，那么在tryLock返回YES时，会自动创建该文件/文件夹。在结束的时候该文件/文件夹会被清除，所以在选择的该路径的时候，应该选择一个不存在的路径，以防止误删了文件。

NSRecursiveLock实际上定义的是一个递归锁，这个锁可以被同一线程多次请求，而不会引起死锁。这主要是用在循环或递归操作中。我们先来看一个示例：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

NSLock *lock = [[NSLock alloc] init];   dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{        static void (^RecursiveMethod)(int);        RecursiveMethod = ^(int value) {            [lock lock];          if  (value > 0) {                NSLog(@ "value = %d" , value);              sleep(2);              RecursiveMethod(value - 1);          }          [lock unlock];      };        RecursiveMethod(5); });

这段代码是一个典型的死锁情况。在我们的线程中，RecursiveMethod是递归调用的。所以每次进入这个block时，都会去加一次锁，而从第二次开始，由于锁已经被使用了且没有解锁，所以它需要等待锁被解除，这样就导致了死锁，线程被阻塞住了。调试器中会输出如下信息：

1 2	value = 5 *** -[NSLock lock]: deadlock (  '(null)' )   *** Break on _NSLockError() to debug.

在这种情况下，我们就可以使用NSRecursiveLock。它可以允许同一线程多次加锁，而不会造成死锁。递归锁会跟踪它被lock的次数。每次成功的lock都必须平衡调用unlock操作。只有所有达到这种平衡，锁最后才能被释放，以供其它线程使用。

所以，对上面的代码进行一下改造，

1	NSRecursiveLock *lock = [[NSRecursiveLock alloc] init];

这样，程序就能正常运行了，其输出如下所示：

1 2 3 4 5

value = 5 value = 4 value = 3 value = 2 value = 1

NSRecursiveLock除了实现NSLocking协议的方法外，还提供了两个方法，分别如下：

1 2 3 4 5

// 在给定的时间之前去尝试请求一个锁 - (BOOL)lockBeforeDate:(NSDate *)limit   // 尝试去请求一个锁，并会立即返回一个布尔值，表示尝试是否成功 - (BOOL)tryLock

这两个方法都可以用于在多线程的情况下，去尝试请求一个递归锁，然后根据返回的布尔值，来做相应的处理。如下代码所示：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

NSRecursiveLock *lock = [[NSRecursiveLock alloc] init];   dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{        static void (^RecursiveMethod)(int);        RecursiveMethod = ^(int value) {            [lock lock];          if  (value > 0) {                NSLog(@ "value = %d" , value);              sleep(2);              RecursiveMethod(value - 1);          }          [lock unlock];      };        RecursiveMethod(5); });   dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{        sleep(2);      BOOL flag = [lock lockBeforeDate:[NSDate dateWithTimeIntervalSinceNow:1]];      if  (flag) {          NSLog(@ "lock before date" );            [lock unlock];      }  else  {          NSLog(@ "fail to lock before date" );      } });

在前面的代码中，我们又添加了一段代码，增加一个线程来获取递归锁。我们在第二个线程中尝试去获取递归锁，当然这种情况下是会失败的，输出结果如下：

1 2 3 4 5 6

value = 5 value = 4 fail to lock before date value = 3 value = 2 value = 1

另外，NSRecursiveLock还声明了一个name属性，如下：

1	@property(copy) NSString *name

我们可以使用这个字符串来标识一个锁。Cocoa也会使用这个name作为错误描述信息的一部分。

参考http://www.cocoachina.com/ios/20150513/11808.html