首先看一下它们的性能对比:
性能对比图下面开始逐个分析
1. OSSpinLock 自旋锁
引入头文件 #import <libkern/OSAtomic.h>
- (void)viewDidLoad {
[super viewDidLoad];
[self testLock];
}
- (void)testLock {
dispatch_queue_t queue = dispatch_queue_create("com.test.a", DISPATCH_QUEUE_CONCURRENT);
//设置票的数量为5
_tickets = 5;
//创建锁
_pinLock = OS_SPINLOCK_INIT;
//线程1
dispatch_async(queue, ^{
[self saleTickets];
});
//线程2
dispatch_async(queue, ^{
[self saleTickets];
});
}
- (void)saleTickets
{
while (1) {
[NSThread sleepForTimeInterval:1];
//加锁
OSSpinLockLock(&_pinLock);
if (_tickets > 0) {
_tickets--;
NSLog(@"剩余票数= %ld, Thread:%@",_tickets,[NSThread currentThread]);
} else {
NSLog(@"票卖完了 Thread:%@",[NSThread currentThread]);
break;
}
//解锁
OSSpinLockUnlock(&_pinLock);
}
}
2. os_unfair_lock iOS10以后代替自旋锁
os_unfair_lock用于取代不安全的OSSpinLock ,从iOS10开始才支持
从底层调用看,等待os_unfair_lock锁的线程会处于休眠状态,并非忙等
需要引入头文件#import <os/lock.h>
- (void)viewDidLoad {
[super viewDidLoad];
[self testLock];
}
- (void)testLock {
dispatch_queue_t queue = dispatch_queue_create("com.test.a", DISPATCH_QUEUE_CONCURRENT);
//设置票的数量为5
_tickets = 5;
//创建锁
_pinLock = OS_UNFAIR_LOCK_INIT;
//线程1
dispatch_async(queue, ^{
[self saleTickets];
});
//线程2
dispatch_async(queue, ^{
[self saleTickets];
});
}
- (void)saleTickets
{
while (1) {
//加锁
os_unfair_lock_lock(&_pinLock);
[NSThread sleepForTimeInterval:1];
if (_tickets > 0) {
_tickets--;
NSLog(@"剩余票数= %ld, Thread:%@",_tickets,[NSThread currentThread]);
} else {
NSLog(@"票卖完了 Thread:%@",[NSThread currentThread]);
break;
}
//解锁
os_unfair_lock_unlock(&_pinLock);
}
}
3. dispatch_semaphore 信号量实现加锁
dispatch_semaphore实现的原理,首先会先将信号量减一,并判断是否大于等于0,如果是,则返回0,并继续执行后续代码,否则,使线程进入睡眠状态,让出cpu时间。直到信号量大于0或者超时,则线程会被重新唤醒执行后续操作。
dispatch_semaphore_create(1);为1说明只可以同时执行一个线程,如果为2可以同时执行两个线程,为N可以同时执行N个线程,同时执行也就是说同时执行的这些线程不具备线程安全
- (void)viewDidLoad {
[super viewDidLoad];
[self testLock];
}
- (void)testLock {
dispatch_queue_t queue = dispatch_queue_create("com.test.a", DISPATCH_QUEUE_CONCURRENT);
__block int i = 0;
// 创建信号量
dispatch_semaphore_t semaphore = dispatch_semaphore_create(1);
//线程1
dispatch_async(queue, ^{
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
i++;
sleep(1);
i--;
NSLog(@"任务1 %d", i);
dispatch_semaphore_signal(semaphore);
});
//线程2
dispatch_async(queue, ^{
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
i++;
sleep(1);
i--;
NSLog(@"任务2 %d", i);
dispatch_semaphore_signal(semaphore);
});
//线程3
dispatch_async(queue, ^{
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
i++;
sleep(1);
i--;
NSLog(@"任务3 %d", i);
dispatch_semaphore_signal(semaphore);
});
}
例如以上代码,当dispatch_semaphore_create(3) 填写大于等于2时,输出结果是不确定的,如下所示
2019-03-09 21:26:53.920783+0800 test[5048:460547] 任务1 2
2019-03-09 21:26:53.920783+0800 test[5048:460548] 任务2 2
2019-03-09 21:26:53.920784+0800 test[5048:460545] 任务3 1
2019-03-09 21:28:53.449173+0800 test[5083:462224] 任务1 1
2019-03-09 21:28:53.449174+0800 test[5083:462242] 任务2 2
2019-03-09 21:28:53.449251+0800 test[5083:462225] 任务3 0
只有填写1的时候才能保证线程安全
4. pthread_mutex 互斥锁
阻塞线程并进入睡眠
- (void)viewDidLoad {
[super viewDidLoad];
[self testLock];
}
- (void)testLock {
dispatch_queue_t queue = dispatch_queue_create("com.test.a", DISPATCH_QUEUE_CONCURRENT);
__block pthread_mutex_t mutex;
pthread_mutex_init(&mutex, NULL);
//线程1
dispatch_async(queue, ^{
pthread_mutex_lock(&mutex);
NSLog(@"任务1");
sleep(2);
pthread_mutex_unlock(&mutex);
});
//线程2
dispatch_async(queue, ^{
pthread_mutex_lock(&mutex);
NSLog(@"任务2");
sleep(1);
pthread_mutex_unlock(&mutex);
});
}
5. NSLock 互斥锁 不能多次调用 lock方法,会造成死锁
NSLock在内部封装了一个 pthread_mutex
在Cocoa程序中NSLock中实现了一个简单的互斥锁。 所有锁(包括NSLock)的接口实际上都是通过NSLocking协议定义的,它定义了lock和unlock方法。你使用这些方法来获取和释放该锁。 NSLock类还增加了tryLock和lockBeforeDate:方法。 tryLock试图获取一个锁,但是如果锁不可用的时候,它不会阻塞线程,相反,它只是返回NO。 lockBeforeDate:方法试图获取一个锁,但是如果锁没有在规定的时间内被获得,它会让线程从阻塞状态变为非阻塞状态(或者返回NO)。
- (void)viewDidLoad {
[super viewDidLoad];
[self testLock];
}
- (void)testLock {
//设置票的数量为5
_tickets = 5;
_mutexLock = [[NSLock alloc] init];
dispatch_queue_t queue = dispatch_queue_create("com.test.a", DISPATCH_QUEUE_CONCURRENT);
//线程1
dispatch_async(queue, ^{
[self saleTickets];
});
//线程2
dispatch_async(queue, ^{
[self saleTickets];
});
}
- (void)saleTickets
{
while (1) {
[NSThread sleepForTimeInterval:1];
//加锁
[_mutexLock lock];
if (_tickets > 0) {
_tickets--;
NSLog(@"剩余票数= %ld, Thread:%@",_tickets,[NSThread currentThread]);
} else {
NSLog(@"票卖完了 Thread:%@",[NSThread currentThread]);
break;
}
//解锁
[_mutexLock unlock];
}
}
结果和上边一样就不再赘述
6. NSCondition
NSCondition有点类似于携程,先执行一部分任务,然后跳转到其他地方执行,完了以后再回来
- (void)viewDidLoad {
[super viewDidLoad];
[self testLock];
}
- (void)testLock {
_condition = [[NSCondition alloc] init];
dispatch_queue_t queue = dispatch_queue_create("com.test.a", DISPATCH_QUEUE_CONCURRENT);
//设置票的数量为5
_tickets = 5;
//线程1
dispatch_async(queue, ^{
[self saleTickets1];
});
//线程1
dispatch_async(queue, ^{
[self saleTickets2];
});
}
- (void)saleTickets1
{
[_condition lock];
_tickets--;
NSLog(@"剩余票数 = %ld, Thread:%@", _tickets, [NSThread currentThread]);
if (_tickets == 4) {
[_condition wait];
}
_tickets--;
NSLog(@"剩余票数 = %ld, Thread:%@", _tickets, [NSThread currentThread]);
[_condition unlock];
}
- (void)saleTickets2
{
//加锁
[_condition lock];
[NSThread sleepForTimeInterval:1];
_tickets--;
NSLog(@"我是VIP我来插队了 剩余票数 = %ld, Thread:%@", _tickets, [NSThread currentThread]);
[_condition signal];
//解锁
[_condition unlock];
7. pthread_mutex(recursive) 递归锁
- (void)viewDidLoad {
[super viewDidLoad];
[self testLock];
}
- (void)testLock {
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
pthread_mutex_init(&_lock, &attr); //设置属性
dispatch_queue_t queue = dispatch_queue_create("com.test.a", DISPATCH_QUEUE_CONCURRENT);
//设置票的数量为5
_tickets = 5;
//线程1
dispatch_async(queue, ^{
[self saleTickets];
});
}
- (void)saleTickets
{
while (1) {
//加锁
pthread_mutex_lock(&_lock);
[NSThread sleepForTimeInterval:1];
if (_tickets > 0) {
_tickets--;
NSLog(@"剩余票数= %ld, Thread:%@",_tickets,[NSThread currentThread]);
[self saleTickets];
} else {
NSLog(@"票卖完了 Thread:%@",[NSThread currentThread]);
break;
}
//解锁
pthread_mutex_unlock(&_lock);
}
}
8. NSRecursiveLock 递归锁
使用锁最容易犯的一个错误就是在递归或循环中造成死锁 如下代码中,因为在线程1中的递归block中,锁会被多次的lock,所以自己也被阻塞了
- (void)viewDidLoad {
[super viewDidLoad];
[self testLock];
}
- (void)testLock {
_mutexLock = [[NSLock alloc] init];
dispatch_queue_t queue = dispatch_queue_create("com.test.a", DISPATCH_QUEUE_CONCURRENT);
static void(^TestBlock)(int);
//线程1
dispatch_async(queue, ^{
TestBlock = ^(int value)
{
[_mutexLock lock];
if (value > 0)
{
[NSThread sleepForTimeInterval:1];
int count = --value;
NSLog(@"count: %d", count);
TestBlock(count);
}
[_mutexLock unlock];
};
TestBlock(5);
});
}
以上将NSLock换成NSRecursiveLock,便可解决问题。
_mutexLock = [[NSRecursiveLock alloc] init];
NSRecursiveLock类定义的锁可以在同一线程多次lock,而不会造成死锁。
递归锁会跟踪它被多少次lock。每次成功的lock都必须平衡调用unlock操作。
只有所有的锁住和解锁操作都平衡的时候,锁才真正被释放给其他线程获得。
9. NSConditionLock 条件锁
NSCondition封装了一个互斥锁和条件变量。互斥锁保证线程安全,条件变量保证执行顺序。
条件锁,一个线程获得了锁,其它线程等待。
[xxxx lock];
表示 xxx 期待获得锁,如果没有其他线程获得锁(不需要判断内部的condition) 那它能执行此行以下代码,如果已经有其他线程获得锁(可能是条件锁,或者无条件锁),则等待,直至其他线程解锁
[xxx lockWhenCondition:A条件];
表示如果没有其他线程获得该锁,但是该锁内部的condition不等于A条件,它依然不能获得锁,仍然等待。如果内部的condition等于A条件,并且没有其他线程获得该锁,则进入代码区,同时设置它获得该锁,其他任何线程都将等待它代码的完成,直至它解锁。
[xxx unlockWithCondition:A条件];
表示释放锁,同时把内部的condition设置为A条件
- (void)viewDidLoad {
[super viewDidLoad];
[self testLock];
}
- (void)testLock {
dispatch_queue_t queue = dispatch_queue_create("com.test.a", DISPATCH_QUEUE_CONCURRENT);
//主线程中
NSConditionLock *theLock = [[NSConditionLock alloc] init];
//线程1
dispatch_async(queue, ^{
for (int i=0;i<=3;i++)
{
[theLock lock];
NSLog(@"thread1:%d",i);
sleep(1);
[theLock unlockWithCondition:i];
}
});
//线程2
dispatch_async(queue, ^{
[theLock lockWhenCondition:2];
NSLog(@"thread2");
[theLock unlock];
});
}
执行结果:
2019-03-09 20:54:59.762199+0800 test[4171:428554] thread1:0
2019-03-09 20:55:00.767031+0800 test[4171:428554] thread1:1
2019-03-09 20:55:01.770958+0800 test[4171:428554] thread1:2
2019-03-09 20:55:02.771687+0800 test[4171:428556] thread2
2019-03-09 20:55:02.772258+0800 test[4171:428554] thread1:3
在线程1中的加锁使用了lock,是不需要条件的,所以顺利的就锁住了。
unlockWithCondition:在开锁的同时设置了一个整型的条件 2 。
线程2则需要一把被标识为2的钥匙,所以当线程1循环到 i = 2 时,线程2的任务才执行。
NSConditionLock也跟其它的锁一样,是需要lock与unlock对应的,只是lock,lockWhenCondition:与unlock,unlockWithCondition:是可以随意组合的
10. @synchronized 关键字加锁 互斥锁,性能较差不推荐使用
@synchronized(这里添加一个OC对象,一般使用self) {
需要执行的代码
}
注意点
1. 加锁的代码尽量少
2. 添加的OC对象必须在多个线程中都是同一对象
3. 优点是不需要显式的创建锁对象,便可以实现锁的机制
4. @synchronized块会隐式的添加一个异常处理例程来保护代码,该处理例程会在异常抛出的时候自动的释放互斥锁。所以如果不想让隐式的异常处理例程带来额外的开销,你可以考虑使用锁对象
- (void)viewDidLoad {
[super viewDidLoad];
[self testLock];
}
- (void)testLock {
//设置票的数量为5
_tickets = 5;
dispatch_queue_t queue = dispatch_queue_create("com.test.a", DISPATCH_QUEUE_CONCURRENT);
//线程1
dispatch_async(queue, ^{
[self saleTickets];
});
//线程2
dispatch_async(queue, ^{
[self saleTickets];
});
}
- (void)saleTickets
{
while (1) {
@synchronized(self) {
[NSThread sleepForTimeInterval:1];
if (_tickets > 0) {
_tickets--;
NSLog(@"剩余票数= %ld, Thread:%@",_tickets,[NSThread currentThread]);
} else {
NSLog(@"票卖完了 Thread:%@",[NSThread currentThread]);
break;
}
}
}
}
查看结果:
2019-03-09 11:11:56.351768+0800 test[2452:200838] 剩余票数= 4, Thread:<NSThread: 0x60400046ea00>{number = 3, name = (null)}
2019-03-09 11:11:57.357842+0800 test[2452:200842] 剩余票数= 3, Thread:<NSThread: 0x60000007af40>{number = 4, name = (null)}
2019-03-09 11:11:58.362985+0800 test[2452:200838] 剩余票数= 2, Thread:<NSThread: 0x60400046ea00>{number = 3, name = (null)}
2019-03-09 11:11:59.368940+0800 test[2452:200842] 剩余票数= 1, Thread:<NSThread: 0x60000007af40>{number = 4, name = (null)}
2019-03-09 11:12:00.374592+0800 test[2452:200838] 剩余票数= 0, Thread:<NSThread: 0x60400046ea00>{number = 3, name = (null)}
2019-03-09 11:12:01.375835+0800 test[2452:200842] 票卖完了 Thread:<NSThread: 0x60000007af40>{number = 4, name = (null)}
2019-03-09 11:12:02.380906+0800 test[2452:200838] 票卖完了 Thread:<NSThread: 0x60400046ea00>{number = 3, name = (null)}
可以看到除了 OSSpinLock
外,dispatch_semaphore
和 pthread_mutex
性能是最高的。苹果在新系统中已经优化了 pthread_mutex
的性能,所以它看上去和 OSSpinLock
差距并没有那么大了。
可以看到YYKit组件中YYCache 和 YYImageCoder大量使用 dispatch_semaphore pthread_mutex
这两个锁
OSSpinLock
自旋锁(虽然已经被证明不安全 优先级翻转),性能最高的锁。原理很简单,就是一直 do while
忙等。它的缺点是当等待时会消耗大量 CPU 资源,所以它不适用于较长时间的任务。对于内存缓存的存取来说,它非常合适。
dispatch_semaphore
是信号量,但当信号总量设为 1 时也可以当作锁来。在没有等待情况出现时,它的性能比 pthread_mutex
还要高,但一旦有等待情况出现时,性能就会下降许多。相对于 OSSpinLock
来说,它的优势在于等待时不会消耗 CPU 资源。对磁盘缓存来说,它比较合适。
不存在等待的情况,例如不涉及到磁盘这种文件读写,dispatch_semaphore
性能很高,如果涉及到的任务等待时间较长,就需要用pthread_mutex
(OSSpinLock
不安全就可以先不用了)
网友评论