0
点赞
收藏
分享

微信扫一扫

—— 多线程/锁 详解

奋斗De奶爸 2021-09-29 阅读 100
日记本

1. 名词解释

原子操作:同一时间只允许一个线程访问
代码临界区:指的是一块对公共资源进行访问的代码,并非一种机制或是算法。

2. 多线程

iOS 多线程之 NSThread
https://www.jianshu.com/p/64d4c2b59b88

iOS 多线程之 GCD
https://www.jianshu.com/p/f8f1836eb866

iOS 多线程之 NSOperation
https://www.jianshu.com/p/95dc1375fe0d

3. iOS多线程安全 — 锁

https://www.jianshu.com/p/d3b2a2526d40
https://blog.ibireme.com/2016/01/16/spinlock_is_unsafe_in_ios/#more-41952

以上是不同锁从耗时角度的排序,下面我们评估一下各种锁的性能,以验证上述排序。示例代码如下:

double curTime, lastTime;
const NSInteger KRunTimes = 1000 * 1000;

//// 1. OSSpinLock 自旋锁;
OSSpinLock spinlock = OS_SPINLOCK_INIT;
lastTime = CFAbsoluteTimeGetCurrent();
for (NSInteger i = 0; i < KRunTimes; ++i) {
OSSpinLockLock(
OSSpinLockUnlock(
}
curTime = CFAbsoluteTimeGetCurrent();
NSLog(@"OSSpinlock: %f ms", (curTime - lastTime) * 1000);

//// 2. pthread_mutex_t
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
lastTime = CFAbsoluteTimeGetCurrent();
for (NSInteger i = 0; i < KRunTimes; ++i) {
pthread_mutex_lock(
pthread_mutex_unlock(
}
curTime = CFAbsoluteTimeGetCurrent();
NSLog(@"pthread_mutex: %f ms", (curTime - lastTime) * 1000);
pthread_mutex_destroy(

//// 3. NSRecursiveLock
NSRecursiveLock *recursiveLock = [[NSRecursiveLock alloc] init];
lastTime = CFAbsoluteTimeGetCurrent();
for (NSInteger i = 0; i < KRunTimes; ++i) {
[recursiveLock lock];
[recursiveLock unlock];
}
curTime = CFAbsoluteTimeGetCurrent();
NSLog(@"NSRecursiveLock: %f ms", (curTime - lastTime) * 1000);

//// 4. NSLock
NSLock *myLock = [NSLock new];
lastTime = CFAbsoluteTimeGetCurrent();
for (NSInteger i = 0; i < KRunTimes; ++i) {
[myLock lock];
[myLock unlock];
}
curTime = CFAbsoluteTimeGetCurrent();
NSLog(@"NSLock: %f ms", (curTime - lastTime) * 1000);

// NSLock IMP
typedef void (*func)(id, SEL);
SEL lockSEL = @selector(lock);
SEL unlockSEL = @selector(unlock);
func lockFunc = (void (*)(id, SEL))[myLock methodForSelector : lockSEL];
func unlockFunc = (void (*)(id, SEL))[myLock methodForSelector : unlockSEL];

lastTime = CFAbsoluteTimeGetCurrent();
for (NSInteger i = 0; i < KRunTimes; ++i) {
lockFunc(myLock, lockSEL);
unlockFunc(myLock, unlockSEL);
}
curTime = CFAbsoluteTimeGetCurrent();
NSLog(@"NSLock + IMP: %f ms", (curTime - lastTime) * 1000);

//// 5. NSCondition
NSCondition *condition = [[NSCondition alloc] init];
lastTime = CFAbsoluteTimeGetCurrent();
for (NSInteger i = 0; i < KRunTimes; ++i) {
[condition lock];
[condition unlock];
}
curTime = CFAbsoluteTimeGetCurrent();
NSLog(@"NSCondition: %f ms", (curTime - lastTime) * 1000);

//// 6. NSConditionLock
NSConditionLock *conditionLock = [[NSConditionLock alloc] init];
lastTime = CFAbsoluteTimeGetCurrent();
for (NSInteger i = 0; i < KRunTimes; ++i) {
[conditionLock lock];
[conditionLock unlock];
}
curTime = CFAbsoluteTimeGetCurrent();
NSLog(@"NSConditionLock: %f ms", (curTime - lastTime) * 1000);

//// 7. 同步synchronized
id obj = [NSObject new];

lastTime = CFAbsoluteTimeGetCurrent();
for (NSInteger i = 0; i < KRunTimes; ++i) {
@synchronized(obj) {
}
}
curTime = CFAbsoluteTimeGetCurrent();
NSLog(@"@synchronized: %f ms", (curTime - lastTime) * 1000);

//// 8. dispatch_barrier_async
dispatch_queue_t queue =
dispatch_queue_create("com.qq.ksnow", DISPATCH_QUEUE_CONCURRENT);

lastTime = CFAbsoluteTimeGetCurrent();
for (NSInteger i = 0; i < KRunTimes; ++i) {
dispatch_barrier_async(queue, ^{});
}
curTime = CFAbsoluteTimeGetCurrent();
NSLog(@"@dispatch_barrier_async: %f ms", (curTime - lastTime) * 1000);


//// 模拟器/iOS7/XCode6下性能对比
OSSpinlock: 10.430992 ms
pthread_mutex: 62.326968 ms
NSRecursiveLock: 89.230001 ms
NSLock: 100.879967 ms
NSLock + IMP: 89.570999 ms
NSCondition: 89.850008 ms
NSConditionLock: 233.431995 ms
@synchronized: 232.551038 ms
dispatch_barrier_async: 1234.429002 ms

//// iPad Mini2/iOS7/XCode6下性能对比
OSSpinlock: 63.916981 ms
pthread_mutex: 170.615971 ms
NSRecursiveLock: 229.423046 ms
NSLock: 227.194011 ms
NSLock + IMP: 221.384048 ms
NSCondition: 221.689999 ms
NSConditionLock: 636.340976 ms
@synchronized: 499.736011 ms
dispatch_barrier_async: 329.769015 ms

4. 总结

为什么不直接使用 IMP 而使用直接声明函数指针的方式? XCode6下IMP不能指定参数,报错如下

5. 原因分析

  • 自旋锁(Spin)
    多个线程论询锁变量是否可用,由于线程在论询程中保持执行状态,一旦获取锁,线程会一直保持该锁,直至显式释放自旋锁。 自旋锁避免了进程上下文的调度开销,是比较高效的。

  • 互斥锁(Mutex)
    是防止多线程同时对同一公共资源(比如全局变量)进行读写的一种锁,同一时间段只允许一个线程访问。当线程来到临界区,获取不到锁,就会去睡眠主动让出时间片,让出时间片会导致操作系统切换到另一个线程。线程会从sleep(加锁)—>running(解锁)过程中有上下文的切换(cpu的抢占,信号的发送)等开销。

  • 读写锁(rwlock)
    也称“共享-互斥锁”、多读-单写锁) 用于解决多线程对公共资源读写问题。
    读操作可并发重入,写操作是互斥的。 读写锁通常用互斥锁、条件变量、信号量实现。

  • 信号量(Semaphore)
    是一种更高级的同步机制,互斥锁可以说是Semaphore在仅取值0/1时的特例。信号量可以有更多的取值空间,用来实现更加复杂的同步,而不单单是线程间互斥。

  • 条件锁(Condition)
    就是条件变量,当进程的某些资源要求不满足时就进入休眠,也就是锁住了。当资源被分配到了,条件锁打开,进程继续运行。

  • 递归锁(Recursive)
    递归锁有一个特点,就是同一个线程可以加锁N次而不会引发死锁。

https://www.jianshu.com/p/8b8a01dd6356

这两天翻看 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(
sleep(4);
NSLog(@"线程1");
OSSpinLockUnlock(
NSLog(@"线程1 解锁成功");
NSLog(@"--------------------------------------------------------");
});

//线程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"线程2 准备上锁");
OSSpinLockLock(
NSLog(@"线程2");
OSSpinLockUnlock(
NSLog(@"线程2 解锁成功");
});

运行结果:

我们来修改一下代码:

__block OSSpinLock oslock = OS_SPINLOCK_INIT;
//线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
......
//OSSpinLockUnlock(
......

运行结果:

OSSpinLock1 图中可以发现:当我们锁住线程1时,在同时锁住线程2的情况下,线程2会一直等待(自旋锁不会让等待的进入睡眠状态),直到线程1的任务执行完且解锁完毕,线程2会立即执行;而在 OSSpinLock2 图中,因为我们注释掉了线程1中的解锁代码,会绕过线程1,直到调用了线程2的解锁方法才会继续执行线程1中的任务,正常情况下,lockunlock最好成对出现

这里顺便提一下trylocklock使用场景:

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 发送信号");
});

关于信号量,我们可以用停车来比喻:

运行结果:

可以发现,因为我们初始化信号量的时候是大于 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(
sleep(3);
NSLog(@"线程1");
pthread_mutex_unlock(
});

//1.线程2
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
NSLog(@"线程2 准备上锁");
pthread_mutex_lock(
NSLog(@"线程2");
pthread_mutex_unlock(
});

运行结果:

这里贴个 YYKit 中的源码:

pthread_mutex(recursive)


经过上面几种例子,我们可以发现:加锁后只能有一个线程访问该对象,后面的线程需要排队,并且 lock 和 unlock 是对应出现的,同一线程多次 lock 是不允许的,而递归锁允许同一个线程在未释放其拥有的锁时反复对该锁进行加锁操作。

例子:

static pthread_mutex_t pLock;
pthread_mutexattr_t attr;
pthread_mutexattr_init( //初始化attr并且给它赋予默认
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE); //设置锁类型,这边是设置为递归锁
pthread_mutex_init(&pLock,
pthread_mutexattr_destroy( //销毁一个属性对象,在重新进行初始化之前该结构不能重新使用

//1.线程1
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
static void (^RecursiveBlock)(int);
RecursiveBlock = ^(int value) {
pthread_mutex_lock(
if (value > 0) {
NSLog(@"value: %d", value);
RecursiveBlock(value - 1);
}
pthread_mutex_unlock(
};
RecursiveBlock(5);
});

运行结果:

NSLock


NSLock API 很少也很简单:

例子:

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:

看字面意思很好理解:

例子:

  • 等待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");
}
});

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:时,这时候会把condition0 修改为 1
  • 因为condition 修改为了 1, 会先走到 线程3,然后 线程3 又将 condition 修改为 3
  • 最后 走了 线程2 的流程

参考文献:

NSRecursiveLock递归锁的使用
关于dispatch_semaphore的使用
实现锁的多种方式和锁的高级用法

举报

相关推荐

0 条评论