iOS 多线程
多线程方案
pthread C语言 程序员管理线程
NSThread OC 程序员管理
GCD 用来替代NSThread C语言 自动管理
NSOperation 基于GCD，面向对象 自动管理
iOS内多线程底层都是pthread
GCD
同步是在当前线程
并发队列容许多个任务同时执行
global 全局并发队列
1.同步 在当前线程执行 不具备开启线程的能力
2.异步
3.并发 多个任务可以同时执行
4.串行 一个接一个执行
手动串行队列异步执行 有开启新线程 但串行执行任务
主队列异步 不开辟新线程
并发队列异步 会开辟线程并发执行
使用sync函数往当前串行队列中添加任务会导致死锁
并发队列异步block不会死锁
Performselector
使用afterdelay时子线程不发生调用 是在runloop定义的 底层是定时器 需要开启runloop
performselector只是发送消息
GNUstep
GUN计划 开源计划 将Cocoa的OC库重新开源实现了一遍
使用thread 需要启动runloop 才能在线程执行 performseclector方法
group线程组 异步执行任务并 同步到主线程
多线程的安全隐患
1.资源共享
2.数据错乱和数据安全
3.买票的同步问题
线程同步技术 加锁
锁
OSSpinLock 自旋锁
自旋锁 等待锁的线程会处于忙等状态 一直占用着CPU资源
自旋锁会可能出现线程反转的问题 线程优先级发生反转
线程优先级低的获取锁后 会是优先级高的线程忙等 ，cpu可能会把大量时间给高的线程 从而导致死锁
解决方案 使用 OSSpinLockTry 进行尝试加锁
#import <libkern/OSAtomic.h>
OSSpinLock lock = OS_SPINLOCK_INIT;
OSSpinLockLock(&lock);
OSSpinLockUnlock(&lock);
lock必须定义为全局变量
一旦加锁 别的线程就没法获取 阻塞线程
对于读写操作 要使用同一把锁
static静态全局变量
static 调用函数的初始化 必须用哪个gcdonce 保证唯一
os_unfair_lock ios10之后代替自旋锁的锁
底层调用 等待的线程会休眠 不是忙等
#import <os/lock.h>
os_unfair_lock lock = OS_UNFAIR_LOCK_INIT;
os_unfair_lock_lock(&lock);
os_unfair_lock_unlock(&lock)
如果忘记解锁了 就会一直阻塞 称之为死锁 成对出现 lllock 低级锁
pthread_mutex
pthread开头的一般是跨平台的 互斥锁 等待锁的线程会处于休眠状态
// 初始化完成
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
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_lock(&mutex);
pthread_mutex_unlock(&mutex);
//销毁锁
pthread_mutex_destroy(&mutex)
PTHREAD_MUTEX_DEFAULT 嵌套调用会导致死锁
PTHREAD_MUTEX_RECURSIVE 递归锁 递归使用不会锁
递归锁 允许同一个线程对一把锁重复加锁
lldp si 一行一行代码执行 c 快速跳转
mutex条件
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
pthread_cond_wait(&cond, &mutex);
pthread_cond_signal(&cond );
pthread_cond_destroy(&cond);
信号 唤醒另一条线程执行任务 线程等待另一条线程做完事情去执行任务
NSLock NSRecursiveLock
NSLock是对mutex普通锁的封装
NSRecursiveLOck是对mutex递归锁的封装
always Show Disassembly 显示汇编
NSCondition
是对mutex和cond的封装
- (void)wait;
- (BOOL)waitUntilDate:(NSDate *)limit;
- (void)signal;
- (void)broadcast;
使用 signal时可以在放在 unlock之前或之后 区别在于在 unlock之前会等待 unlock之后才能执行
使用runloop实现常驻线程
NSConditionLock 条件锁
对NSCondition的封装 可以设置具体的条件值 int的条件值
如果条件值为 设定的值是才能加锁成功
可以实现线程依赖 通过加条件锁
使用lock时不管条件值 如果没有锁会直接加锁 不去判断条件值
dispatch_semaphore 信号量
semaphore初始值 用来控制线程最大并发访问量
通过NSThread创建线程 wait等待新华 signal发送信号
wait函数 每条线程进来如果信号量的值大于0 就让信号量的值减一 继续往下执行代码
当等到信号量的值大于0 马上让值减一
@synchronized 是对mutex递归锁的封装
从代码来说比较简洁
@synchronized ([self class]) {
}
使用self要确定 self是同一个对 使用()内的对象进行加锁 或者使用代理对象
@synchronized 底层是对mutex的封装 pthread_mutex_t
一个对象对应一把锁 从Datalist中取值 是一个map字典 通过对象找到值
支持递归加锁
同步方案
1.OSSpinLOck 自旋锁 线程反转
2.os_unfair_lock ios10以后
3.pthread_mutex_lock 普通和递归 条件
4.NSlock 对普通mutex的封装
5.NSRecursiveLock 对递归mutex的封装
6.NScondition 对 mutex和condition条件的封装
执行到一半的时候等待
7.NSconditionLock 条件锁 初始化和设置条件 依赖关系
8.dispatch_semaphore 信号量 同时允许5个线程执行任务 被阻塞的线程处于休眠
9.@synchronized 用同一对象加锁 是递归锁 性能最差 封装了hash表和C++的结构函数
不同线程的信号量封装成单例在函数里进行同步
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
semaphore = dispatch_semaphore_create(1);
});
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
// .......
dispatch_semaphore_signal(semaphore);
自旋锁和互斥锁的使用时机
自旋锁不推荐使用了 OSSpinLock
自旋锁使用的时机
1.预计线程等待锁的时间很短
2.加锁的代码经常被调用 但很少出现竞争
3.CPU资源不紧张
4.多核处理器
互斥锁的使用时机
1.预计线程等待锁的时间较长
2.单核处理器
3.临界区会有IO操作 会占用CPU资源
4.临界区代码复杂或者循环量大
5.临界区竞争非常激烈
atomic 原子性
1、会对属性的get和set方法进行加锁操作，都是原子性操作 保证线程同步
对get set 内部对象 进行加锁和解锁的操作
runtime的源码分析 如果是atomic 会有自旋锁加锁
原子操作是不可分割的 整体执行
2、并不能保证使用属性是安全的
3、消耗性能 不推荐使用
读写安全方案
IO操作 读取文件内容 往文件中写入内容
读取和写操作 保证同一时间write和read方法
多读单写方案优化 为了提高效率 实现多读单写
实现方案
1.同一时间 只能有一个线程进行写的操作
2.同一时期 允许有多个线程进行度的操作
3.统一时间 不允许既有写的操作，又有读的操作
解决方案
1.pthread_rwlock 读写锁 等待锁的线程会进入休眠
pthread_rwlock_t lock ;
pthread_rwlock_init(&lock, NULL);
pthread_rwlock_rdlock(&lock);
pthread_rwlock_unlock(&lock);
pthread_rwlock_destroy(&lock);
2.dispatch_barrier_async 栅栏函数的使用
使用异步队列进行读操作 使用栅栏barrier_async{} 函数执行同步操作
传入的并发队列必须是自己创建的队列
如果是全局并发队列或者串行队列 这个函数等同于dispatch_async{}
