背景：最近在项目中涉及到很多锁方面的知识，于是在项目完成后，决定把最近关于锁的知识记录下来，方便自己以后查询
- 锁的相关概念
- 锁的性能比较
- 锁的用法
- 各种锁的优缺点
概念
0.锁： 语言的并发程序设计，一直是一个比较困难且不可避免的话题。多数程序员都会尝试使用多线程编程，但是却很难保证自己所写的多线程程序的正确性。多线程程序，如果涉及到对共享资源的并发读写，就会产生资源争用。解决资源争用，最直接的想法是引入锁，对并发读写的数据进行保护。
1.死锁：死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。当然，产生死锁有四个条件，有需要深入了解的我在后文给链接
2.互斥锁：最常使用于线程同步的锁；标记用来保证在任一时刻，只能有一个线程访问该对象，同一线程多次加锁操作会造成死锁；临界区和互斥量都可用来实现此锁，通常情况下锁操作失败会将该线程睡眠等待锁释放时被唤醒
3.自旋锁：同样用来标记只能有一个线程访问该对象，在同一线程多次加锁操作会造成死锁；同互斥锁不同的是在锁操作需要等待的时候并不是睡眠等待唤醒，而是循环检测保持者已经释放了锁，这样做的好处是节省了线程从睡眠状态到唤醒之间内核会产生的消耗，在加锁时间短暂的环境下这点会提高很大效率
4.递归锁：严格上讲递归锁只是互斥锁的一个特例，同样只能有一个线程访问该对象，但允许同一个线程在未释放其拥有的锁时反复对该锁进行加锁操作；
iOS常用锁的性能比较
这个问题我没有去测试，引用一张大神测试后的照片截图
这是参考式链接：
[libireme 不再安全的 OSSpinLock]:
https://blog.ibireme.com/2016/01/16/spinlock_is_unsafe_in_ios/
iOS 锁的用法
OSSpinLock
OSSpinLock 使用方法
- (void)testOSSpinLock{
__block OSSpinLock oslock = OS_SPINLOCK_INIT;
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"线程1 准备上锁");
OSSpinLockLock(&oslock);
NSLog(@"线程1 执行任务");
OSSpinLockUnlock(&oslock);
NSLog(@"线程1 解锁成功");
});
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"线程2 准备上锁");
OSSpinLockLock(&oslock);
NSLog(@"线程2 执行任务");
OSSpinLockUnlock(&oslock);
NSLog(@"线程2 解锁成功");
});
}
OSSpinLock 存在问题
新版 iOS 中，系统维护了 5 个不同的线程优先级/QoS: background，utility，default，user-initiated，user-interactive。高优先级线程始终会在低优先级线程前执行，一个线程不会受到比它更低优先级线程的干扰。这种线程调度算法会产生潜在的优先级反转问题，从而破坏了 spin lock。
具体来说，如果一个低优先级的线程获得锁并访问共享资源，这时一个高优先级的线程也尝试获得这个锁，它会处于 spin lock 的忙等状态从而占用大量 CPU。此时低优先级线程无法与高优先级线程争夺 CPU 时间，从而导致任务迟迟完不成、无法释放 lock。这并不只是理论上的问题，libobjc 已经遇到了很多次这个问题了，于是苹果的工程师停用了 OSSpinLock。
苹果工程师 Greg Parker 提到，对于这个问题，一种解决方案是用 truly unbounded backoff 算法，这能避免 livelock 问题，但如果系统负载高时，它仍有可能将高优先级的线程阻塞数十秒之久；另一种方案是使用 handoff lock 算法，这也是 libobjc 目前正在使用的。锁的持有者会把线程 ID 保存到锁内部，锁的等待者会临时贡献出它的优先级来避免优先级反转的问题。理论上这种模式会在比较复杂的多锁条件下产生问题，但实践上目前还一切都好。
libobjc 里用的是 Mach 内核的 thread_switch() 然后传递了一个 mach thread port 来避免优先级反转，另外它还用了一个私有的参数选项，所以开发者无法自己实现这个锁。另一方面，由于二进制兼容问题，OSSpinLock 也不能有改动。
最终的结论就是，除非开发者能保证访问锁的线程全部都处于同一优先级，否则 iOS 系统中所有类型的自旋锁都不能再使用了。
这是参考式链接：
[libireme 不再安全的 OSSpinLock]:
https://blog.ibireme.com/2016/01/16/spinlock_is_unsafe_in_ios/
dispatch_semaphore
dispatch_semaphore
信号量是一个整形值并且具有一个初始计数值，并且支持两个操作：信号通知和等待。当一个信号量被信号通知，其计数会被增加。当一个线程在一个信号量上等待时，线程会被阻塞（如果有必要的话），直至计数器大于零，然后线程会减少这个计数,在GCD中有三个函数是semaphore的操作
dispatch_semaphore_create(传入值)： 传入值必须 >=0, 若传入为 0 则阻塞线程并等待timeout,时间到后会执行其后的语句
dispatch_semaphore_wait(signal, overTime)：可以理解为 lock,会使得 signal 值 -1
dispatch_semaphore_signal(signal)：可以理解为 unlock,会使得 signal 值 +1
- (void)dispatchSemaphore{
dispatch_semaphore_t signal = dispatch_semaphore_create(1);
//等待时间
dispatch_time_t overTime = DISPATCH_TIME_FOREVER;
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
//等同加锁 -1
dispatch_semaphore_wait(signal, overTime);
NSLog(@"线程1 执行任务");
sleep(10);
//发通知 等同解锁 +1
dispatch_semaphore_signal(signal);
NSLog(@"线程1 解锁");
});
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
//等同加锁 -1
dispatch_semaphore_wait(signal, overTime);
NSLog(@"线程2 执行任务");
//发通知 等同解锁 +1
dispatch_semaphore_signal(signal);
NSLog(@"线程2 解锁");
});
}
NSCondition
NSCondition 的对象实际上作为一个锁和一个线程检查器：锁主要为了当检测条件时保护数据源，执行条件引发的任务；线程检查器主要是根据条件决定是否继续运行线程，即线程是否被阻塞。
- wait：进入等待状态
- waitUntilDate:：让一个线程等待一定的时间
- signal：唤醒一个等待的线程
- broadcast：唤醒所有等待的线程
NSCondition 使用方法
假定：有A、B......两个个任务，没有执行顺序，或者只能确定确定一个执行任务,看下面代码，以及执行结果
- (void)testConditionLock{
NSCondition *condition = [[NSCondition alloc] init];
//线程一
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[condition lock];
NSLog(@"线程一 加锁成功");
[condition wait];
NSLog(@"线程一 执行任务");
[condition unlock];
NSLog(@"线程一 解锁");
[condition signal];
});
//线程二
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[condition lock];
NSLog(@"线程二 加锁成功");
[condition wait];
NSLog(@"线程二 执行任务");
[condition unlock];
NSLog(@"线程二 解锁");
[condition signal];
});
//线程三
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
[condition lock];
NSLog(@"线程三 加锁成功");
//[condition wait];
NSLog(@"线程三 执行任务");
[condition unlock];
NSLog(@"线程三 解锁");
[condition signal];
});
}
结果
2018-03-21 17:06:23.156804+0800 Lock-test[74191:6464691] 线程一 加锁成功
2018-03-21 17:06:23.157058+0800 Lock-test[74191:6464694] 线程二 加锁成功
2018-03-21 17:06:23.157413+0800 Lock-test[74191:6464693] 线程三 加锁成功
2018-03-21 17:06:23.158964+0800 Lock-test[74191:6464693] 线程三 执行任务
2018-03-21 17:06:23.159106+0800 Lock-test[74191:6464693] 线程三 解锁
2018-03-21 17:06:23.159695+0800 Lock-test[74191:6464691] 线程一 执行任务
2018-03-21 17:06:23.159942+0800 Lock-test[74191:6464691] 线程一 解锁
2018-03-21 17:06:23.160125+0800 Lock-test[74191:6464694] 线程二 执行任务
2018-03-21 17:06:23.160249+0800 Lock-test[74191:6464694] 线程二 解锁
NSCondition 缺点：
不能保证任务有序执行，只能确保第一执行的任务
NSConditionLock
条件锁，一个线程获得了锁，其它线程等待
tryLockWhenCondition：表示如果没有其他线程获得该锁，但是该锁内部的condition不等于条件，它依然不能获得锁，仍然等待
unlockWithCondition:： 解锁成功，并指向下个一条件
NSConditionLock 使用方法
假定：有A、B、C三个任务，需要执行的顺序是B->A->C
- (void)testConditonLock{
NSConditionLock *condition = [[NSConditionLock alloc] initWithCondition:2];
//线程一
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"线程一 加锁");
[condition lockWhenCondition:1];
NSLog(@"线程一 执行任务");
[condition unlockWithCondition:3];
});
//线程二
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"线程二 加锁");
if([condition tryLockWhenCondition:2]){
NSLog(@"线程二 执行任务");
}else{
NSLog(@"执行任务失败");
}
[condition unlockWithCondition:1];
});
//线程三
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"线程三 加锁");
[condition lockWhenCondition:3];
NSLog(@"线程三 执行任务");
// [condition unlockWithCondition:3];
});
}
2018-03-21 17:23:45.333313+0800 Lock-test[74523:6479604] 线程二 加锁
2018-03-21 17:23:45.333313+0800 Lock-test[74523:6479607] 线程一 加锁
2018-03-21 17:23:45.333313+0800 Lock-test[74523:6479605] 线程三 加锁
2018-03-21 17:23:45.333687+0800 Lock-test[74523:6479604] 线程二 执行任务
2018-03-21 17:23:45.335576+0800 Lock-test[74523:6479607] 线程一 执行任务
2018-03-21 17:23:45.335783+0800 Lock-test[74523:6479605] 线程三 执行任务
NSConditionLock 优点：
可以在加锁的同时，保证任务有序进行。缺点可能就是所谓性能低了
synchronized
synchronized 递归锁，最常见，也是最常用的锁。
- (void)testSYnchronized{
//线程一
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
@synchronized(self){
NSLog(@"线程一");
[self test:@"=="];
}
});
//线程二
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
@synchronized(self){
NSLog(@"线程二");
[self test:@"================================="];
}
});
}
- (void)test:(NSString *)test{
while (1) {
NSLog(@"%@", test);
}
}
参考资料
https://juejin.im/entry/5a00f59ff265da4314401967
http://blog.csdn.net/qq_30513483/article/details/52349968
https://blog.ibireme.com/2016/01/16/spinlock_is_unsafe_in_ios/
