iOS 了解锁

我们在使用多线程的时候多个线程可能会访问同一块资源，这样就很容易引发数据错乱和数据安全等问题。这时候我们需要保证每次只有一个线程访问这一块资源，锁应运而生。

@synchronizedNSLock对象锁NSRecursiveLock 递归锁NSCondition NSConditionLock 条件锁pthread_mutex 互斥锁（C语言）dispatch_semaphore 信号量实现加锁（GCD）OSSpinLock

1）、@synchronized关键字加锁互斥锁，性能较差不推荐使用

@synchronized（这里添加一个OC对象，一般使用self）{
这里写要加锁的代码
}
注意点
a.加锁的代码尽量少
b.添加的OC对象必须在多个线程中都是同一对象
c.优点是不需要显示创建锁对象，便可以实现锁的机制。
d.@synchronized块会隐式的添加一个异常处理例程来保护代码，该处理例程会在异常抛出的时候自动释放互斥锁。所以如果不想让隐式的异常处理例程带来额外的开销，可以考虑使用该锁对象。

2）、NSLock互斥锁不能多次调用lock方法，会造成死锁

在Cocoa程序中NSLock中实现了一个简单的互斥锁。所有锁（包括NSLock）的接口实际都是通过NSLocking协议定义的，它定义了lock和unlock方法。你使用这些方法来获取和释放该锁。
NSLock类还增加了tryLock和lockBeforeDate：方法。tryLock视图获取一个锁，但是如果锁不可用的时候，它不会阻塞线程，相反，它只是返回NO。
lockBeforeDate：方法视图获取一个锁，但是如果锁没有在规定的时间内被获取，它会让线程从阻塞状态变为非阻塞状态（或者返回NO）。

注意： NSLock 不能当做循环锁（也有称作递归锁或嵌套锁的，主要特点是允许相同线程多次上锁，并通过多次 unlock来解锁）来使用，同一线程在 lock之后未unlock 之前再次 lock 会造成永久性死锁。
循环锁，请使用 NSRecursiveLock 。

3）、NSRecursiveLock 递归锁

使用锁最容易犯的一个错误就是在递归或循环中造成死锁，在NSLock锁中，如果锁多次的lock，自己会被阻塞。

//创建锁              
_mutexLock = [[NSLock alloc]init];
//线程1
dispatch_async(self.concurrentQueue, ^{

static void(^TestMethod)(int);
    TestMethod = ^(int value)
    {
        [_mutexLock lock];
        if (value > 0)

 {
            [NSThread sleepForTimeInterval:1];
            TestMethod(value--);
        }
        [_mutexLock unlock];
    };

    TestMethod(5);
});

此处将NSLock换成NSRecursiveLock，便可解决问题。
NSRecursiveLock类定义的锁可以在同一线程多次lock，而不会造成死锁。
递归锁会跟踪它被多次lock。每次成功的lock都必须平衡调用unlock操作。
只有所有的锁住和解锁操作都平衡的时候，锁才真正被释放给其他线程获得。

NSRecursiveLock定义了一个可以被同一线程获得多次而不会造成死锁的 lock ，当前线程无论是单次上锁还是多次上锁，所有的其他线程都不能访问被锁保护的区域。

  //创建锁
_rsLock = [[NSRecursiveLock alloc] init];
 //线程1
 dispatch_async(self.concurrentQueue, ^{

static void(^TestMethod)(int);
    TestMethod = ^(int value)
    {
        [_rsLock lock];
        if (value > 0)
        {
            [NSThread sleepForTimeInterval:1];

        TestMethod(value--);
        }
        [_rsLock unlock];
    };
    TestMethod(5);
});

4）、NSConditionLock条件锁

//主线程中
NSConditionLock *theLock = [[NSConditionLock alloc] init];

//线程1
dispatch_async(self.concurrentQueue, ^{
    for (int i=0;i<=3;i++)
    {
        [theLock lock];
        NSLog(@"thread1:%d",i);
        sleep(1);

 [theLock unlockWithCondition:i];

   }
});

//线程2
dispatch_async(self.concurrentQueue, ^{
    [theLock lockWhenCondition:2];
    NSLog(@"thread2");

  [theLock unlock];
});

在线程1中的加锁使用了lock，是不需要条件的，所以顺利的就锁住了。
unlockWithCondition：在开锁的同时设置了一个整形的条件2。
线程2则需要一把被标识为2的钥匙，所以当线程1循环到i = 2时，线程2的任务才执行。
NSConditionLock也跟其他的锁一样，是需要lock与unlock对应的，只是lock，lockWhenCondition：与unlock，unlockWithCondition：是可以随意组合的，当然这是与你的需求相关的。

@interface NSConditionLock : NSObject <NSLocking> {
@private
    void *_priv;
}


- (instancetype)initWithCondition:(NSInteger)condition NS_DESIGNATED_INITIALIZER;

- (BOOL)tryLockWhenCondition:(NSInteger)condition;
- (void)unlockWithCondition:(NSInteger)condition;

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

@property (nullable, copy) NSString *name NS_AVAILABLE(10_5, 2_0);

@end

NSConditionLock 和 NSLock 类似，都遵循 NSLocking 协议，方法都类似，只是多了一个 condition 属性，以及每个操作都多了一个关于 condition 属性的方法，例如 tryLock，tryLockWhenCondition:，NSConditionLock 可以称为条件锁，只有 condition 参数与初始化时候的 condition 相等，lock 才能正确进行加锁操作。而 unlockWithCondition: 并不是当 Condition 符合条件时才解锁，而是解锁之后，修改 Condition 的值，这个结论可以从下面的例子中得出。

//主线程中
    NSConditionLock *lock = [[NSConditionLock alloc] initWithCondition:0];
    
    //线程1

  dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        [lock lockWhenCondition:1];
        NSLog(@"线程1");
        sleep(2);

   [lock unlock];
    });

    //线程2
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        sleep(1);//以保证让线程2的代码后执行

 if ([lock tryLockWhenCondition:0]) {
            NSLog(@"线程2");
            [lock unlockWithCondition:2];

 if ([lock tryLockWhenCondition:0]) {
            NSLog(@"线程2");
            [lock unlockWithCondition:2];

     NSLog(@"线程2解锁成功");
        } else {
            NSLog(@"线程2尝试加锁失败");
        }
    });

  
//线程3
 dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        sleep(2);//以保证让线程2的代码后执行

  if ([lock tryLockWhenCondition:2]) {
            NSLog(@"线程3");
            [lock unlock];
            NSLog(@"线程3解锁成功");
        } else {

       NSLog(@"线程3尝试加锁失败");
        }
    });

    //线程4
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        sleep(3);//以保证让线程2的代码后执行

 if ([lock tryLockWhenCondition:2]) {
            NSLog(@"线程4");
            [lock unlockWithCondition:1];    
            NSLog(@"线程4解锁成功");

        } else {
            NSLog(@"线程4尝试加锁失败");
        }
    });

2016-08-19 13:51:15.353 ThreadLockControlDemo[1614:110697] 线程2

2016-08-19 13:51:15.354 ThreadLockControlDemo[1614:110697] 线程2解锁成功
2016-08-19 13:51:16.353 ThreadLockControlDemo[1614:110689] 线程3

2016-08-19 13:51:16.353 ThreadLockControlDemo[1614:110689] 线程3解锁成功
2016-08-19 13:51:17.354 ThreadLockControlDemo[1614:110884] 线程4

2016-08-19 13:51:17.355 ThreadLockControlDemo[1614:110884] 线程4解锁成功
2016-08-19 13:51:17.355 ThreadLockControlDemo[1614:110884] 线程1

上面代码先输出了 ”线程 2“，因为线程 1 的加锁条件不满足，初始化时候的 condition 参数为 0，而加锁条件是 condition 为 1，所以加锁失败。locakWhenCondition 与 lock 方法类似，加锁失败会阻塞线程，所以线程 1 会被阻塞着，而 tryLockWhenCondition 方法就算条件不满足，也会返回 NO，不会阻塞当前线程。

回到上面的代码，线程 2 执行了 [lock unlockWithCondition:2]; 所以 Condition 被修改成了 2。

而线程 3 的加锁条件是 Condition 为 2，所以线程 3 才能加锁成功，线程 3 执行了 [lock unlock]; 解锁成功且不改变 Condition 值。

线程 4 的条件也是 2，所以也加锁成功，解锁时将 Condition 改成 1。这个时候线程 1 终于可以加锁成功，解除了阻塞。

从上面可以得出，NSConditionLock 还可以实现任务之间的依赖。

5）、NSCondition

看字面意思很好理解:
wait：进入等待状态
waitUntilDate:：让一个线程等待一定的时间
signal：唤醒一个等待的线程
broadcast：唤醒所有等待的线程
例子:

等待2秒
NSCondition *cLock = [NSCondition new];
//线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"start");
[cLock lock];
[cLock waitUntilDate:[NSDate dateWithTimeIntervalSinceNow:2]];
NSLog(@"线程1");
[cLock unlock];
});

唤醒一个等待线程


//线程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[cLock lock];
NSLog(@"线程2加锁成功");
[cLock wait];
NSLog(@"线程2");
[cLock unlock];
});

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
sleep(2);
NSLog(@"唤醒一个等待的线程");
[cLock signal];
});

唤醒所有等待的线程

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
sleep(2);
NSLog(@"唤醒所有等待的线程");
[cLock broadcast];
});

6）、pthread_mutex互斥锁

__block pthread_mutex_t mutex;
pthread_mutex_init(&amp;mutex, NULL);
//线程1
dispatch_async(self.concurrentQueue), ^{
  pthread_mutex_lock(&amp;mutex);
  NSLog(@"任务1");
  sleep(2);
  pthread_mutex_unlock(&amp;mutex);
});

//线程2
dispatch_async(self.concurrentQueue), ^{
  sleep(1);
  pthread_mutex_lock(&amp;mutex);
  NSLog(@"任务2");
  pthread_mutex_unlock(&amp;mutex);
});

7）、dispatch_semaphore信号量实现加锁

GCD中也已经提供了一种信号机制，使用它我们也可以来构建一把锁

dispatch_semaphore_t signal = dispatch_semaphore_create(1); //传入值必须 &gt;=0, 若传入为0则阻塞线程并等待timeout,时间到后会执行其后的语句
dispatch_time_t overTime = dispatch_time(DISPATCH_TIME_NOW, 3.0f * NSEC_PER_SEC);
//线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"线程1 等待ing");
dispatch_semaphore_wait(signal, overTime); //signal 值 -1
NSLog(@"线程1");
dispatch_semaphore_signal(signal); //signal 值 +1
NSLog(@"线程1 发送信号");
NSLog(@"--------------------------------------------------------");
   });
  //线程2
 dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"线程2 等待ing");
dispatch_semaphore_wait(signal, overTime);
NSLog(@"线程2");
dispatch_semaphore_signal(signal);
NSLog(@"线程2 发送信号");
});

dispatch_semaphore_create(1)：传入值必须 >=0, 若传入为 0 则阻塞线程并等待timeout,时间到后会执行其后的语句dispatch_semaphore_wait(signal, overTime)：可以理解为 lock,会使得 signal 值 -1dispatch_semaphore_signal(signal)：可以理解为 unlock,会使得 signal 值 +1运行结果

8）、OSSpinLock（不建议使用）

新版 iOS 中，系统维护了 5 个不同的线程优先级/QoS: background，utility，default，user-initiated，user-interactive。高优先级线程始终会在低优先级线程前执行，一个线程不会受到比它更低优先级线程的干扰。这种线程调度算法会产生潜在的优先级反转问题，从而破坏了 spin lock。

具体来说，如果一个低优先级的线程获得锁并访问共享资源，这时一个高优先级的线程也尝试获得这个锁，它会处于 spin lock 的忙等状态从而占用大量 CPU。此时低优先级线程无法与高优先级线程争夺 CPU 时间，从而导致任务迟迟完不成、无法释放 lock。这并不只是理论上的问题，libobjc 已经遇到了很多次这个问题了，于是苹果的工程师停用了 OSSpinLock。

1）、@synchronized关键字加锁互斥锁，性能较差不推荐使用

2）、NSLock互斥锁不能多次调用lock方法，会造成死锁

3）、NSRecursiveLock 递归锁

4）、NSConditionLock条件锁

5）、NSCondition

6）、pthread_mutex互斥锁

7）、dispatch_semaphore信号量实现加锁

8）、OSSpinLock（不建议使用）

AFN 3.1 .0 使用NSlock 、@synchronized和 dispatch_semaphore_t信号量实现加锁（老版本有使用过NSRecursiveLock） SDWebImage 使用@synchronized

猜你喜欢

iOS 了解锁

1）、@synchronized关键字加锁 互斥锁，性能较差不推荐使用

2）、NSLock互斥锁 不能多次调用lock方法，会造成死锁

3）、NSRecursiveLock 递归锁

4）、NSConditionLock条件锁

5）、NSCondition

6）、pthread_mutex互斥锁

7）、dispatch_semaphore信号量实现加锁

8）、OSSpinLock（不建议使用）

AFN 3.1 .0 使用NSlock 、@synchronized和 dispatch_semaphore_t信号量实现加锁（老版本有使用过NSRecursiveLock） SDWebImage 使用@synchronized

猜你喜欢

1）、@synchronized关键字加锁互斥锁，性能较差不推荐使用

2）、NSLock互斥锁不能多次调用lock方法，会造成死锁