iOS的OSSpinLock与os_unfair_lock
最近面试的时候给问到了锁，回答得不是很好，所以又重新学了一次，谨以此文记录学习成果
-
用锁的场景：多条线程存在同时操作（删、查、读、写）同一个文件or对象or变量。如果不是同时或者不是同一个那就不用加锁了。
-
介绍：OSSpinLock是在iOS10前还算比较常见的一钟锁，其是"忙等"的锁，所以适用于轻量级的操作，比如基本数据类型的加减，如int 的-1，+1操作,“忙等”的锁，大致的解析就是会一直 while（目标锁还未释放），然后一直执行，所以会很耗cpu的性能
-
还有另外一种锁的实现，是将线程状态改成休眠，然后等待唤醒。这种其实也不是很省资源，因为线程之间的切换也是非常耗性能的，大概需要20毫秒的时间。
-
隐患：会出现优先级翻转的情况.比如线程1优先级比较高，线程2优先级比较低，然后在某一时刻是线程2先获取到锁，所以先是线程2加锁，这时候，线程1就在while（目标锁还未释放），这个状态，但因为线程1优先级比较高，所以系统分配的时间比较多，有可能会没有分配时间给线程2执行后续的操作（需要做的任务和解锁）了，这时候就会造成死锁。
但如果是线程休眠的情况，在优先级高的线程休眠后，优先级比较低的线程会给系统调用，所以不会有死锁的情况
- 使用方法
//导入头文件
#import <libkern/OSAtomic.h>
//因为多个线程要公用一把锁，所以定义为属性，因为是c的，所以用assign
@property (assign, nonatomic) OSSpinLock mLock;
//创建
self. mLock = OS_SPINLOCK_INIT;
//加锁
OSSpinLockLock(&_moneyLock);
// <···你的代码···>
//解锁
OSSpinLockUnlock(&_moneyLock);
oc代码
image.png
这也就是我为什么在前面说iOS10之前自旋锁比较常见，其实在10之后，系统已经修改了OSSpinLock的实现方式了，改用了os_unfair_lock 来实现了
os_unfair_lock
介绍：
os_unfair_lock是在iOS10之后为了替代自旋锁OSSpinLock而诞生的，主要是通过线程休眠的方式来继续加锁，而不是一个“忙等”的锁。猜测是为了解决自旋锁的优先级反转的问题。
OC代码
image.png
使用：
#import <os/lock.h>
@property (assign, nonatomic) os_unfair_lock mLock;
self.mLock = OS_UNFAIR_LOCK_INIT;
os_unfair_lock_lock(&_mLock);
os_unfair_lock_unlock(&_mLock);
通过查看汇编代码来看2钟锁的不同
注意：要把系统调到10.0以下，我测试自旋锁的时候调到了9.0
初步代码
//
// ViewController.m
// OSSpinLockAndunfairlock
//
// Created by LJP on 2020/2/29.
// Copyright © 2020 L. All rights reserved.
//
#import "ViewController.h"
#import <libkern/OSAtomic.h>
#import <os/lock.h>
@interface ViewController ()
@property (assign, nonatomic) OSSpinLock mSpinLock;
//@property (assign, nonatomic) os_unfair_lock mUnfairLock;
@property (assign, nonatomic) NSInteger mCount;
@end
@implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
self.mSpinLock = OS_SPINLOCK_INIT;
self.mCount = 30;
NSLog(@"开始");
[self test];
}
- (void)test {
dispatch_queue_t queue = dispatch_get_global_queue(0, 0);
dispatch_async(queue, ^{
for (int i = 0; i < 10; i++) {
[self subCount];
}
});
dispatch_async(queue, ^{
for (int i = 0; i < 10; i++) {
[self subCount];
}
});
dispatch_async(queue, ^{
for (int i = 0; i < 10; i++) {
[self subCount];
}
});
}
- (void)subCount {
sleep(0.5);
self.mCount = self.mCount - 1;
NSLog(@"mCount == %ld name == %@ ", (long)self.mCount, [NSThread currentThread]);
}
@end
运行的结果如下
image.png
从控制图里可以看出如果不加锁顺序是会乱的，并且有可能最终的结果不是0
加锁之后
image.png
执行几次后，顺序没有乱
下面就是观察汇编代码了
- 调用10条线程去执行
!](https://img.haomeiwen.com/i3463764/1f4d50aeccb77483.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
-
首先把睡眠时间调高一点，然后运行
image.png
可以看到，是选运行线程6 再到线程8 再到线程9
-
调出显示汇编指令的面板
image.png
-
si指令 si是让汇编指令一条一条的向下走
image.png
当你多敲几次后你会发现，他会一直在这个范围里走来走去
-
jne指令 其实就是一个判断语句，如果符合条件，就跳去相应的行数
image.png
所以说自旋锁是相当于 while 一直在循环等待
下面开始测试os_unfair_lock
- 先把版本调高
*然后和自旋一样的操作
image.png
多次测试之后你会发现 走到syscall里就会跳会vc的画面,不会再有下一步的si了。
image.png
猜测是系统调用线程进入休眠了
总结
其实2个锁都耗性能，各有优劣，但可能是因为自旋锁会产生优先级反转，用互斥锁会比较安全
自旋锁在 循环等待的时候会消耗cpu的性能
互斥锁在 cpu线程调度的时候会消耗cpu性能
所以互斥锁，比较适合 临界代码 比较耗时间长的 比如 有网络阻塞 IO 阻塞的情况
自旋锁， 因为一直消耗cpu 所以 一般比较适合 临界代码比较少的 比较适合段时间操作的 比如 从 mutable 对象里面(dictioanry array hashtable) 读写操作的情况
最后的代码
//
// ViewController.m
// OSSpinLockAndunfairlock
//
// Created by LJP on 2020/2/29.
// Copyright © 2020 L. All rights reserved.
//
#import "ViewController.h"
#import <libkern/OSAtomic.h>
#import <os/lock.h>
@interface ViewController ()
//@property (assign, nonatomic) OSSpinLock mSpinLock;
@property (assign, nonatomic) os_unfair_lock mUnfairLock;
@property (assign, nonatomic) NSInteger mCount;
@end
@implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
// self.mSpinLock = OS_SPINLOCK_INIT;
self.mUnfairLock = OS_UNFAIR_LOCK_INIT;
self.mCount = 30;
NSLog(@"开始");
[self test];
}
- (void)test {
// dispatch_queue_t queue = dispatch_get_global_queue(0, 0);
//
// dispatch_async(queue, ^{
// for (int i = 0; i < 10; i++) {
// [self subCount];
// }
// });
//
// dispatch_async(queue, ^{
// for (int i = 0; i < 10; i++) {
// [self subCount];
// }
// });
//
// dispatch_async(queue, ^{
// for (int i = 0; i < 10; i++) {
// [self subCount];
// }
// });
for (int i = 0; i < 10; i++) {
[[[NSThread alloc] initWithTarget:self selector:@selector(subCount) object:nil] start];
}
}
- (void)subCount {
os_unfair_lock_lock(&_mUnfairLock);
sleep(60);
self.mCount = self.mCount - 1;
NSLog(@"mCount == %ld name == %@ ", (long)self.mCount, [NSThread currentThread]);
os_unfair_lock_unlock(&_mUnfairLock);
}
@end
