【Qt线程-7】QThread、QThreadPool+QRunnable怎么选

背景：

之前也写过个人学习的相关记录：

【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方式，但如此以后，就不要强行引入信号槽了。

希望大家各抒己见，向您学习。

本文完。