iOS开发中常用的几种锁
简介：
操作系统在进行多线程调度的时候，为了保证多线程安全引入了锁的机制，以实现指定代码或资源在某时间内只可以被有限个线程访问。这里主要介绍iOS开发中，使用Objective-C开发所用到的几种锁的用法。
1 iOS开发中常用的几种锁
1.1 OSSpinLock 自旋锁
1.2 pthread_mutex
1.3 pthread_mutex(recursive)
1.4 NSLock
1.5 dispatch_semaphore
1.6 NSCondition
1.7 NSRecursiveLock
1.8 NSConditionLock
1.9 @synchronized
以上为OC作iOS开发语言时常用到的锁，其中pthread_mutex和pthread_mutex(recursive) 是C语言实现的，来源于遵循POSIX标准的pthread多线程库。
2 各个锁的特点和使用方法以及性能总结
2.1 OSSpinLock（已被弃用）
OSSpinLock 是一种自旋锁，也只有加锁，解锁，尝试加锁三个方法，其中尝试加锁是非线程阻塞的。可用通过 #import
OSSpinLock theLock = OS_SPINLOCK_INIT;
OSSpinLockLock(&theLock);
//要执行的代码
OSSpinLockUnlock(&theLock);
OSSpinlock可能造成死锁的原因：
OSSpinLock 不再安全，原因是有可能在优先级比较低的线程里对共享资源进行加锁了，然后高优先级的线程抢占了低优先级的调用CPU时间，导致高优先级的线程一直在等待低优先级的线程释放锁，然而低优先级根本没法抢占高优先级的CPU时间。这种情况我们称作 优先级倒转。
2.2 pthread_mutex 和 pthread_mutex(recursive)
pthread_mutex表示互斥锁, 当锁被占用，而其他线程申请锁时，不是使用忙等，而是阻塞线程并睡眠。将线程从睡眠状态中唤醒也是比较耗费内存资源
示例：
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL); // 定义锁的属性
pthread_mutex_t mutex;
pthread_mutex_init(&mutex, &attr) // 创建锁
pthread_mutex_lock(&mutex); // 申请锁
//线程安全区域
pthread_mutex_unlock(&mutex); // 释放锁
pthread_mutex(recursive)是递归锁，也就是允许一个线程递归的申请锁，只要把 attr 的类型改成 PTHREAD_MUTEX_RECURSIVE 即可.
2.3 NSLock
NSLock是非递归锁，当同一线程重复获取同一非递归锁时，就会发生死锁
https://www.jianshu.com/p/6116ec8a5595
原因如下：由于当前线程运行到第一个lock加锁，现在再次运行到lock同样的锁，需等待当前线程解锁，把当前线程挂起，不能解锁
NSLock是非递归锁，当同一线程重复获取同一非递归锁时，就会发生死锁
解决办法：
我们可以用NSRecursiveLock或者@synchronized替代NSLock
因为NSRecursiveLock或者@synchronized都是递归锁，
递归锁：它允许同一线程多次加锁，而不会造成死锁。
NSLock 是OC以对象的形式暴露给开发者的一种锁，它的实现非常简单，通过宏，定义了 lock 方法:
#define MLOCK \
- (void) lock\
{\
int err = pthread_mutex_lock(&_mutex);\
// 错误处理 ……
}
NSLock 只是在内部封装了一个 pthread_mutex，属性为 PTHREAD_MUTEX_ERRORCHECK，它会损失一定性能换来错误提示。
这里使用宏定义的原因是，OC 内部还有其他几种锁，他们的 lock 方法都是一模一样，仅仅是内部 pthread_mutex 互斥锁的类型不同。通过宏定义，可以简化方法的定义。
NSLock 比 pthread_mutex 略慢的原因在于它需要经过方法调用，同时由于缓存的存在，多次方法调用不会对性能产生太大的影响。
OSSpinLock 和 NSlock的比较
NSLock 请求加锁失败的话，会先轮询，但一秒过后便会使线程进入 waiting 状态，等待唤醒。而 OSSpinLock 会一直轮询，等待时会消耗大量 CPU 资源，不适用于较长时间的任务。
2.4 dispatch_semaphore
dispatch_semaphore 是 GCD 使用信号量控制并发，相比较OSSpinLock等待状态消耗 CPU 资源。 相关的三个函数：
1.创建信号量，
2.等待信号
3.发送信号
dispatch_semaphore_create(long value); dispatch_semaphore_wait(dispatch_semaphore_t dsema, dispatch_time_t timeout);
dispatch_semaphore_signal(dispatch_semaphore_t dsema);
当设置信号量为 1 时，一个 dispatch_semaphore_wait(signal, overTime); 方法对应一个 dispatch_semaphore_signal(signal); 类似NSLock 的 lock 和 unlock，区别在于有信号量这个参数，lock unlock 只能同一时间，一个线程访问被保护的临界区，而如果 dispatch_semaphore 的信号量初始值为 x ，则可以有 x 个线程同时访问被保护的临界区，即可以控制多个线程并发。
2.5 NSCondition
NSCondition 的底层是通过条件变量(condition variable) pthread_cond_t 来实现的。条件变量有点像信号量，提供了线程阻塞与信号机制，因此可以用来阻塞某个线程，并等待某个数据就绪，随后唤醒线程，比如常见的生产者-消费者模式。
示例：
NSCondition *lock = [[NSCondition alloc] init];
//线程1
[lock lock];
[lock wait]; // 线程被挂起
[lock unlock];
//线程2
sleep(1);//以保证让线程2的代码后执行
[lock lock];
[lock signal]; // 唤醒线程1
[lock unlock];
2.6 NSRecursiveLock
递归锁也是通过 pthread_mutex_lock 函数来实现，在函数内部会判断锁的类型，如果显示是递归锁，就允许递归调用，仅仅将一个计数器加一，锁的释放过程也是同理。
NSRecursiveLock 与 NSLock 的区别在于内部封装的 pthread_mutex_t 对象的类型不同，前者的类型为 PTHREAD_MUTEX_RECURSIVE。
2.7 NSConditionLock
NSConditionLock 可以称为条件锁，只有 condition 参数与初始化时候的 condition 相等，lock 才能正确进行加锁操作。而 unlockWithCondition: 并不是当 Condition 符合条件时才解锁，而是解锁之后，修改 Condition 的值。
NSConditionLock 借助 NSCondition 来实现，它的本质就是一个生产者-消费者模型。“条件被满足”可以理解为生产者提供了新的内容。NSConditionLock 的内部持有一个 NSCondition 对象，以及 _condition_value 属性，在初始化时就会对这个属性进行赋值:
// 简化版代码
- (id) initWithCondition: (NSInteger)value {
if (nil != (self = [super init])) {
_condition = [NSCondition new]
_condition_value = value;
}
return self;
}
它的 lockWhenCondition 方法其实就是消费者方法:
- (void) lockWhenCondition: (NSInteger)value {
[_condition lock];
while (value != _condition_value) {
[_condition wait];
}
}
对应的 unlockWhenCondition 方法则是生产者，使用了 broadcast 方法通知了所有的消费者:
- (void) unlockWithCondition: (NSInteger)value {
_condition_value = value;
[_condition broadcast];
[_condition unlock];
}
2.8 @synchronized
这其实是一个 OC 层面的锁，主要是通过牺牲性能换来语法上的简洁与可读。
@synchronized 后面需要紧跟一个 OC 对象，它实际上是把这个对象当做锁的唯一标识。这是通过一个哈希表来记录表示，OC 在底层使用了一个互斥锁的数组(你可以理解为锁池)，通过对对象去哈希值在数组中得到对应的互斥锁。
示例：
@synchronized(self) {
//线程安全代码
}
3 性能对比
下图通过加锁耗时简单的比较了各种锁的加解锁性能
性能测试源码：
https://github.com/ibireme/tmp/blob/master/iOSLockBenckmark/iOSLockBenckmark/ViewController.m