背景:
之前也写过个人学习的相关记录:
【Qt线程-1】this,volatile,exec(),moveToThread()_qt volatile
【Qt线程-2】事件循环(QCoreApplication::processEvents,exec)的应用
【Qt线程-3】使用事件循环,信号,stop变量,sleep阻塞,QWaitCondition+QMutex条件变量,退出子线程工作_qt阻塞线程
【Qt线程-4】事件循环嵌套,BlockingQueuedConnection与QWaitCondition比较
【Qt线程-5】生产者&消费者模型应用(多态,子线程控制,协同,事件循环)_qt生产者消费者模型
【Qt线程-6】获取当前线程id,thread()和currentThreadId(),不是想当然那样,不使用信号槽可能看不出区别_qthread获取线程id
【Qt线程-7】QThread、QThreadPool+QRunnable怎么选
联想到vs(c#)当中也有线程池的概念,有提升效率或者节约开销的方法还是要学习使用的。
之前我并没有使用过QThreadPool+QRunnable的方式,主要是看过以后觉得不爽。
本篇不想讨论过多技术实现,而是说出个人的想法感受,希望得到诸位指正。
特点分析:
QThreadPool可以节约创建线程的开销。
QRunnable没有继承自QObject,这就意味着不能使用信号槽,但业务逻辑还是要重写run函数实现,所以子线程里的业务无法正常通过信号槽通信。首先问大家,这理解有错不?
如果要QThreadPool方式可以使用信号槽,那就要业务逻辑继承QRunnable时,同时继承QObject,期间是否容易引起其它问题不好说,反正我是尽量不使用多继承的,除非业务必须。
亦或者,使用QMetaObject::invokeMethod来变相使用信号槽。
相比而言,QThread的方式,无论继承后重写run函数,还是moveTothread,都可以很方便地使用信号槽通信。但是创建和销毁线程开销相对大。
我的看法:
qt本身引以为豪的就是元数据系统和信号槽,所谓的松散耦合。尽管信号槽的执行效率要比直接调用函数低。
所以,我觉得如果不是特别强调性能的业务,还是使用QThread+moveTothread方式,能规避好多零碎的问题,并充分利用qt的设计特性。至于开销,可以自己手动控制线程的创建和销毁。比如预知线程的数量,减少创建和销毁次数。
如果是很强调性能的业务,可以考虑QThreadPool+QRunnable方式,但如此以后,就不要强行引入信号槽了。
希望大家各抒己见,向您学习。
本文完。