你理解的多线程？
iOS的多线程方案有哪几种？你更倾向于哪一种？
你在项目中用过 GCD 吗？
GCD 的队列类型
说一下 OperationQueue 和 GCD 的区别，以及各自的优势
线程安全的处理手段有哪些？
OSSpinLock
os_unfair_lock
pthread_mutex
dispatch_semaphore
dispatch_queue(DISPATCH_QUEUE_SERIAL)
NSLock
NSRecursiveLock
NSCondition
NSConditionLock
@synchronized
OC你了解的锁有哪些？在你回答基础上进行二次提问
追问一：自旋和互斥对比？
追问二：使用以上锁需要注意哪些？
追问三：用C/OC/C++，任选其一，实现自旋或互斥？口述即可！
下面打印什么结果
image.png
打印结果是1 3
performSelectorWithObjectafterDelay的本质是往RunLoop中添加定时器 子线程默认没有启动RunLoop
下面打印什么结果
image.png
崩溃
iOS中常见多线程方案
多线程方案.png
GCD
同步和异步 主要影响 能不能开启新线程
- 同步 在当前线程中执行任务 不具备开启新线程的能力
- 异步 在新的线程中执行任务 具备开启新线程的能力
并发和串行 主要影响 任务的执行方式
- 并发 多个任务并发(同时)执行
- 串行 一个任务执行完毕后 再执行下一个任务
dispatch_sync 和 dispatch_async 用来控制是否要开启新的线程
队列的类型 决定了任务的执行方式(并发 串行)
各种队列的执行效果
执行效果.png
只要是sync 或者 主队列 就不会开启新线程
使用sync函数往当前串行队列中添加任务，会卡住当前的串行队列（产生死锁）
dispatch_sync 立马在当前线程执行任务 执行完毕才能继续往下执行
队列的特点 排队 先进先出
performSelectorWithObjectafterDelay
[self performSelector:@selector(test) withObject:nil afterDelay:.0];
这个代码本质是往RunLoop里面添加定时器
所以 放在子线程是没有效果的 (因为子线程没有RunLoop）
如果想在子线程中起作用 需要打开RunLoop
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
因为这个performSelectorWithObjectafterDelay 的实现里面 默认已经把timer加入到RunLoop中 所以 直接启动RunLoop即可
安全隐患
1.资源共享
- 一块资源可能会被多个线程共享 也就是多个线程可能会访问同一块资源
- 比如多个线程访问同一个对象、同一个变量、同一个文件
2.当多个线程访问同一块资源时，很容易引发数据错乱和数据安全问题
安全隐患的解决办法
解决方案：使用线程同步技术（同步，就是协同步调，按预定的先后次序进行）
常见的线程同步技术是：加锁
线程同步方案
OSSpinLock
os_unfair_lock
pthread_mutex
dispatch_semaphore
dispatch_queue(DISPATCH_QUEUE_SERIAL)
NSLock
NSRecursiveLock
NSCondition
NSConditionLock
@synchronized
OSSpinLock
OSSpinLock 自旋锁 等待锁的线程会处于忙等状态 一直占用CPU资源
#import <libkern/OSAtomic.h>
//初始化锁
OSSpinLock lock = OS_SPINLOCK_INIT;
//加锁
OSSpinLockLock(&lock);
//解锁
OSSpinLockUnlock(&lock);
调度线程 进程使用的是时间片轮转调度算法
OSSpinLock目前已经不再安全，可能会出现优先级反转问题(如果等待锁的线程优先级较高，它会一直占用着CPU资源，优先级低的线程就无法释放锁)
os_unfair_lock
os_unfair_lock 是取代不安全的OSSpinLock 从iOS10才开始
等待os_unfair_lock锁的线程会处于休眠状态，并非忙等
#import <os/lock.h>
//初始化锁
os_unfair_lock moneyLock = OS_UNFAIR_LOCK_INIT;
//加锁
os_unfair_lock_lock(&moneyLock);
//解锁
os_unfair_lock_unlock(&moneyLock);
pthread_mutex
pthread开头的 都是跨平台的
pthread_mutex 互斥锁 等待锁的线程会处于休眠状态
//初始化锁 静态初始化
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
//初始化锁的属性
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
//设置锁的类型
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL);
//初始化锁 动态初始化
pthread_mutex_init(&mutex, &attr);
//销毁属性
pthread_mutexattr_destroy(&attr);
//加锁
pthread_mutex_lock(&mutex);
//解锁
pthread_mutex_unlock(&mutex);
//销毁锁
pthread_mutex_destroy(&mutex);
pthread_mutex 可以实现递归锁 允许对同一个线程重复加锁 可以实现线程安全
pthread_mutex锁的类型
image.png
当线程1必须等待线程2完成之后 才能执行 就可以加入pthread_mutex锁条件 让线程1先休眠
//条件
pthread_cond_t cond;
//初始化条件
pthread_cond_init(&cond, NULL);
//销毁条件
pthread_cond_destroy(&cond);
//等待 会放开锁 被唤醒后 会再次加锁
pthread_cond_wait(&cond, &mutex);
//发送信号 唤醒
pthread_cond_signal(&cond);
//激活所有等待该条件的线程
pthread_cond_broadcast(&cond);
NSLock、NSRecursiveLock
NSLock是对mutex普通锁的封装
- (BOOL)tryLock;
尝试加锁 一调用这个方法 就查看是否能加锁 如果能加 就返回YES 代码继续执行
如果不能加锁 就不加 返回NO 代码继续执行 (无论能否加锁 都不会阻塞)
- (BOOL)lockBeforeDate:(NSDate *)limit
传入时间 在这个时间之前 如果能够等到锁 那么就给这个锁加锁(如果时间没到 那么就一直在这里等 阻塞 休眠) 就返回YES
如果等不到锁 就加锁失败 返回NO 这个代码也会往下走
NSLock *ticketLock = [[NSLock alloc] init];
//加锁
[ticketLock lock];
//解锁
[ticketLock unlock];
NSRecursiveLock是对mutex递归锁的封装
NSCondition
NSCondition是对mutex 和 cond的封装
NSCondition *condition = [[NSCondition alloc] init];
[condition lock];
[condition unlock];
//等待
[condition wait];
//发送信息
[condition signal];
//唤醒所有等待改条件的线程
[condition broadcast];
NSConditionLock
NSConditionLock是对NSCondition的封装 可以设置具体的条件值
NSConditionLock *conditionLock = [[NSConditionLock alloc] initWithCondition:1];
[conditionLock lock];
[conditionLock unlock];
//当锁内部的值是1的时候 进行加锁 否则 一直等待值为1
[conditionLock lockWhenCondition:1];
//设置锁内部的条件值是2 并且打开锁
[conditionLock unlockWithCondition:2];
NSConditionLock 可以设置线程之间的依赖
NSCondition 是可以1个线程执行一半 执行其他的线程 再回来执行原先的线程
dispatch_queue
直接使用GCD的串行队列，也是可以实现线程同步的
dispatch_queue_t ticketQueue = dispatch_queue_create("ticketQueue", DISPATCH_QUEUE_SERIAL);
dispatch_sync(ticketQueue, ^{
//任务
});
dispatch_sync(ticketQueue, ^{
//任务
});
dispatch_semaphore
dispatch_semaphore 信号量
信号量的初始值 可以用来控制线程并发访问的最大数量
//创建信号量 最大并发数5
dispatch_semaphore_t semaphore = dispatch_semaphore_create(5);
//如果信号量的值大于0 就让信号量的值减1 然后 继续往下执行代码
//如何信号量的值是小于等于0 就会休眠等待 直到信号量的值大于0 就让信号量的值减1 然后 继续往下执行代码
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
//让信号量的值加1
dispatch_semaphore_signal(semaphore);
@synchronized
@synchronized 是对mutex递归锁的封装
//self对象作为一把锁
@synchronized(self) {
//任务
}
@synchronized(obj)内部会生成obj对应的递归锁，然后进行加锁、解锁操作
@synchronized 使用了哈希表 obj作为key 找到底层的那个锁 进行加锁 解锁
线程同步方案性能比较
性能从高到低排序
os_unfair_lock
OSSpinLock
dispatch_semaphore
pthread_mutex
dispatch_queue(DISPATCH_QUEUE_SERIAL)
NSLock
NSCondition
pthread_mutex(recursive)
NSRecursiveLock
NSConditionLock
@synchronized
自旋锁 互斥锁的比较
什么情况使用自旋锁比较划算
- 预计线程等待锁的时间很短
- 加锁的代码(临界区) 经常被调用 但竞争情况很少发生
- CPU资源不紧张
- 多核处理器
什么情况使用互斥锁比较划算
- 预计线程等待锁的时间较长
- 单核处理器
- 临界区有IO操作(IO操作比较暂居资源)
- 临界区代码复杂活循环量大
- 临界区竞争非常激烈
atomic
给属性加上atomic 可以保证属性的setter和getter都是原子性操作 也就是setter和getter内部加了线程同步锁
它并不能保证使用属性的过程是线程安全的
iOS中的读写安全方案
多读单写
pthread_rwlock：读写锁
dispatch_barrier_async：异步栅栏调用
pthread_rwlock
等待锁的线程会进入休眠
pthread_rwlock_t rwlock;
//const pthread_rwlockattr_t *restrict _Nullable 属性
pthread_rwlock_init(&rwlock, NULL);
//读 加锁
pthread_rwlock_rdlock(&rwlock);
//写 加锁
pthread_rwlock_wrlock(&rwlock);
//解锁
pthread_rwlock_unlock(&rwlock);
//销毁
pthread_rwlock_destroy(&rwlock);
dispatch_barrier_async
dispatch_barrier_async.png
当执行到dispatch_barrier_async 里面的任务的时候 跟其他的任务是隔离开的
传入的并发队列必须是自己通过dispatch_queue_cretate创建的 如果传入的全局并发队列或者串行队列 那这个函数便等同于dispatch_async函数的效果
