使用线程
基本上有种使用线程的场合：
通过利用处理器的多个核使处理速度更快。
为保持GUI线程或其他高实时性线程的响应，将耗时的操作或阻塞的调用移到其他线程。
何时使用其他技术替代线程开发人员使用线程时需要非常小心。
启动线程是很容易的，但确保所有共享数据保持一致很难。遇到问题往往很难解决，这是由于在一段时间内它可能只出现一次或只在特定的硬件配置下出现。在创建线程来解决某些问题之前，应该考虑一些替代的技术 ：
替代技术
注解 QEventLoop::processEvents()
在一个耗时的计算操作中反复调用QEventLoop::processEvents() 可以防止界面的假死。尽管如此，这个方案可伸缩性并不太好，因为该函数可能会被调用地过于频繁或者不够频繁。
QTimer 后台处理操作有时可以方便地使用Timer安排在一个在未来的某一时刻执行的槽中来完成。在没有其他事件需要处理时，时间隔为0的定时器超时事件被相应
QSocketNotifier QNetworkAccessManager QIODevice::readyRead()
这是一个替代技术，替代有一个或多个线程在慢速网络执行阻塞读的情况。只要响应部分的计算可以快速执行，这种设计比在线程中实现的同步等待更好。与线程相比这种设计更不容易出错且更节能(energy efficient)。在许多情况下也有性能优势。
一般情况下，建议只使用安全和经过测试的方案而避免引入特设线程的概念。QtConcurrent 提供了一个将任务分发到处理器所有的核的易用接口。线程代码完全被隐藏在 QtConcurrent 框架下，所以你不必考虑细节。尽管如此，QtConcurrent 不能用于线程运行时需要通信的情况，而且它也不应该被用来处理阻塞操作。 应该使用 Qt 线程的哪种技术？
有时候，你需要的不仅仅是在另一线程的上下文中运行一个函数。您可能需要有一个生存在另一个线程中的对象来为GUI线程提供服务。也许你想在另一个始终运行的线程中来轮询硬件端口并在有关注的事情发生时发送信号到GUI线程。
Qt为开发多线程应用程序提供了多种不同的解决方案。解决方案的选择依赖于新线程的目的以及线程的生命周期。
生命周期
开发任务
解决方案
一次调用
在另一个线程中运行一个函数，函数完成时退出线程
编写函数，使用QtConcurrent::run 运行它
派生QRunnable，使用QThreadPool::globalInstance()->start() 运行它
派生QThread，重新实现QThread::run() ，使用QThread::start() 运行它
一次调用
需要操作一个容器中所有的项。使用处理器所有可用的核心。一个常见的例子是从图像列表生成缩略图。
QtConcurrent 提供了map()函数来将操作应用到容器中的每一个元素，提供了fitler()函数来选择容器元素，以及指定reduce函数作为选项来组合剩余元素。
一次调用
一个耗时运行的操作需要放入另一个线程。在处理过程中，状态信息需要发送会GUI线程。 使用QThread，重新实现run函数并根据需要发送信号。使用信号槽的queued连接方式将信号连接到GUI线程的槽函数。
持久运行
生存在另一个线程中的对象，根据要求需要执行不同的任务。这意味着工作线程需要双向的通讯。 派生一个QObject对象并实现需要的信号和槽，将对象移动到一个运行有事件循环的线程中并通过queued方式连接的信号槽进行通讯。
持久运行
生存在另一个线程中的对象，执行诸如轮询端口等重复的任务并与GUI线程通讯。 同上，但是在工作线程中使用一个定时器来轮询。尽管如此，处理轮询的最好的解决方案是彻底避免它。有时QSocketNotifer是一个替代。
Qt线程基础
QThread是一个非常便利的跨平台的对平台原生线程的抽象。启动一个线程是很简单的。让我们看一个简短的代码：生成一个在线程内输出"hello"并退出的线程。
// hellothread/hellothread.h
|
1
2
3
4
5
6
|
class HelloThread : public QThread
{
Q_OBJECT
private :
void run();
};
|
我们从QThread派生出一个类，并重新实现run方法。
// hellothread/hellothread.cpp
|
1
2
3
4
|
void HelloThread::run()
{
qDebug() << "hello from worker thread " << thread ()->currentThreadId();
}
|
run方法中包含将在另一个线程中运行的代码。在本例中，一个包含线程ID的消息被打印出来。 QThread::start() 将在另一个线程中被调用。
|
1
2
3
4
5
6
7
8
9
|
int main( int argc, char *argv[])
{
QCoreApplication app(argc, argv);
HelloThread thread ;
thread .start();
qDebug() << "hello from GUI thread " << app. thread ()->currentThreadId();
thread .wait(); // do not exit before the thread is completed!
return 0;
}
|
QObject与线程
QObject有线程关联(thread affinity)[如何翻译？关联？依附性？dbzhang800 20110618]，换句话说，它生存于一个特定的线程。这意味着，在创建时QObject保存了到当前线程的指针。当事件使用postEvent()被派发时，这个信息变得很有用。事件被放置到相应线程的事件循环中。如果QObject所依附的线程没有事件循环，该事件将永远不会被传递。 要启动事件循环，必须在run()内调用exec()。线程关联可以通过moveToThread()来更改。 如上所述，当从其他线程调用对象的方法时开发人员必须始终保持谨慎。线程关联不会改变这种状况。 Qt文档中将一些方法标记为线程安全。postEvent()就是一个值得注意的例子。一个线程安全的方法可以同时在不同的线程被调用。 通常情况下并不会并发访问的一些方法，在其他线程调用对象的非线程安全的方法在出现造成意想不到行为的并发访问前数千次的访问可能都是工作正常的。编写测试代码不能完全确保线程的正确性，但它仍然是重要的。在Linux上，Valgrind和Helgrind有助于检测线程错误。 QThread的内部结构非常有趣： QThread并不生存于执行run()的新线程内。它生存于旧线程中。 QThread的大多数成员方法是线程的控制接口，并设计成从旧线程中被调用。不要使用moveToThread()将该接口移动到新创建的线程中；调用moveToThread(this)被视为不好的实践。 exec()和静态方法usleep()、msleep()、sleep()要在新创建的线程中调用。 QThread子类中定义的其他成员可在两个线程中访问。开发人员负责访问的控制。一个典型的策略是在start()被调用前设置成员变量。一旦工作线程开始运行，主线程不应该操作其他成员。当工作线程终止后，主线程可以再次访问其他成员。这是一个在线程开始前传递参数并在结束后收集结果的便捷的策略。 QObject必须始终和parent在同一个线程。对于在run()中生成的对象这儿有一个惊人的后果：
|
1
2
3
4
5
6
|
void HelloThread::run()
{
QObject *object1 = new QObject( this ); //error, parent must be in the same thread
QObject object2; // OK
QSharedPointer new QObject); // OK
}
|
使用互斥量保护数据的完整
互斥量是一个拥有lock()和unlock()方法并记住它是否已被锁定的对象。互斥量被设计为从多个线程调用。如果信号量未被锁定lock()将立即返回。下一次从另一个线程调用会发现该信号量处于锁定状态，然后lock()会阻塞线程直到其他线程调用unlock()。此功能可以确保代码段将在同一时间只能由一个线程执行。 使用事件循环防止数据破坏
Qt的事件循环对线程间的通信是一个非常有价值的工具。每个线程都可以有它自己的事件循环。在另一个线程中调用一个槽的一个安全的方法是将调用放置到另一个线程的事件循环中。这可以确保目标对象调用另一个的成员函数之前可以完成当前正在运行的成员函数。 那么，如何才能把一个成员调用放于一个事件循环中？ Qt的有两种方法来做这个。一种方法是通过queued信号槽连接；另一种是使用QCoreApplication::postEvent()派发一个事件。queued的信号槽连接是异步执行的信号槽连接。内部实现是基于posted的事件。信号的参数放入事件循环后信号函数的调用将立即返回。 连接的槽函数何时被执行依赖于事件循环其他的其他操作。 通过事件循环通信消除了我们使用互斥量时所面临的死锁问题。这就是我们为什么推荐使用事件循环，而不是使用互斥量锁定对象的原因。 处理异步执行
一种获得一个工作线程的结果的方法是等待线程终止。在许多情况下，一个阻塞等待是不可接受的。阻塞等待的替代方法是异步的结果通过posted事件或者queued信号槽进行传递。由于操作的结果不会出现在源代码的下一行而是在位于源文件其他部分的一个槽中，这会产生一定的开销，因为，但在位于源文件中其他地方的槽。 Qt开发人员习惯于使用这种异步行为工作，因为它非常相似于GUI程序中使用的的事件驱动编程。
http://www.devbean.net/2013/11/qt-study-road-2-thread-intro/
Qt 学习之路 ：线程简介
前面我们讨论了有关进程以及进程间通讯的相关问题，现在我们开始讨论线程。事实上，现代的程序中，使用线程的概率应该大于进程。特别是在多核时代，随着 CPU 主频的提升，受制于发热量的限制，CPU 散热问题已经进入瓶颈，另辟蹊径地提高程序运行效率就是使用线程，充分利用多核的优势。有关线程和进程的区别已经超出了本章的范畴，我们简单提一句，一个进程可以有一个或更多线程同时运行。线程可以看做是“轻量级进程”，进程完全由操作系统管理，线程即可以由操作系统管理，也可以由应用程序管理。 Qt 使用QThread 来管理线程。下面来看一个简单的例子：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
MainWindow::MainWindow(QWidget*parent)
:QMainWindow(parent)
{
QWidget *widget= new QWidget( this );
QVBoxLayout *layout= new QVBoxLayout;
widget->setLayout(layout);
QLCDNumber* lcdNumber= new QLCDNumber( this );
layout->addWidget(lcdNumber);
QPushButton* button= new QPushButton(tr( "Start" ), this );
layout->addWidget(button);
setCentralWidget(widget);
QTimer *timer= new QTimer( this );
connect(timer,&QTimer::timeout,[=](){
staticintsec=0;
lcdNumber->display(QString::number(sec++));
});
WorkerThread * thread = new WorkerThread( this );
connect(button,&QPushButton::clicked,[=](){
timer->start(1);
for (inti=0;i<2000000000;i++);
timer->stop();
});
}
|
我们的主界面有一个用于显示时间的 LCD 数字面板还有一个用于启动任务的按钮。程序的目的是用户点击按钮，开始一个非常耗时的运算（程序中我们以一个 2000000000 次的循环来替代这个非常耗时的工作，在真实的程序中，这可能是一个网络访问，可能是需要复制一个很大的文件或者其它任务），同时 LCD 开始显示逝去的毫秒数。毫秒数通过一个计时器QTimer进行更新。计算完成后，计时器停止。这是一个很简单的应用，也看不出有任何问题。但是当我们开始运行程序时，问题就来了：点击按钮之后，程序界面直接停止响应，直到循环结束才开始重新更新。 有经验的开发者立即指出，这里需要使用线程。这是因为 Qt 中所有界面都是在 UI 线程中（也被称为主线程，就是执行了QApplication::exec()的线程），在这个线程中执行耗时的操作（比如那个循环），就会阻塞 UI 线程，从而让界面停止响应。界面停止响应，用户体验自然不好，不过更严重的是，有些窗口管理程序会检测到你的程序已经失去响应，可能会建议用户强制停止程序，这样一来你的程序可能就此终止，任务再也无法完成。所以，为了避免这一问题，我们要使用 QThread 开启一个新的线程：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
|
class WorkerThread: public QThread
{
Q_OBJECT
public :
WorkerThread(QObject*parent=0)
:QThread(parent)
{
}
protected :
void run()
{
for (inti=0;i<1000000000;i++);
emit done();
}
signals:
voiddone();
};
MainWindow::MainWindow(QWidget*parent)
:QMainWindow(parent)
{
QWidget *widget= new QWidget( this );
QVBoxLayout *layout= new QVBoxLayout;
widget->setLayout(layout);
lcdNumber= new QLCDNumber( this );
layout->addWidget(lcdNumber);
QPushButton *button= new QPushButton(tr( "Start" ), this );
layout->addWidget(button);
setCentralWidget(widget);
QTimer *timer= new QTimer( this );
connect(timer,&QTimer::timeout,[=](){
staticintsec=0;
lcdNumber->display(QString::number(sec++));
});
WorkerThread * thread = new WorkerThread( this );
connect( thread ,&WorkerThread::done,timer,&QTimer::stop);
connect( thread ,&WorkerThread::finished, thread ,&WorkerThread::deleteLater);
connect(button,&QPushButton::clicked,[=]()
{
timer->start(1);
thread ->start();
});
}
|
注意，我们增加了一个WorkerThread类。WorkerThread继承自QThread类，重写了其run()函数。我们可以认为，run()函数就是新的线程需要执行的代码。在这里就是要执行这个循环，然后发出计算完成的信号。而在按钮点击的槽函数中，使用QThread::start()函数启动一个线程（注意，这里不是run()函数）。再次运行程序，你会发现现在界面已经不会被阻塞了。另外，我们将WorkerThread::deleteLater()函数与WorkerThread::finished()信号连接起来，当线程完成时，系统可以帮我们清除线程实例。这里的finished()信号是系统发出的，与我们自定义的done()信号无关。 这是 Qt 线程的最基本的使用方式之一（确切的说，这种使用已经不大推荐使用，不过因为看起来很清晰，而且简单使用起来也没有什么问题，所以还是有必要介绍）。代码看起来很简单，不过，如果你认为 Qt 的多线程编程也很简单，那就大错特错了。Qt 多线程的优势设计使得它使用起来变得容易，但是坑很多，稍不留神就会被绊住，尤其是涉及到与 QObject 交互的情况。稍懂多线程开发的童鞋都会知道，调试多线程开发简直就是煎熬。下面几章，我们会更详细介绍有关多线程编程的相关内容。
http://www.devbean.net/2013/11/qt-study-road-2-thread-and-event-loop/
Qt 学习之路 ：线程和事件循环
前面一章我们简单介绍了如何使用QThread实现线程。现在我们开始详细介绍如何“正确”编写多线程程序。我们这里的大部分内容来自于Qt的一篇Wiki文档，有兴趣的童鞋可以去看原文。 在介绍在以前，我们要认识两个术语： 可重入的（Reentrant）：如果多个线程可以在同一时刻调用一个类的所有函数，并且保证每一次函数调用都引用一个唯一的数据，就称这个类是可重入的（Reentrant means that all the functions in the referenced class can be called simultaneously by multiple threads, provided that each invocation of the functions reference unique data.）。大多数 C++ 类都是可重入的。类似的，一个函数被称为可重入的，如果该函数允许多个线程在同一时刻调用，而每一次的调用都只能使用其独有的数据。全局变量就不是函数独有的数据，而是共享的。换句话说，这意味着类或者函数的使用者必须使用某种额外的机制（比如锁）来控制对对象的实例或共享数据的序列化访问。 线程安全（Thread-safe）：如果多个线程可以在同一时刻调用一个类的所有函数，即使每一次函数调用都引用一个共享的数据，就说这个类是线程安全的（Threadsafe means that all the functions in the referenced class can be called simultaneously by multiple threads even when each invocation references shared data.）。如果多个线程可以在同一时刻访问函数的共享数据，就称这个函数是线程安全的。 进一步说，对于一个类，如果不同的实例可以被不同线程同时使用而不受影响，就说这个类是可重入的；如果这个类的所有成员函数都可以被不同线程同时调用而不受影响，即使这些调用针对同一个对象，那么我们就说这个类是线程安全的。由此可以看出，线程安全的语义要强于可重入。接下来，我们从事件开始讨论。之前我们说过，Qt 是事件驱动的。在 Qt 中，事件由一个普通对象表示（QEvent或其子类）。这是事件与信号的一个很大区别：事件总是由某一种类型的对象表示，针对某一个特殊的对象，而信号则没有这种目标对象。所有QObject的子类都可以通过覆盖QObject::event()函数来控制事件的对象。 事件可以由程序生成，也可以在程序外部生成。例如： QKeyEvent和QMouseEvent对象表示键盘或鼠标的交互，通常由系统的窗口管理器产生； QTimerEvent事件在定时器超时时发送给一个QObject，定时器事件通常由操作系统发出； QChildEvent在增加或删除子对象时发送给一个QObject，这是由 Qt 应用程序自己发出的。 需要注意的是，与信号不同，事件并不是一产生就被分发。事件产生之后被加入到一个队列中（这里的队列含义同数据结构中的概念，先进先出），该队列即被称为事件队列。事件分发器遍历事件队列，如果发现事件队列中有事件，那么就把这个事件发送给它的目标对象。这个循环被称作事件循环。事件循环的伪代码描述大致如下所示：
|
1
2
3
4
5
6
7
8
|
while (is_active)
{
while (!event_queue_is_empty)
{
dispatch_next_event();
}
wait_for_more_events();
}
|
正如前面所说的，调用QCoreApplication::exec() 函数意味着进入了主循环。我们把事件循环理解为一个无限循环，直到QCoreApplication::exit()或者QCoreApplication::quit()被调用，事件循环才真正退出。 伪代码里面的while会遍历整个事件队列，发送从队列中找到的事件；wait_for_more_events()函数则会阻塞事件循环，直到又有新的事件产生。我们仔细考虑这段代码，在wait_for_more_events()函数所得到的新的事件都应该是由程序外部产生的。因为所有内部事件都应该在事件队列中处理完毕了。因此，我们说事件循环在wait_for_more_events()函数进入休眠，并且可以被下面几种情况唤醒： 窗口管理器的动作（键盘、鼠标按键按下、与窗口交互等）； 套接字动作（网络传来可读的数据，或者是套接字非阻塞写等）； 定时器； 由其它线程发出的事件（我们会在后文详细解释这种情况）。 在类 UNIX 系统中，窗口管理器（比如 X11）会通过套接字（Unix Domain 或 TCP/IP）向应用程序发出窗口活动的通知，因为客户端就是通过这种机制与 X 服务器交互的。如果我们决定要实现基于内部的socketpair(2)函数的跨线程事件的派发，那么窗口的管理活动需要唤醒的是： 套接字 socket 定时器 timer 这也正是select(2)系统调用所做的：它监视窗口活动的一组描述符，如果在一定时间内没有活动，它会发出超时消息（这种超时是可配置的）。Qt 所要做的，就是把select()的返回值转换成一个合适的QEvent子类的对象，然后将其放入事件队列。好了，现在你已经知道事件循环的内部机制了。 至于为什么需要事件循环，我们可以简单列出一个清单： 组件的绘制与交互：QWidget::paintEvent()会在发出QPaintEvent事件时被调用。该事件可以通过内部QWidget::update()调用或者窗口管理器（例如显示一个隐藏的窗口）发出。所有交互事件（键盘、鼠标）也是类似的：这些事件都要求有一个事件循环才能发出。 定时器：长话短说，它们会在select(2)或其他类似的调用超时时被发出，因此你需要允许 Qt 通过返回事件循环来实现这些调用。 网络：所有低级网络类（QTcpSocket、QUdpSocket以及QTcpServer等）都是异步的。当你调用read()函数时，它们仅仅返回已可用的数据；当你调用write()函数时，它们仅仅将写入列入计划列表稍后执行。只有返回事件循环的时候，真正的读写才会执行。注意，这些类也有同步函数（以waitFor开头的函数），但是它们并不推荐使用，就是因为它们会阻塞事件循环。高级的类，例如QNetworkAccessManager则根本不提供同步 API，因此必须要求事件循环。 有了事件循环，你就会想怎样阻塞它。阻塞它的理由可能有很多，例如我就想让QNetworkAccessManager同步执行。在解释为什么永远不要阻塞事件循环之前，我们要了解究竟什么是“阻塞”。假设我们有一个按钮Button，这个按钮在点击时会发出一个信号。这个信号会与一个Worker对象连接，这个Worker对象会执行很耗时的操作。当点击了按钮之后，我们观察从上到下的函数调用堆栈：
|
1
2
3
4
5
6
7
8
|
main( int , char **)
QApplication::exec()
[…]
QWidget::event(QEvent *)
Button::mousePressEvent(QMouseEvent *)
Button::clicked()
[…]
Worker::doWork()
|
我们在main()函数开始事件循环，也就是常见的QApplication::exec()函数。窗口管理器侦测到鼠标点击后，Qt 会发现并将其转换成QMouseEvent事件，发送给组件的event()函数。这一过程是通过QApplication::notify()函数实现的。注意我们的按钮并没有覆盖event()函数，因此其父类的实现将被执行，也就是QWidget::event()函数。这个函数发现这个事件是一个鼠标点击事件，于是调用了对应的事件处理函数，就是Button::mousePressEvent()函数。我们重写了这个函数，发出Button::clicked()信号，而正是这个信号会调用Worker::doWork()槽函数。有关这一机制我们在前面的事件部分曾有阐述，如果不明白这部分机制，请参考前面的章节。 在worker努力工作的时候，事件循环在干什么？或许你已经猜到了答案：什么都没做！事件循环发出了鼠标按下的事件，然后等着事件处理函数返回。此时，它一直是阻塞的，直到Worker::doWork()函数结束。注意，我们使用了“阻塞”一词，也就是说，所谓阻塞事件循环，意思是没有事件被派发处理。 在事件就此卡住时，组件也不会更新自身（因为QPaintEvent对象还在队列中），也不会有其它什么交互发生（还是同样的原因），定时器也不会超时并且网络交互会越来越慢直到停止。也就是说，前面我们大费周折分析的各种依赖事件循环的活动都会停止。这时候，需要窗口管理器会检测到你的应用程序不再处理任何事件，于是告诉用户你的程序失去响应。这就是为什么我们需要快速地处理事件，并且尽可能快地返回事件循环。 现在，重点来了：我们不可能避免业务逻辑中的耗时操作，那么怎样做才能既可以执行那些耗时的操作，又不会阻塞事件循环呢？一般会有三种解决方案：第一，我们将任务移到另外的线程（正如我们上一章看到的那样，不过现在我们暂时略过这部分内容）；第二，我们手动强制运行事件循环。想要强制运行事件循环，我们需要在耗时的任务中一遍遍地调用QCoreApplication::processEvents()函数。QCoreApplication::processEvents()函数会发出事件队列中的所有事件，并且立即返回到调用者。仔细想一下，我们在这里所做的，就是模拟了一个事件循环。 另外一种解决方案我们在前面的章节提到过：使用QEventLoop类重新进入新的事件循环。通过调用QEventLoop::exec()函数，我们重新进入新的事件循环，给QEventLoop::quit()槽函数发送信号则退出这个事件循环。拿前面的例子来说：
|
1
2
3
4
5
6
|
QEventLoop eventLoop;
connect(netWorker,&NetWorker::finished,
&eventLoop,&QEventLoop::quit);
QNetworkReply *reply=netWorker->get(url);
replyMap.insert(reply,FetchWeatherInfo);
eventLoop.exec();
|
QNetworkReply没有提供阻塞式 API，并且要求有一个事件循环。我们通过一个局部的QEventLoop来达到这一目的：当网络响应完成时，这个局部的事件循环也会退出。 前面我们也强调过：通过“其它的入口”进入事件循环要特别小心：因为它会导致递归调用！现在我们可以看看为什么会导致递归调用了。回过头来看看按钮的例子。当我们在Worker::doWork()槽函数中调用了QCoreApplication::processEvents()函数时，用户再次点击按钮，槽函数Worker::doWork()又一次被调用：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
main( int , char **)
QApplication::exec()
[…]
QWidget::event(QEvent *)
Button::mousePressEvent(QMouseEvent *)
Button::clicked()
[…]
Worker::doWork() // 第一次调用
QCoreApplication::processEvents() // 手动发出所有事件
[…]
QWidget::event(QEvent *) // 用户又点击了一下按钮…
Button::mousePressEvent(QMouseEvent *)
Button::clicked() // 又发出了信号…
[…]
Worker::doWork() // 递归进入了槽函数！
|
当然，这种情况也有解决的办法：我们可以在调用QCoreApplication::processEvents()函数时传入QEventLoop::ExcludeUserInputEvents参数，意思是不要再次派发用户输入事件（这些事件仍旧会保留在事件队列中）。 幸运的是，在删除事件（也就是由QObject::deleteLater()函数加入到事件队列中的事件）中，没有这个问题。这是因为删除事件是由另外的机制处理的。删除事件只有在事件循环有比较小的“嵌套”的情况下才会被处理，而不是调用了deleteLater()函数的那个循环。例如：
|
1
2
3
4
|
QObject* object= new QObject;
object->deleteLater();
QDialog dialog;
dialog.exec();
|
这段代码并不会造成野指针（注意，QDialog::exec()的调用是嵌套在deleteLater()调用所在的事件循环之内的）。通过QEventLoop进入局部事件循环也是类似的。在 Qt 4.7.3 中，唯一的例外是，在没有事件循环的情况下直接调用deleteLater()函数，那么，之后第一个进入的事件循环会获取这个事件，然后直接将这个对象删除。不过这也是合理的，因为 Qt 本来不知道会执行删除操作的那个“外部的”事件循环，所以第一个事件循环就会直接删除对象。
http://www.devbean.net/2013/11/qt-study-road-2-thread-related-classes/
Qt 学习之路 2（73）：Qt 线程相关类
希望上一章有关事件循环的内容还没有把你绕晕。本章将重新回到有关线程的相关内容上面来。在前面的章节我们了解了有关QThread类的简单使用。不过，Qt 提供的有关线程的类可不那么简单，否则的话我们也没必要再三强调使用线程一定要万分小心，一不留神就会陷入陷阱。 事实上，Qt 对线程的支持可以追溯到2000年9月22日发布的 Qt 2.2。在这个版本中，Qt 引入了QThread。不过，当时对线程的支持并不是默认开启的。Qt 4.0 开始，线程成为所有平台的默认开启选项（这意味着如果不需要线程，你可以通过编译选项关闭它，不过这不是我们现在的重点）。现在版本的 Qt 引入了很多类来支持线程，下面我们将开始逐一了解它们。 QThread是我们将要详细介绍的第一个类。它也是 Qt 线程类中最核心的底层类。由于 Qt 的跨平台特性，QThread要隐藏掉所有平台相关的代码。 正如前面所说，要使用QThread开始一个线程，我们可以创建它的一个子类，然后覆盖其QThread::run()函数：
|
1
2
3
4
5
6
7
8
|
class Thread: public QThread
{
protected :
voidrun()
{
/* 线程的相关代码 */
}
};
|
然后我们这样使用新建的类来开始一个新的线程：
|
1
2
|
Thread* thread = new Thread;
thread ->start(); // 使用 start() 开始新的线程
|
注意，从 Qt 4.4 开始，QThread就已经不是抽象类了。QThread::run()不再是纯虚函数，而是有了一个默认的实现。这个默认实现其实是简单地调用了QThread::exec()函数，而这个函数，按照我们前面所说的，其实是开始了一个事件循环（有关这种实现的进一步阐述，我们将在后面的章节详细介绍）。 QRunnable是我们要介绍的第二个类。这是一个轻量级的抽象类，用于开始一个另外线程的任务。这种任务是运行过后就丢弃的。由于这个类是抽象类，我们需要继承QRunnable，然后重写其纯虚函数QRunnable::run()：
|
1
2
3
4
5
6
7
8
|
class Task: public QRunnable
{
public :
void run()
{
/* 线程的相关代码 */
}
};
|
要真正执行一个QRunnable对象，我们需要使用QThreadPool类。顾名思义，这个类用于管理一个线程池。通过调用QThreadPool::start(runnable)函数，我们将一个QRunnable对象放入QThreadPool的执行队列。一旦有线程可用，线程池将会选择一个QRunnable对象，然后在那个线程开始执行。所有 Qt 应用程序都有一个全局线程池，我们可以使用QThreadPool::globalInstance()获得这个全局线程池；与此同时，我们也可以自己创建私有的线程池，并进行手动管理。 需要注意的是，QRunnable不是一个QObject，因此也就没有内建的与其它组件交互的机制。为了与其它组件进行交互，你必须自己编写低级线程原语，例如使用 mutex 守护来获取结果等。 QtConcurrent是我们要介绍的最后一个对象。这是一个高级 API，构建于QThreadPool之上，用于处理大多数通用的并行计算模式：map、reduce 以及 filter。它还提供了QtConcurrent::run()函数，用于在另外的线程运行一个函数。注意，QtConcurrent是一个命名空间而不是一个类，因此其中的所有函数都是命名空间内的全局函数。 不同于QThread和QRunnable，QtConcurrent不要求我们使用低级同步原语：所有的QtConcurrent都返回一个QFuture对象。这个对象可以用来查询当前的运算状态（也就是任务的进度），可以用来暂停/回复/取消任务，当然也可以用来获得运算结果。注意，并不是所有的QFuture对象都支持暂停或取消的操作。比如，由QtConcurrent::run()返回的QFuture对象不能取消，但是由QtConcurrent::mappedReduced()返回的是可以的。QFutureWatcher类则用来监视QFuture的进度，我们可以用信号槽与QFutureWatcher进行交互（注意，QFuture也没有继承QObject）。
http://www.devbean.net/2013/12/qt-study-road-2-thread-and-qobject/
Qt 学习之路 2（74）：线程和 QObject
前面两个章节我们从事件循环和线程类库两个角度阐述有关线程的问题。本章我们将深入线程间得交互，探讨线程和QObject之间的关系。在某种程度上，这才是多线程编程真正需要注意的问题。 现在我们已经讨论过事件循环。我们说，每一个 Qt 应用程序至少有一个事件循环，就是调用了QCoreApplication::exec()的那个事件循环。不过，QThread也可以开启事件循环。只不过这是一个受限于线程内部的事件循环。因此我们将处于调用main()函数的那个线程，并且由QCoreApplication::exec()创建开启的那个事件循环成为主事件循环，或者直接叫主循环。注意，QCoreApplication::exec()只能在调用main()函数的线程调用。主循环所在的线程就是主线程，也被成为 GUI 线程，因为所有有关 GUI 的操作都必须在这个线程进行。QThread的局部事件循环则可以通过在QThread::run()中调用QThread::exec()开启：
|
1
2
3
4
5
6
7
8
|
class Thread: public QThread
{
protected :
voidrun(){
/* ... 初始化 ... */
exec();
}
};
|
记得我们前面介绍过，Qt 4.4 版本以后，QThread::run()不再是纯虚函数，它会调用QThread::exec()函数。与QCoreApplication一样，QThread也有QThread::quit()和QThread::exit()函数来终止事件循环。 线程的事件循环用于为线程中的所有QObjects对象分发事件；默认情况下，这些对象包括线程中创建的所有对象，或者是在别处创建完成后被移动到该线程的对象（我们会在后面详细介绍“移动”这个问题）。我们说，一个QObject的所依附的线程（thread affinity）是指它所在的那个线程。它同样适用于在QThread的构造函数中构建的对象：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
class MyThread: public QThread
{
public :
MyThread()
{
otherObj= new QObject;
}
private :
QObject obj;
QObject* otherObj;
QScopedPointer yetAnotherObj;
};
|
在我们创建了MyThread对象之后，obj、otherObj和yetAnotherObj的线程依附性是怎样的？是不是就是MyThread所表示的那个线程？要回答这个问题，我们必须看看究竟是哪个线程创建了它们：实际上，是调用了MyThread构造函数的线程创建了它们。因此，这些对象不在MyThread所表示的线程，而是在创建了MyThread的那个线程中。 我们可以通过调用QObject::thread()可以查询一个QObject的线程依附性。注意，在QCoreApplication对象之前创建的QObject没有所谓线程依附性，因此也就没有对象为其派发事件。也就是说，实际是QCoreApplication创建了代表主线程的QThread对象。
我们可以使用线程安全的QCoreApplication::postEvent()函数向一个对象发送事件。它将把事件加入到对象所在的线程的事件队列中，因此，如果这个线程没有运行事件循环，这个事件也不会被派发。 值得注意的一点是，QObject及其所有子类都不是线程安全的（但都是可重入的）。因此，你不能有两个线程同时访问一个QObject对象，除非这个对象的内部数据都已经很好地序列化（例如为每个数据访问加锁）。记住，在你从另外的线程访问一个对象时，它可能正在处理所在线程的事件循环派发的事件！基于同样的原因，你也不能在另外的线程直接delete一个QObject对象，相反，你需要调用QObject::deleteLater()函数，这个函数会给对象所在线程发送一个删除的事件。 此外，QWidget及其子类，以及所有其它 GUI 相关类（即便不是QObject的子类，例如QPixmap），甚至不是可重入的：它们只能在 GUI 线程访问。 QObject的线程依附性是可以改变的，方法是调用QObject::moveToThread()函数。该函数会改变一个对象及其所有子对象的线程依附性。由于QObject不是线程安全的，所以我们只能在该对象所在线程上调用这个函数。也就是说，我们只能在对象所在线程将这个对象移动到另外的线程，不能在另外的线程改变对象的线程依附性。还有一点是，Qt 要求QObject的所有子对象都必须和其父对象在同一线程。这意味着： 不能对有父对象（parent 属性）的对象使用QObject::moveToThread()函数 不能在QThread中以这个QThread本身作为父对象创建对象，例如：
|
1
2
3
4
5
6
7
|
classThread:publicQThread
{
voidrun()
{
QObject *obj= new QObject( this ); // 错误！
}
};
|
这是因为QThread对象所依附的线程是创建它的那个线程，而不是它所代表的线程。 Qt 还要求，在代表一个线程的QThread对象销毁之前，所有在这个线程中的对象都必须先delete。要达到这一点并不困难：我们只需在QThread::run()的栈上创建对象即可。 现在的问题是，既然线程创建的对象都只能在函数栈上，怎么能让这些对象与其它线程的对象通信呢？Qt 提供了一个优雅清晰的解决方案：我们在线程的事件队列中加入一个事件，然后在事件处理函数中调用我们所关心的函数。显然这需要线程有一个事件循环。这种机制依赖于 moc 提供的反射：因此，只有信号、槽和使用Q_INVOKABLE宏标记的函数可以在另外的线程中调用。 QMetaObject::invokeMethod()静态函数会这样调用：
|
1
2
3
4
|
QMetaObject::invokeMethod(object, "methodName" ,
Qt::QueuedConnection,
Q_ARG(type1,arg1),
Q_ARG(type2,arg2));
|
主意，上面函数调用中出现的参数类型都必须提供一个公有构造函数，一个公有的析构函数和一个公有的复制构造函数，并且要使用qRegisterMetaType()函数向 Qt 类型系统注册。 跨线程的信号槽也是类似的。当我们将信号与槽连接起来时，QObject::connect()的最后一个参数将指定连接类型： Qt::DirectConnection：直接连接意味着槽函数将在信号发出的线程直接调用 Qt::QueuedConnection：队列连接意味着向接受者所在线程发送一个事件，该线程的事件循环将获得这个事件，然后之后的某个时刻调用槽函数 Qt::BlockingQueuedConnection：阻塞的队列连接就像队列连接，但是发送者线程将会阻塞，直到接受者所在线程的事件循环获得这个事件，槽函数被调用之后，函数才会返回 Qt::AutoConnection：自动连接（默认）意味着如果接受者所在线程就是当前线程，则使用直接连接；否则将使用队列连接 注意在上面每种情况中，发送者所在线程都是无关紧要的！在自动连接情况下，Qt 需要查看信号发出的线程是不是与接受者所在线程一致，来决定连接类型。注意，Qt 检查的是信号发出的线程，而不是信号发出的对象所在的线程！我们可以看看下面的代码：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
class Thread: public QThread
{
Q_OBJECT
signals:
void aSignal();
protected :
void run()
{
emit aSignal();
}
};
/* ... */
Thread thread ;
Object obj;
QObject::connect(& thread ,SIGNAL(aSignal()),&obj,SLOT(aSlot()));
thread .start();
|
aSignal()信号在一个新的线程被发出（也就是Thread所代表的线程）。注意，因为这个线程并不是Object所在的线程（Object所在的线程和Thread所在的是同一个线程，回忆下，信号槽的连接方式与发送者所在线程无关），所以这里将会使用队列连接。 另外一个常见的错误是：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
class Thread: public QThread
{
Q_OBJECT
slots:
void aSlot()
{
/* ... */
}
protected :
void run()
{
/* ... */
}
};
/* ... */
Thread thread ;
Object obj;
QObject::connect(&obj,SIGNAL(aSignal()),& thread ,SLOT(aSlot()));
thread .start();
obj.emitSignal();
|
这里的obj发出aSignal()信号时，使用哪种连接方式？答案是：直接连接。因为Thread对象所在线程发出了信号，也就是信号发出的线程与接受者是同一个。在aSlot()槽函数中，我们可以直接访问Thread的某些成员变量，但是注意，在我们访问这些成员变量时，Thread::run()函数可能也在访问！这意味着二者并发进行：这是一个完美的导致崩溃的隐藏bug。 另外一个例子可能更为重要：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
class Thread: public QThread
{
Q_OBJECT
slots:
void aSlot()
{
/* ... */
}
protected :
void run()
{
QObject*obj=newObject;
connect(obj,SIGNAL(aSignal()), this ,SLOT(aSlot()));
/* ... */
}
};
|
这个例子也会使用队列连接。然而，这个例子比上面的例子更具隐蔽性：在这个例子中，你可能会觉得，Object所在Thread所代表的线程中被创建，又是访问的Thread自己的成员数据。稍有不慎便会写出这种代码。 为了解决这个问题，我们可以这么做：Thread构造函数中增加一个函数调用：moveToThread(this)：
|
1
2
3
4
5
6
7
8
9
10
11
|
class Thread: public QThread
{
Q_OBJECT
public :
Thread()
{
moveToThread( this ); // 错误！
}
/* ... */
};
|
实际上，这的确可行（因为Thread的线程依附性被改变了：它所在的线程成了自己），但是这并不是一个好主意。这种代码意味着我们其实误解了线程对象（QThread子类）的设计意图：QThread对象不是线程本身，它们其实是用于管理它所代表的线程的对象。因此，它们应该在另外的线程被使用（通常就是它自己所在的线程），而不是在自己所代表的线程中。 上面问题的最好的解决方案是，将处理任务的部分与管理线程的部分分离。简单来说，我们可以利用一个QObject的子类，使用QObject::moveToThread()改变其线程依附性：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
class Worker: public QObject
{
Q_OBJECT
public slots:
void doWork()
{
/* ... */
}
};
/* ... */
QThread * thread = new QThread;
Worker *worker= new Worker;
connect(obj,SIGNAL(workReady()),worker,SLOT(doWork()));
worker->moveToThread( thread );
thread ->start();
|
http://www.devbean.net/2013/12/qt-study-road-2-thread-summary/
Qt 学习之路：线程总结
前面我们已经详细介绍过有关线程的一些值得注意的事项。现在我们开始对线程做一些总结。 有关线程，你可以做的是： 在QThread子类添加信号。这是绝对安全的，并且也是正确的（前面我们已经详细介绍过，发送者的线程依附性没有关系）
不应该做的是： 调用moveToThread(this)函数 指定连接类型：这通常意味着你正在做错误的事情，比如将QThread控制接口与业务逻辑混杂在了一起（而这应该放在该线程的一个独立对象中） 在QThread子类添加槽函数：这意味着它们将在错误的线程被调用，也就是QThread对象所在线程，而不是QThread对象管理的线程。这又需要你指定连接类型或者调用moveToThread(this)函数 使用QThread::terminate()函数 不能做的是： 在线程还在运行时退出程序。使用QThread::wait()函数等待线程结束 在QThread对象所管理的线程仍在运行时就销毁该对象。如果你需要某种“自行销毁”的操作，你可以把finished()信号同deleteLater()槽连接起来 那么，下面一个问题是：我什么时候应该使用线程？ 首先，当你不得不使用同步 API 的时候。 如果你需要使用一个没有非阻塞 API 的库或代码（所谓非阻塞 API，很大程度上就是指信号槽、事件、回调等），那么，避免事件循环被阻塞的解决方案就是使用进程或者线程。不过，由于开启一个新的工作进程，让这个进程去完成任务，然后再与当前进程进行通信，这一系列操作的代价都要比开启线程要昂贵得多，所以，线程通常是最好的选择。 一个很好的例子是地址解析服务。注意我们这里并不讨论任何第三方 API，仅仅假设一个有这样功能的库。这个库的工作是将一个主机名转换成地址。这个过程需要去到一个系统（也就是域名系统，Domain Name System, DNS）执行查询，这个系统通常是一个远程系统。一般这种响应应该瞬间完成，但是并不排除远程服务器失败、某些包可能会丢失、网络可能失去链接等等。简单来说，我们的查询可能会等几十秒钟。 UNIX 系统上的标准 API 是阻塞的（不仅是旧的gethostbyname(3)，就连新的getservbyname(3)和getaddrinfo(3)也是一样）。Qt 提供的QHostInfo类同样用于地址解析，默认情况下，内部使用一个QThreadPool提供后台运行方式的查询（如果关闭了 Qt 的线程支持，则提供阻塞式 API）。 另外一个例子是图像加载和缩放。QImageReader和QImage只提供了阻塞式 API，允许我们从设备读取图片，或者是缩放到不同的分辨率。如果你需要处理很大的图像，这种任务会花费几十秒钟。 其次，当你希望扩展到多核应用的时候。 线程允许你的程序利用多核系统的优势。每一个线程都可以被操作系统独立调度，如果你的程序运行在多核机器上，调度器很可能会将每一个线程分配到各自的处理器上面运行。 举个例子，一个程序需要为很多图像生成缩略图。一个具有固定 n 个线程的线程池，每一个线程交给系统中的一个可用的 CPU 进行处理（我们可以使用QThread::idealThreadCount()获取可用的 CPU 数）。这样的调度将会把图像缩放工作交给所有线程执行，从而有效地提升效率，几乎达到与 CPU 数的线性提升（实际情况不会这么简单，因为有时候 CPU 并不是瓶颈所在）。 第三，当你不想被别人阻塞的时候。 这是一个相当高级的话题，所以你现在可以暂时不看这段。这个问题的一个很好的例子是在 WebKit 中使用QNetworkAccessManager。WebKit 是一个现代的浏览器引擎。它帮助我们展示网页。Qt 中的QWebView就是使用的 WebKit。 QNetworkAccessManager则是 Qt 处理 HTTP 请求和响应的通用类。我们可以将它看做浏览器的网络引擎。在 Qt 4.8 之前，这个类没有使用任何协助工作线程，所有的网络处理都是在QNetworkAccessManager及其QNetworkReply所在线程完成。 虽然在网络处理中不使用线程是一个好主意，但它也有一个很大的缺点：如果你不能及时从 socket 读取数据，内核缓冲区将会被填满，于是开始丢包，传输速度将会直线下降。 socket 活动（也就是从一个 socket 读取一些可用的数据）是由 Qt 的事件循环管理的。因此，阻塞事件循环将会导致传输性能的损失，因为没有人会获得有数据可读的通知，因此也就没有人能够读取这些数据。 但是什么会阻塞事件循环？最坏的答案是：WebKit 自己！只要收到数据，WebKit 就开始生成网页布局。不幸的是，这个布局的过程非常复杂和耗时，因此它会阻塞事件循环。尽管阻塞时间很短，但是足以影响到正常的数据传输（宽带连接在这里发挥了作用，在很短时间内就可以塞满内核缓冲区）。 总结一下上面所说的内容： WebKit 发起一次请求 从服务器响应获取一些数据 WebKit 利用到达的数据开始进行网页布局，阻塞事件循环 由于事件循环被阻塞，也就没有了可用的事件循环，于是操作系统接收了到达的数据，但是却不能从QNetworkAccessManager的 socket 读取 内核缓冲区被填满，传输速度变慢 网页的整体加载时间被自身的传输速度的降低而变得越来越坏。 注意，由于QNetworkAccessManager和QNetworkReply都是QObject，所以它们都不是线程安全的，因此你不能将它们移动到另外的线程继续使用。因为它们可能同时有两个线程访问：你自己的和它们所在的线程，这是因为派发给它们的事件会由后面一个线程的事件循环发出，但你不能确定哪一线程是“后面一个”。 Qt 4.8 之后，QNetworkAccessManager默认会在一个独立的线程处理 HTTP 请求，所以导致 GUI 失去响应以及操作系统缓冲区过快填满的问题应该已经被解决了。 那么，什么情况下不应该使用线程呢？ 定时器 这可能是最容易误用线程的情况了。如果我们需要每隔一段时间调用一个函数，很多人可能会这么写代码：
|
1
2
3
4
5
6
|
// 最错误的代码
while (condition)
{
doWork();
sleep(1); // C 库里面的 sleep(3) 函数
}
|
当读过我们前面的文章之后，可能又会引入线程，改成这样的代码：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
// 错误的代码
class Thread: public QThread
{
protected :
voidrun()
{
while (condition)
{
// 注意，如果我们要在别的线程修改 condition，那么它也需要加锁
doWork();
sleep(1); // 这次是 QThread::sleep()
}
}
};
|
最好最简单的实现是使用定时器，比如QTimer，设置 1s 超时，然后将doWork()作为槽：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
class Worker: public QObject
{
Q_OBJECT
public :
Worker()
{
connect(&timer,SIGNAL(timeout()), this ,SLOT(doWork()));
timer.start(1000);
}
privateslots:
void doWork()
{
/* ... */
}
private :
QTimer timer;
};
|
我们所需要的就是开始事件循环，然后每隔一秒doWork()就会被自动调用。 网络/状态机 下面是一个很常见的处理网络操作的设计模式：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
socket->connect(host);
socket->waitForConnected();
data=getData();
socket->write(data);
socket->waitForBytesWritten();
socket->waitForReadyRead();
socket->read(response);
reply=process(response);
socket->write(reply);
socket->waitForBytesWritten();
/* ... */
|
在经过前面几章的介绍之后，不用多说，我们就会发现这里的问题：大量的waitFor*()函数会阻塞事件循环，冻结 UI 界面等等。注意，上面的代码还没有加入异常处理，否则的话肯定会更复杂。这段代码的错误在于，我们的网络实际是异步的，如果我们非得按照同步方式处理，就像拿起枪打自己的脚。为了解决这个问题，很多人会简单地将这段代码移动到一个新的线程。 一个更抽象的例子是：
|
1
2
3
4
5
6
7
8
9
10
11
12
|
result=process_one_thing();
if (result->something()){
process_this();
} else {
process_that();
}
wait_for_user_input();
input=read_user_input();
process_user_input(input);
/* ... */
|
这段抽象的代码与前面网络的例子有“异曲同工之妙”。 让我们回过头来看看这段代码究竟是做了什么：我们实际是想创建一个状态机，这个状态机要根据用户的输入作出合理的响应。例如我们网络的例子，我们实际是想要构建这样的东西：
空闲→正在连接（调用
connectToHost()
） 正在连接→成功连接（发出
connected()
信号）
成功连接→发送登录数据（将登录数据发送到服务器） 发送登录数据→登录成功（服务器返回ACK） 发送登录数据→登录失败（服务器返回NACK） 以此类推。 既然知道我们的实际目的，我们就可以修改代码来创建一个真正的状态机（Qt 甚至提供了一个状态机类：QStateMachine）。创建状态机最简单的方法是使用一个枚举来记住当前状态。我们可以编写如下代码：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
|
class Object: public QObject
{
Q_OBJECT
enumState
{
State1,State2,State3 /* ... */
};
State state;
public :
Object():state(State1)
{
connect(source,SIGNAL(ready()), this ,SLOT(doWork()));
}
private slots:
voiddoWork()
{
switch (state)
{
caseState1:
/* ... */
state=State2;
break ;
caseState2:
/* ... */
state=State3;
break ;
/* ... */
}
}
};
|
source对象是哪来的？这个对象其实就是我们关心的对象：例如，在网络的例子中，我们可能希望把 socket 的QAbstractSocket::connected()或者QIODevice::readyRead()信号与我们的槽函数连接起来。当然，我们很容易添加更多更合适的代码（比如错误处理，使用QAbstractSocket::error()信号就可以了）。这种代码是真正异步、信号驱动的设计。 将任务分割成若干部分 假设我们有一个很耗时的计算，我们不能简单地将它移动到另外的线程（或者是我们根本无法移动它，比如这个任务必须在 GUI 线程完成）。如果我们将这个计算任务分割成小块，那么我们就可以及时返回事件循环，从而让事件循环继续派发事件，调用处理下一个小块的函数。回一下如何实现队列连接，我们就可以轻松完成这个任务：将事件提交到接收对象所在线程的事件循环；当事件发出时，响应函数就会被调用。 我们可以使用QMetaObject::invokeMethod()函数，通过指定Qt::QueuedConnection作为调用类型来达到相同的效果。不过这要求函数必须是内省的，也就是说这个函数要么是一个槽函数，要么标记有Q_INVOKABLE宏。如果我们还需要传递参数，我们需要使用qRegisterMetaType()函数将参数注册到 Qt 元类型系统。下面是代码示例：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
class Worker: public QObject
{
Q_OBJECT
public slots:
void startProcessing()
{
processItem(0);
}
void processItem(intindex)
{
/* 处理 items[index] ... */
if (index {
QMetaObject::invokeMethod( this ,
"processItem" ,
Qt::QueuedConnection,
Q_ARG( int ,index+1));
}
}
};
|
由于没有任何线程调用，所以我们可以轻易对这种计算任务执行暂停/恢复/取消，以及获取结果。 至此，我们利用五个章节将有关线程的问题简单介绍了下。线程应该说是全部设计里面最复杂的部分之一，所以这部分内容也会比较困难。在实际运用中肯定会更多的问题，这就只能让我们具体分析了。