iOS中的常见多线程方案
image.png
GCD的常用函数
GCD中有2个用来执行任务的函数
-
用同步的方式执行任务
dispatch_sync(dispatch_queue_t queue, dispatch_block_t block);
queue：队列
block：任务 -
用异步的方式执行任务
dispatch_async(dispatch_queue_t queue, dispatch_block_t block);
GCD的队列
GCD的队列可以分为2大类型
-
==并发==队列（Concurrent Dispatch Queue）
可以让多个任务并发（同时）执行（自动开启多个线程同时执行任务）
并发功能只有在异步（dispatch_async）函数下才有效 -
==串行==队列（Serial Dispatch Queue）
让任务一个接着一个地执行（一个任务执行完毕后，再执行下一个任务）
容易混淆的术语
有4个术语比较容易混淆：==同步、异步、并发、串行==
同步和异步主要影响：能不能开启新的线程
- 同步：在当前线程中执行任务，不具备开启新线程的能力
- 异步：在新的线程中（主线程除外）执行任务，具备开启新线程的能力
并发和串行主要影响：任务的执行方式
- 并发：多个任务并发（同时）执行
- 串行：一个任务执行完毕后，再执行下一个任务
各种队列的执行效果
image.png
==使用sync函数往当前串行队列中添加任务，会卡住当前的串行队列（产生死锁）==
// 问题：以下代码是在主线程执行的，会不会产生死锁？会！
NSLog(@"执行任务1");
dispatch_queue_t queue = dispatch_get_main_queue();
dispatch_sync(queue, ^{
NSLog(@"执行任务2");
});
NSLog(@"执行任务3");
// dispatch_sync立马在当前线程同步执行任务
// 问题：以下代码是在主线程执行的，会不会产生死锁？会！
NSLog(@"执行任务1");
dispatch_queue_t queue = dispatch_queue_create("myqueu", DISPATCH_QUEUE_SERIAL);
dispatch_async(queue, ^{ // 0
NSLog(@"执行任务2");
dispatch_sync(queue, ^{ // 1
NSLog(@"执行任务3");
});
NSLog(@"执行任务4");
});
NSLog(@"执行任务5");
队列组的使用
思考：如何用gcd实现以下功能
异步并发执行任务1、任务2
等任务1、任务2都执行完毕后，再回到主线程执行任务3
// 创建队列组
dispatch_group_t group = dispatch_group_create();
// 创建并发队列
dispatch_queue_t queue = dispatch_queue_create("my_queue", DISPATCH_QUEUE_CONCURRENT);
// 添加异步任务
dispatch_group_async(group, queue, ^{
for (int i = 0; i < 5; i++) {
NSLog(@"任务1-%@", [NSThread currentThread]);
}
});
dispatch_group_async(group, queue, ^{
for (int i = 0; i < 5; i++) {
NSLog(@"任务2-%@", [NSThread currentThread]);
}
});
// 等前面的任务执行完毕后，会自动执行这个任务
dispatch_group_notify(group, queue, ^{
for (int i = 0; i < 5; i++) {
NSLog(@"任务3-%@", [NSThread currentThread]);
}
});
多线程的安全隐患
资源共享
1块资源可能会被多个线程共享，也就是==多个线程可能会访问同一块资源==
比如多个线程访问同一个对象、同一个变量、同一个文件，当多个线程访问同一块资源时，很容易引发==数据错乱和数据安全==问题
多线程安全隐患示例 – 存钱取钱
存钱取钱
多线程安全隐患示例 – 卖票
卖票
多线程安全隐患分析
多线程安全隐患的解决方案
- 解决方案：使用线程同步技术（同步，就是协同步调，按预定的先后次序进行）
- 常见的线程同步技术是：加锁
GNUstep
GNUstep是GNU计划的项目之一，它将Cocoa的OC库重新开源实现了一遍
虽然GNUstep不是苹果官方源码，但还是具有一定的参考价值
iOS中的线程同步方案
- OSSpinLock
- os_unfair_lock
- pthread_mutex
- dispatch_semaphore
- dispatch_queue(DISPATCH_QUEUE_SERIAL)
- NSLock
- NSRecursiveLock
- NSCondition
- NSConditionLock
- @synchronized
OSSpinLock
OSSpinLock叫做”自旋锁”，等待锁的线程会处于忙等（busy-wait）状态，一直占用着CPU资源
目前已经不再安全，可能会出现优先级反转问题
如果等待锁的线程优先级较高，它会一直占用着CPU资源，优先级低的线程就无法释放锁
需要导入头文件#import <libkern/OSAtomic.h>
// 初始化锁
OSSpinLock lock = OS_SPINLOCK_INIT;
//尝试加锁（如果需要等待就不加锁，直接返回false；如果不需要等待就加锁，返回true）
OSSpinLockTry(&lock)
// 加锁
OSSpinLockLock(&lock);
// 解锁
OSSpinLockUnlock(&lock);
os_unfair_lock
os_unfair_lock用于取代不安全的OSSpinLock ，从iOS10开始才支持
从底层调用看，等待os_unfair_lock锁的线程会处于休眠状态，并非忙等
需要导入头文件#import <os/lock.h>
-** Low-level lock的特点等不到锁就休眠
//初始化
os_unfair_lock moneyLock = OS_UNFAIR_LOCK_INIT;
//尝试加锁
os_unfair_lock_trylock(&moneyLock);
//加锁
os_unfair_lock_lock(&moneyLock);
//具体操作
//解锁
os_unfair_lock_unlock(&moneyLock);
pthread_mutex
mutex叫做==”互斥锁”==，等待锁的线程会处于休眠状态
需要导入头文件#import <pthread.h>
pthread_mutex_t moneyMutex;
// 初始化属性
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_DEFAULT);
// 初始化锁
pthread_mutex_init(mutex, &attr);
// 销毁属性
pthread_mutexattr_destroy(&attr);
//尝试加锁
pthread_mutex_trylock(&moneyMutex);
//加锁
pthread_mutex_lock(&moneyMutex);
//具体操作
//解锁
pthread_mutex_unlock(&moneyMutex);
//销毁锁
pthread_mutex_destroy(&moneyMutex);
Mutex type attributes
#define PTHREAD_MUTEX_NORMAL 0
#define PTHREAD_MUTEX_ERRORCHECK 1
#define PTHREAD_MUTEX_RECURSIVE 2
#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_NORMAL
- pthread_mutex – 递归锁
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
- pthread_mutex – 条件
pthread_cond_t cond;
// 初始化条件
pthread_cond_init(&_cond, NULL);
if (条件) {
// 等待条件（进入休眠，放开mutex锁；呗唤醒后，会再次对mutex加锁）
pthread_cond_wait(&_cond, &_mutex);
}
// 信号（激活一个等待条件的线程）
pthread_cond_signal(&_cond);
// 广播（激活所有等待条件的线程）
//pthread_cond_broadcast(&_cond);
pthread_mutex_unlock(&_mutex);
NSLock、NSRecursiveLock
NSLock是对mutex普通锁的封装
NSRecursiveLock也是对mutex递归锁的封装，API跟NSLock基本一致
@protocol NSLocking
- (void)lock;
- (void)unlock;
@end
@interface NSLock : NSObject <NSLocking> {
- (BOOL)tryLock;
- (BOOL)lockBeforeDate:(NSDate *)limit;
@property (nullable, copy) NSString *name API_AVAILABLE(macos(10.5), ios(2.0), watchos(2.0), tvos(9.0));
@end
NSCondition
==NSCondition==是对==mutex==和==cond==的封装
@interface NSCondition : NSObject <NSLocking> {
- (void)wait;
- (BOOL)waitUntilDate:(NSDate *)limit;
- (void)signal;
- (void)broadcast;
@property (nullable, copy) NSString *name API_AVAILABLE(macos(10.5), ios(2.0), watchos(2.0), tvos(9.0));
@end
NSConditionLock
NSConditionLock是对NSCondition的进一步封装，可以设置具体的条件值
@interface NSConditionLock : NSObject <NSLocking> {
- (instancetype)initWithCondition:(NSInteger)condition NS_DESIGNATED_INITIALIZER;
@property (readonly) NSInteger condition;
- (void)lockWhenCondition:(NSInteger)condition;
- (BOOL)tryLock;
- (BOOL)tryLockWhenCondition:(NSInteger)condition;
- (void)unlockWithCondition:(NSInteger)condition;
- (BOOL)lockBeforeDate:(NSDate *)limit;
- (BOOL)lockWhenCondition:(NSInteger)condition beforeDate:(NSDate *)limit;
@property (nullable, copy) NSString *name API_AVAILABLE(macos(10.5), ios(2.0), watchos(2.0), tvos(9.0));
@end
dispatch_semaphore
==semaphore==叫做”信号量”
信号量的初始值，可以用来控制线程并发访问的最大数量
信号量的初始值为1，代表同时只允许1条线程访问资源，保证线程同步
//初始化信号量
dispatch_semaphore_t semaphore = dispatch_semaphore_create(1);
// 如果信号量的值 > 0，就让信号量的值减1，然后继续往下执行代码
// 如果信号量的值 <= 0，就会休眠等待，直到信号量的值变成>0，就让信号量的值减1，然后继续往下执行代码
dispatch_semaphore_wait(self.semaphore, DISPATCH_TIME_FOREVER);
// 让信号量的值+1
dispatch_semaphore_signal(self.semaphore);
Semaphore宏定义
#define SemaphoreBegin \
static dispatch_semaphore_t semaphore; \
static dispatch_once_t onceToken; \
dispatch_once(&onceToken, ^{ \
semaphore = dispatch_semaphore_create(1); \
}); \
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
#define SemaphoreEnd \
dispatch_semaphore_signal(semaphore);
使用方式
SemaphoreBegin;
// 操作
SemaphoreEnd;
dispatch_queue
直接使用GCD的串行队列，也是可以实现线程同步的
dispatch_queue_t moneyQueue;
self.moneyQueue = dispatch_queue_create("moneyQueue", DISPATCH_QUEUE_SERIAL);
dispatch_sync(moneyQueue, ^{
//任务
});
@synchronized
==@synchronized==是对==mutex==递归锁的封装
源码查看：objc4中的objc-sync.mm文件
@synchronized(obj)内部会生成obj对应的递归锁，然后进行加锁、解锁操作
static NSObject *lock;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
lock = [[NSObject alloc] init];
});
@synchronized(lock) {
[super __saleTicket];
}
iOS线程同步方案性能比较
性能从高到低排序
- os_unfair_lock（iOS10以后）
- OSSpinLock（废弃，存在问题）
- dispatch_semaphore
- pthread_mutex
- dispatch_queue(DISPATCH_QUEUE_SERIAL)
- NSLock
- NSCondition
- pthread_mutex(recursive)
- NSRecursiveLock
- NSConditionLock
- @synchronized
自旋锁、互斥锁比较
- 什么情况使用自旋锁比较划算？
- 预计线程等待锁的时间很短
- 加锁的代码（临界区）经常被调用，但竞争情况很少发生
- CPU资源不紧张
- 多核处理器
- 什么情况使用互斥锁比较划算？
- 预计线程等待锁的时间较长
- 单核处理器
- 临界区有IO操作
- 临界区代码复杂或者循环量大
- 临界区竞争非常激烈
atomic
atomic用于保证属性setter、getter的原子性操作，相当于在getter和setter内部加了线程同步的锁
可以参考源码objc4的objc-accessors.mm
它并不能保证使用属性的过程是线程安全的
iOS中的读写安全方案
- 思考如何实现以下场景
- 同一时间，只能有1个线程进行写的操作
- 同一时间，允许有多个线程进行读的操作
- 同一时间，不允许既有写的操作，又有读的操作
- 上面的场景就是典型的“多读单写”，经常用于文件等数据的读写操作，iOS中的实现方案有
- pthread_rwlock：读写锁
- dispatch_barrier_async：异步栅栏调用
pthread_rwlock
等待锁的线程会进入休眠
@property (assign, nonatomic) pthread_rwlock_t lock;
- (void)rwlockTest {
// 初始化锁
pthread_rwlock_init(&_lock, NULL);
dispatch_queue_t queue = dispatch_get_global_queue(0, 0);
for (int i = 0; i < 10; i++) {
dispatch_async(queue, ^{
[self read];
});
dispatch_async(queue, ^{
[self write];
});
}
}
- (void)read {
pthread_rwlock_rdlock(&_lock);
//读任务
pthread_rwlock_unlock(&_lock);
}
- (void)write
{
pthread_rwlock_wrlock(&_lock);
//写任务
pthread_rwlock_unlock(&_lock);
}
- (void)dealloc
{
pthread_rwlock_destroy(&_lock);
}
dispatch_barrier_async
- 这个函数传入的并发队列必须是自己通过dispatch_queue_cretate创建的
- 如果传入的是一个串行或是一个全局的并发队列，那这个函数便等同于dispatch_async函数的效果
self.queue = dispatch_queue_create("rw_queue", DISPATCH_QUEUE_CONCURRENT);
for (int i = 0; i < 10; i++) {
dispatch_async(self.queue, ^{
[self read];//读操作
});
dispatch_barrier_async(self.queue, ^{
[self write];//写操作
});
}
- 队列的特点：排队、FIFO
dispatch_sync:立刻在当前线程执行任务，执行完毕才能继续往下执行
si指令
s->单步 step一行oc代码
i->instruction一行汇编代码
next -> 区别是会跳过函数
c -> continue 过掉当前断点
通过汇编代码的调试可以看出
-
jne j->jump
自旋锁（while循环）
自旋锁属于高级锁：不睡觉 -
syscall -> 系统函数，睡觉去了
强引用thread无法解决线程的后续任务无法调用的问题，使用runloop是为了让线程保持激活状态
线程同步的本质是：多条线程不同时占用同一份资源，也就是只要按顺序访问就不会有问题。
信号量：控制最大并发数
synchronize是一个递归锁，是对pthreadmutex的封装
如何证明是递归锁（如果可以递归调用，说明是递归锁）
lock和unlock之间的代码叫临界区
atomic
id objc_getProperty(id self, SEL _cmd, ptrdiff_t offset, BOOL atomic) {
if (offset == 0) {
return object_getClass(self);
}
// Retain release world
id *slot = (id*) ((char*)self + offset);
if (!atomic) return *slot;
// Atomic retain release world
spinlock_t& slotlock = PropertyLocks[slot];
slotlock.lock();
id value = objc_retain(*slot);
slotlock.unlock();
// for performance, we (safely) issue the autorelease OUTSIDE of the spinlock.
return objc_autoreleaseReturnValue(value);
}
读写安全：多读单写
读不会破坏以前的数据。
结果之所以出现问题，就是因为包含了写(改)操作
网友评论