这两天翻看 ibireme 大神 《不再安全的 OSSpinLock》 这篇文章，看到文中分析各种锁之前的性能的图表：
发现除了@synchronized 用过,其他的都陌生的很，可以说完全不知道....
于是怀着惭愧的心情赶紧把这些锁学习了下，废话不多说，我们开始:
锁 是什么意思？
我们在使用多线程的时候多个线程可能会访问同一块资源，这样就很容易引发数据错乱和数据安全等问题，这时候就需要我们保证每次只有一个线程访问这一块资源，锁 应运而生。
OSSpinLock
需导入头文件:
#import <libkern/OSAtomic.h>
例子：
__block OSSpinLock oslock = OS_SPINLOCK_INIT;
//线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"线程1 准备上锁");
OSSpinLockLock(&oslock);
sleep(4);
NSLog(@"线程1");
OSSpinLockUnlock(&oslock);
NSLog(@"线程1 解锁成功");
NSLog(@"--------------------------------------------------------");
});
//线程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"线程2 准备上锁");
OSSpinLockLock(&oslock);
NSLog(@"线程2");
OSSpinLockUnlock(&oslock);
NSLog(@"线程2 解锁成功");
});
运行结果：
我们来修改一下代码：
__block OSSpinLock oslock = OS_SPINLOCK_INIT;
//线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
......
//OSSpinLockUnlock(&oslock);
......
运行结果：
在 OSSpinLock1 图中可以发现：当我们锁住线程1时，在同时锁住线程2的情况下，线程2会一直等待（自旋锁不会让等待的进入睡眠状态），直到线程1的任务执行完且解锁完毕，线程2会立即执行；而在 OSSpinLock2 图中，因为我们注释掉了线程1中的解锁代码，会绕过线程1，直到调用了线程2的解锁方法才会继续执行线程1中的任务，正常情况下，lock和unlock最好成对出现。
OS_SPINLOCK_INIT： 默认值为
0,在locked状态时就会大于0，unlocked状态下为0
OSSpinLockLock(&oslock)：上锁，参数为OSSpinLock地址
OSSpinLockUnlock(&oslock)：解锁，参数为OSSpinLock地址
OSSpinLockTry(&oslock)：尝试加锁，可以加锁则立即加锁并返回YES,反之返回NO
这里顺便提一下trylock和lock使用场景：
当前线程锁失败，也可以继续其它任务，用 trylock 合适
当前线程只有锁成功后，才会做一些有意义的工作，那就 lock，没必要轮询 trylock
dispatch_semaphore 信号量
例子：
dispatch_semaphore_t signal = dispatch_semaphore_create(1); //传入值必须 >=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值-1
dispatch_semaphore_signal(signal)：可以理解为unlock,会使得signal值+1
关于信号量，我们可以用停车来比喻：
停车场剩余4个车位，那么即使同时来了四辆车也能停的下。如果此时来了五辆车，那么就有一辆需要等待。
信号量的值（signal）就相当于剩余车位的数目，dispatch_semaphore_wait函数就相当于来了一辆车，dispatch_semaphore_signal就相当于走了一辆车。停车位的剩余数目在初始化的时候就已经指明了（dispatch_semaphore_create（long value）），调用一次 dispatch_semaphore_signal，剩余的车位就增加一个；调用一次dispatch_semaphore_wait 剩余车位就减少一个；当剩余车位为 0 时，再来车（即调用 dispatch_semaphore_wait）就只能等待。有可能同时有几辆车等待一个停车位。有些车主没有耐心，给自己设定了一段等待时间，这段时间内等不到停车位就走了，如果等到了就开进去停车。而有些车主就像把车停在这，所以就一直等下去。
运行结果：
可以发现，因为我们初始化信号量的时候是大于 0 的，所以并没有阻塞线程，而是直接执行了 线程1 线程2。
我们把 信号量初始值改为 0:
dispatch_semaphore_t signal = dispatch_semaphore_create(0);
运行结果:
可以看到这时候我们设置的 overTime 生效了。
pthread_mutex
ibireme 在《不再安全的 OSSpinLock》这篇文章中提到性能最好的 OSSpinLock 已经不再是线程安全的并把自己开源项目中的 OSSpinLock 都替换成了 pthread_mutex。
特意去看了下源码，总结了下常见用法：
使用需导入头文件：
#import <pthread.h>
例子:
static pthread_mutex_t pLock;
pthread_mutex_init(&pLock, NULL);
//1.线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"线程1 准备上锁");
pthread_mutex_lock(&pLock);
sleep(3);
NSLog(@"线程1");
pthread_mutex_unlock(&pLock);
});
//1.线程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"线程2 准备上锁");
pthread_mutex_lock(&pLock);
NSLog(@"线程2");
pthread_mutex_unlock(&pLock);
});
运行结果:
pthread_mutex 中也有个
pthread_mutex_trylock(&pLock)，和上面提到的OSSpinLockTry(&oslock)区别在于，前者可以加锁时返回的是0，否则返回一个错误提示码；后者返回的YES和NO
这里贴个 YYKit 中的源码：
pthread_mutex(recursive)
经过上面几种例子，我们可以发现：加锁后只能有一个线程访问该对象，后面的线程需要排队，并且 lock 和 unlock 是对应出现的，同一线程多次 lock 是不允许的，而递归锁允许同一个线程在未释放其拥有的锁时反复对该锁进行加锁操作。
例子:
static pthread_mutex_t pLock;
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr); //初始化attr并且给它赋予默认
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE); //设置锁类型，这边是设置为递归锁
pthread_mutex_init(&pLock, &attr);
pthread_mutexattr_destroy(&attr); //销毁一个属性对象，在重新进行初始化之前该结构不能重新使用
//1.线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
static void (^RecursiveBlock)(int);
RecursiveBlock = ^(int value) {
pthread_mutex_lock(&pLock);
if (value > 0) {
NSLog(@"value: %d", value);
RecursiveBlock(value - 1);
}
pthread_mutex_unlock(&pLock);
};
RecursiveBlock(5);
});
运行结果:
上面的代码如果我们用
pthread_mutex_init(&pLock, NULL)初始化会出现死锁的情况，递归锁能很好的避免这种情况的死锁；
NSLock
NSLock API 很少也很简单:
lock、unlock：不多做解释，和上面一样
trylock：能加锁返回 YES 并执行加锁操作，相当于 lock，反之返回 NO
** lockBeforeDate：这个方法表示会在传入的时间内尝试加锁，若能加锁则执行加锁**操作并返回 YES，反之返回 NO
例子:
NSLock *lock = [NSLock new];
//线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"线程1 尝试加速ing...");
[lock lock];
sleep(3);//睡眠5秒
NSLog(@"线程1");
[lock unlock];
NSLog(@"线程1解锁成功");
});
//线程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"线程2 尝试加速ing...");
BOOL x = [lock lockBeforeDate:[NSDate dateWithTimeIntervalSinceNow:4]];
if (x) {
NSLog(@"线程2");
[lock unlock];
}else{
NSLog(@"失败");
}
});
运行结果:
NSCondition
我们先来看看 API：
看字面意思很好理解:
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];
});
结果:
- 唤醒一个等待线程
NSCondition *cLock = [NSCondition new];
//线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[cLock lock];
NSLog(@"线程1加锁成功");
[cLock wait];
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];
});
运行结果:
NSRecursiveLock
上面已经大概介绍过了：
递归锁可以被同一线程多次请求，而不会引起死锁。这主要是用在循环或递归操作中。
例子：
NSLock *rLock = [NSLock new];
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
static void (^RecursiveBlock)(int);
RecursiveBlock = ^(int value) {
[rLock lock];
if (value > 0) {
NSLog(@"线程%d", value);
RecursiveBlock(value - 1);
}
[rLock unlock];
};
RecursiveBlock(4);
});
运行结果:
这段代码是一个典型的死锁情况。在我们的线程中，RecursiveMethod 是递归调用的。所以每次进入这个 block 时，都会去加一次锁，而从第二次开始，由于锁已经被使用了且没有解锁，所以它需要等待锁被解除，这样就导致了死锁，线程被阻塞住了。
将 NSLock 替换为 NSRecursiveLock：
NSRecursiveLock *rLock = [NSRecursiveLock new];
..........
运行结果:
NSRecursiveLock 方法里还提供了两个方法，用法和上面介绍的基本没什么差别，这里不过多介绍了：
- (BOOL)tryLock;
- (BOOL)lockBeforeDate:(NSDate *)limit;
@synchronized
@synchronized 相信大家应该都熟悉，它的用法应该算这些锁中最简单的:
//线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
@synchronized (self) {
sleep(2);
NSLog(@"线程1");
}
});
//线程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
@synchronized (self) {
NSLog(@"线程2");
}
});
有兴趣可以看一下这篇文章 《 关于 @synchronized，这儿比你想知道的还要多》
NSConditionLock 条件锁
我们先来看看 API :
相比于 NSLock 多了个 condition 参数，我们可以理解为一个条件标示。
例子:
NSConditionLock *cLock = [[NSConditionLock alloc] initWithCondition:0];
//线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
if([cLock tryLockWhenCondition:0]){
NSLog(@"线程1");
[cLock unlockWithCondition:1];
}else{
NSLog(@"失败");
}
});
//线程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[cLock lockWhenCondition:3];
NSLog(@"线程2");
[cLock unlockWithCondition:2];
});
//线程3
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[cLock lockWhenCondition:1];
NSLog(@"线程3");
[cLock unlockWithCondition:3];
});
运行结果:
- 我们在初始化 NSConditionLock 对象时，给了他的标示为
0 - 执行
tryLockWhenCondition:时，我们传入的条件标示也是0,所 以线程1 加锁成功 - 执行
unlockWithCondition:时，这时候会把condition由0修改为1 - 因为
condition修改为了1， 会先走到 线程3，然后 线程3 又将condition修改为3 - 最后 走了 线程2 的流程
从上面的结果我们可以发现，NSConditionLock 还可以实现任务之间的依赖。
参考文献:
NSRecursiveLock递归锁的使用
关于dispatch_semaphore的使用
实现锁的多种方式和锁的高级用法
