注册
iOS

Swift 多线程上

提到多线程,无非就是关注二点,一是线程安全问题,二是在合适的地方合适的使用多线程(这个就有点广泛了,但是很重要不能为了去使用而使用)。




先看下OC中定义属性的关键字atomic/nonatomic,原子属性和非原子属性(此处先不谈内存相关的知识),有啥区别呢?property申明的属性会默认实现setter和get方法,而atomic默认会给setter方法加锁。也就是atomic线程安全,防止数据在被不同线程读写时发生了错误,设置属性时默认就是nonatomic。万能的苹果开发大神为啥不都设置为线程安全呢,主要是因为atomic很耗内存资源,相比这点安全远不能弥补在内存资源和运行速度上的缺陷,所以需要我们在开发时,适当的时候加锁。


说到加锁(我自己了解的也不是很多),只能说说最基本的。先看我们在OC中创建单利时,用到的关键字synchronized('加锁对象'){'加锁代码'},互斥锁,简单粗暴,不需要释放啥的,在不考虑效率下还是很方便(创建个单利能耗啥效率了,如果在swift中使用那么就是objc_sync_enter('加锁对象')和objc_sync_exit('加锁对象'))。还有就是NSLock,这个或许偶尔会用到,对象锁,lock和unlock需要成对出现,不能频繁调用lock不然可能会出现线程锁死

let lock = NSLock
lock.lock()
defer {
lock.unlock()
}

只是简单说下锁(至于NSRecursiveLock,NSConditionLock等各种锁的我也不是很熟,应该说是没有用过),如果多线程出现问(愿你写的多线程永远不出现线程安全问题,但是需要谨记一句:线程复杂必死),至少知道有解决的方法,在使用多线程稍微注意下。关于线程锁和线程发生锁死,我也只是略懂,以后再总结。除了加锁还可以用其他方法避免线程问题,比如:串行队列(FMDB线程安全就是这种方式),合适的使用信号量DispatchSemaphore。


我自己也是在开发中遇到二次线程安全问题,一次在使用CoreData,还有一次就是在多线程上传图片的时候,都是泪。CoreData,最后我是使用了串行队列解决线程安全问题,CoreData是有安全队列方法的,但是呢那个是接手的项目,别人写好了,我就在原来的基础上修改的。多线程上传图片出现问题,完全是自己不够细心导致的,过了好久才意识到的问题,先说下,OC中的系统对象基本都是线程不安全的,都是操作指针,swift中的系统对象基本都是线程安全的,都是直接读取内存。即使对象是线程安全的,但是也不能在不同的线程操作同一个对象,应该先copy在再操作,就是直接用=(OC是不行的)。




说了一大堆线程相关的废话,那再看看怎样在Swift 中使用多线程,其实最常用的也就是GCD和Operation,如果说对线程安全,GCD,Operation,队列和线程关系不了解,那就去网上找资料补一补。


最常用的API,主线程延迟执行: DispatchQueue.main.asyncAfter(deadline: DispatchTime) {}

获取主线程(一个应用就一个主程):

DispatchQueue.main.async {}


再就是GCD创建队列了,分为串型队列和并发队列(串型队列只会开一个子线程,并发队列会创建多个子线程)


/// 并发队列
let queue = DispatchQueue.global(qos: DispatchQoS.QoSClass.background)
/// 串行队列
let queue = DispatchQueue(label: "test.queue")

接着就是异步/同步(是否阻塞当前线程的区别,注意下线程相互锁死问题)执行任务的API了,任务放到队列里面去,由队列决定是否开辟新的线程执行任务,强调一点,任何UI相关的任务不能放到子线程中执行,子线程是不能刷新UI的,如果你看到你的子线程刷新了UI那是你的眼晴欺骗了你,原因是UIKit框架不是线程安全,可能会出现资源争夺,所以只能在主线程中绘制。只是简单的介绍下比较常用的API,相对于OC的写法已经简单很多了。具体的区别和参数可以参考官方的文档,貌似还很复杂。

接下来就可以愉快的异步线程执行耗时任务了,执行完再回到主线程中,该干嘛就干嘛了,简单粗暴。但是还是有问题需要我们去注意:



  • 任务全部执行完成的回调
  • 怎样控制执行的先后顺序(不考虑串行)
  • 怎样控制并发的数量
  • 怎样暂停/挂起任务

很明显,有些问题GCD可能不太容易解决。


Operation 和OperationQueue,基于GCD封装的对象,支持KVO,处理多线程的API更方便,如果你看过其他第三方框架,可以经常看到这些对象,GCD反而用的比较少。最开始出来找工作时,其实我很不喜欢别人在没有给应用场景时问我什么时候使用GCD,什么时候使用OperationQueue有种被套路的感觉(在合适的地方合理的去使用合理的多线程),就现在而言,如果简单不复杂首选GCD,当然想用OperationQueue去封装,也完全赞同,主要是看业务需求,而不是看技术需求。关于GCD和OperationQueue的区别以及性能,具体还是推荐看网上的博客,最好是先了解里面处理多线程的API,知道各自的优缺点,再去看会有不一样的收获。Operation是一个抽象类不能直接使用,可以自定义其子类,或者直接使用系统提供的子类BlockOperation(swift中系统提供的子类貌似就剩这么一个了)。Operation直接使用是没有开辟新的线程的,只有放到OperationQueue 中才是多线程(OperationQueue可以直接使用,复杂场景时会使用到Operation的子类)。OperationQueue使用的优点会在下面解决问题中提到部分。


再看GCD中的队列组DispatchGroup,也可以对队列做简单的管理。主要将某一个任务入组和出组,实现入组和出组主要用到二种方式,那么就可以监听入组的任务是否全部完成。

let groupQueue = DispatchGroup()
let queue = DispatchQueue.global(qos: DispatchQoS.QoSClass.background)
defer {
groupQueue.notify(queue: DispatchQueue.main) {
debugPrint("执行完成\(Thread.current)")
}
}
/// 第一种直接创建的时候就加到组中,执行完成自动出组
queue.async(group: groupQueue) {
for i in 0 ... 100 {
debugPrint(Thread.current , i , "------1")
}
}
/// 第二种自己执行前加入,完成后手动出组
groupQueue.enter()
queue.async() {
for i in 0 ... 100 {
debugPrint(Thread.current , i , "------2")
}
groupQueue.leave()
}

二种方式只有选择的差距,第一种比较简单,但是适用的场景就比较简单,但是缺点也很明显,当执行的任务也存在异步,那么就不能判断是否真的完成任务了,很简单的例子,同时发送5个请求,要数据全部返回才能执行回调,那么很明显就只能使用第二种方式了,只有数据真正的返回了才出组。




先看第一个问题,比较简单,怎样知道队列中的任务全部执行完成?

使用GCD就很简单了,将任务放到队列组中去执行,完成后自动回调,当然也可以使用OperationQueue,那就是要使用KVO了监听OperationQueue 的maxConcurrentOperationCount属性,当为0的时候任务全部执行完成。


第二个问题,怎样控制执行的先后顺序?如果使用OperationQueue比较容易,方法比较多,举二个例子。看参数就知道,直到ops中的任务执行完成再接着执行其他的任务,如果每个任务都有严格的顺序,那么直接设置OperationQueue的maxConcurrentOperationCount为1就行了,为1时候其实也就是串行队列了。

func addOperations(_ ops: [Operation], waitUntilFinished wait: Bool)

第二种方式就是添加依耐关系

let operation1 = BlockOperation {
debugPrint("开始1", Thread.current)
sleep(2)
debugPrint("完成 ")
}
let operation2 = BlockOperation {
debugPrint("开始2")
sleep(2)
debugPrint("完成")
}
operation2.addDependency(operation1)
operationQueue.addOperation(operation1)
operationQueue.addOperation(operation2)

如果使用GCD的话,那么就需要使用栅栏函数了,这个可以具体看看官方的文档或者网上优秀博客,这就举一个简单的列子

/// 栅栏函数要求队列参数为. concurrent 
let queue = DispatchQueue(label: "text.queue", attributes: .concurrent)
queue.async {
for i in 0 ... 10 {
debugPrint(i , Thread.current , "------1")
}
}
queue.async {
for i in 0 ... 10 {
debugPrint(i , Thread.current , "-----2")
}
}
/// 栅栏函数,前面的执行完,再执行栅栏函数里面的代码,执行完,再执行后面的任务
queue.async(flags: .barrier) {
for i in 0 ... 10 {
debugPrint(i , Thread.current , "------3")
}
}
queue.async {
for i in 0 ... 10 {
debugPrint(i , Thread.current , "------4")
}
}
queue.async {
for i in 0 ... 10 {
debugPrint(i , Thread.current , "------5")
}
}

举的例子比较简单,遇到实际问题其实是很复杂的(强烈建议多看第三方框架,看看别人怎么封装的,多学习),考虑的问题比较多。


第三个问题,怎样控制并发数量?问题二中已经回答了设置OperationQueue的maxConcurrentOperationCount就可以控制并发量了。GCD中的话就可以使用信号量(DispatchSemaphore)去控制并发量了,用法也很简单。信号量还有很多其他的用法,比如将异步变成同步(这种骚操作不建议去使用信号量),资源的保护等等

let queue = DispatchQueue.global(qos:    DispatchQoS.QoSClass.background)
/// 初始化信号量为2,最大并发为2,为0时会等待
let semap = DispatchSemaphore.init(value: 2)
semap.wait() // 信号量减1
queue.async {
debugPrint("开始执行", Thread.current)
sleep(2)
debugPrint("执行完成" , Thread.current)
semap.signal() // 信号量加1
}
semap.wait()
queue.async {
debugPrint("开始执行", Thread.current)
sleep(2)
debugPrint("执行完成" , Thread.current)
semap.signal()
}
semap.wait()
queue.async {
debugPrint("开始执行", Thread.current)
sleep(2)
debugPrint("执行完成" , Thread.current)
semap.signal()
}

第四个问题,怎样暂停/挂起任务?GCD可以但是相当麻烦,OperationQueue就很简单了,可以挂起,暂停所有的任务,也可以取消所有任务,在控制任务执行上,还是很方便的。这个可以参考下Alamofire中的设计,可以避免双重回调嵌套,在此不仔细详解,大概提下Alamofire设计的思路,有个方法是json序列化的,在我们最后获取数据的回调block中,但是,调用这个方法时,是将任务放到了OperationQueue中并且设置了maxConcurrentOperationCount为1,并且设置isSuspended为true,什么时候执行呢,当后台数据返回成功时isSuspended置为false,开始执行序列化的代码,执行完后我们在回调中获取后台返回的数据,没有嵌套block。


整个总结比较简单,只是大概说了下可能会遇到的问题,提供下简单的解决思路,解决复杂的问题,还需要再去多尝试,多去了解相关的文档,了解每一个API甚至参数使用的场景,或许用不到,但是万一在解决bug时不小心找到灵感了呢,书到用时方恨少。但是还是想强调下:线程复杂必死。



链接:https://www.jianshu.com/p/5fb6e565ee23

0 个评论

要回复文章请先登录注册