企业官网建设流程全解析

简介：QT线程及多线程是一份面向Qt开发者的并发编程实战资源，内容覆盖QThread线程创建与生命周期管理、信号槽跨线程通信机制，以及QMutex、QWaitCondition、QSemaphore等同步原语的用法，适合需要提升异步任务处理能力的C++/Qt中初级开发者。资源包内共13个文件，包含cpp源文件、h头文件、pro工程文件、ui界面文件及jpg/gif演示素材，并配有readme说明文档，便于对照源码逐步理解线程安全写法与常见陷阱。包体仅2.16MB，轻量易用，已有988人学习下载。代码案例从QThread子类重写run()到使用moveToThread()将工作对象迁移至新线程，完整展示了正确执行后台任务并优雅退出的思路；同时通过互斥锁性能对比图，直观揭示锁开销与并发设计要点，可帮助读者快速落地到网络通信、数据库操作等实际场景。

1. 项目概述与真实需求拆解

1.1 为什么Qt多线程总是一学就会、一写就废

先说个实际场景：你用QSerialPort做了一个串口调试助手，波特率115200，数据量一大，界面就开始卡顿，鼠标转圈，拖动窗口像幻灯片。这时候几乎所有教程都会告诉你“用多线程啊”，但等你真把数据读取放到QThread里，问题反而更多了——要么界面还是卡，要么程序直接崩溃，更诡异的是明明线程退出了，程序却关不掉。

这个项目标题是“QT线程及多线程”，但我更愿意把它理解成“如何正确地在Qt里使用多线程而不把自己绕进去”。Qt的多线程和原生C++多线程最大的区别在于：Qt不仅有线程本身，还有一套事件循环、信号槽跨线程投递机制，以及海量的“只能在主线程操作”的界面类。把这套机制理解透了，多线程只是顺手的事；理解不透，就会陷入“加线程→更卡→再加线程→崩溃”的死循环。

这篇内容适合三类人：一是刚接触Qt、被界面卡顿问题逼着学多线程的初学者；二是已经会用QThread但搞不清moveToThread和继承QThread到底该选谁的进阶者；三是找工作前想系统梳理多线程知识点的求职者。我把这些年踩过的坑、验证过的方案、以及面试里经常被问到的细节都整理出来，一次讲透。

1.2 从热搜词看大家真正在困扰什么

我翻了下相关搜索记录，发现几个非常典型的高频问题：qt崩溃、qt界面设计、qt怎么调用halcon、qt 串口编程、qt qcustomplot kissfft时域到频域波形、qt模拟鼠标点击事件，还有qt打包应用程序 windeployqt。把这些关键词串起来，能明显看出一个共性需求：大家都在做“带界面的数据采集/处理工具”，而且采集端和处理端往往涉及耗时操作。

举个最典型的链路：串口或者网络把数据收进来 → 用QCustomPlot画实时曲线 → 需要把时域信号用KISSFFT转成频域波形 → 最后还要打包发布给同事用。这个链路里的每一个环节，只要数据量稍微大一点，单线程必然卡顿。而解决这些问题，核心路径只有一条：把“数据采集”“数据处理”“界面绘制”三个环节解耦，该并行的并行，该回主线程的回主线程。

所以这篇内容不会只讲理论，我会把一个完整的“串口采集+FFT频谱显示”案例拆开揉碎，从线程方案选型、信号槽连接机制、到什么操作必须回主线程、以及最终打包时可能遇到的坑，全部过一遍。看完你就能直接照着写自己的版本。

2. Qt多线程的四种套路与选型思路

2.1 继承QThread：最经典也最容易用错的方案

继承QThread重写run()函数，是很多Qt教程喜欢教的第一个多线程示例。我自己最早学的时候也是这么做的，代码大概长这样：

class WorkerThread : public QThread { Q_OBJECT protected: void run() override { // 耗时操作 QThread::msleep(5000); emit resultReady("done"); } signals: void resultReady(const QString &result); };

然后在外层通过new一个WorkerThread、connect信号、调用start()来使用。这个方案的问题在于，很多人把“继承QThread”理解成了“在QThread里跑业务逻辑”，甚至把业务类的成员函数直接写在QThread子类里，导致业务逻辑和线程生命周期强耦合，项目一复杂就难以维护。

关于这个方案，Qt官方文档其实有过明确表态：继承QThread更合理的使用方式是把QThread当作线程控制器，而不是在线程里塞满业务。但官方归官方，现实里大量老项目就是这么写的，而且在小工具类项目里它确实够用。我的建议是：如果是自用的临时脚本、几十一百行的工具类程序，继承QThread没问题；但如果是正经项目，建议优先考虑后面几种方案。

2.2 moveToThread：官方推荐的业务与线程分离方案

moveToThread的核心思想是把一个普通的QObject对象“挪”到某个线程里，让对象的槽函数在自己所属线程里执行。这种方式下，业务代码不需要继承任何线程类，只关心自己的业务逻辑，线程生命周期由外部的QThread对象管理。

class Worker : public QObject { Q_OBJECT public slots: void doWork() { // 耗时操作，在Worker对象所属线程执行 QThread::msleep(3000); emit workFinished("finished"); } signals: void workFinished(const QString &msg); }; // 主线程中 QThread *thread = new QThread; Worker *worker = new Worker; worker->moveToThread(thread); connect(thread, &QThread::finished, worker, &QObject::deleteLater); connect(this, &MainWindow::startWork, worker, &Worker::doWork); connect(worker, &Worker::workFinished, this, &MainWindow::onWorkFinished); thread->start();

这个方案的关键理解点在于：当你用一个信号去触发worker的doWork槽函数时，连接方式如果是AutoConnection，跨线程就会自动转成QueuedConnection，槽函数的执行就会被投递到目标线程的事件循环里去执行。这相当于Qt帮你做了一个线程间的函数调用分发。

我强烈建议正式项目里优先走这条路，因为Worker可以独立测试、可以在不同线程间迁移、可以任意扩展信号槽接口，代码的清晰度和可维护性都比继承QThread高一个档次。

2.3 QtConcurrent：一句话开启异步任务的轻量方案

QtConcurrent适用于“我只需要跑一个耗时的函数，跑完把结果给我”的简单场景，不需要保留常驻线程时，这是四个方案里写起来最爽的。

#include <QtConcurrent/QtConcurrentRun> #include <QFutureWatcher> QFutureWatcher<QString> *watcher = new QFutureWatcher<QString>(this); connect(watcher, &QFutureWatcher<QString>::finished, this, [this, watcher](){ QString result = watcher->result(); ui->label->setText(result); watcher->deleteLater(); }); QFuture<QString> future = QtConcurrent::run([=]() -> QString { QThread::msleep(3000); return QStringLiteral("计算完成"); }); watcher->setFuture(future);

这里有个细节值得注意：QFutureWatcher必须在主线程里创建，它内部的finished信号会和主线程的事件循环自动关联，所以lambda里可以直接更新界面。如果你不想用lambda，也可以connect到一个普通的槽函数，只要保证槽函数在主线程里执行就行。

QtConcurrent底层走的是全局线程池，默认线程数等于CPU核心数，所以不要在里面跑死循环或者长期阻塞任务，否则会占满线程池影响其他任务。需要长期占用的任务，还是用moveToThread方案更合适。

2.4 QThreadPool配合QRunnable：面向大批量短任务的线程池方案

如果是“成千上万个短小的任务，每个任务耗时几百毫秒，希望并发执行又不想手动创建线程”，QThreadPool + QRunnable的组合是正解。QRunnable和QObject没有关系，不能直接使用信号槽，通常需要自己写一个继承QRunnable的类，并在里面持有结果回调。

class CaculateTask : public QRunnable { public: CaculateTask(int start, int end, std::function<void(int)> onFinished) : m_start(start), m_end(end), m_onFinished(onFinished) {} void run() override { int sum = 0; for (int i = m_start; i <= m_end; ++i) sum += i; if (m_onFinished) m_onFinished(sum); } private: int m_start, m_end; std::function<void(int)> m_onFinished; }; // 使用 QThreadPool::globalInstance()->start(new CaculateTask(1, 100000, [=](int result){ QMetaObject::invokeMethod(this, [=]() { ui->label->setText(QString::number(result)); }, Qt::QueuedConnection); }));

注意lambda里更新界面时用到了QMetaObject::invokeMethod配合Qt::QueuedConnection，这是因为QRunnable的run()是在线程池工作线程里执行的，不能直接操作UI，需要投递回主线程。这个细节特别容易踩坑，后面讲安全问题时会展开说。

2.5 一张表看清四种方案怎么选

3. 线程安全与信号槽机制深度拆解

3.1 为什么“跨线程更新UI”一定会出问题

很多初学者会写这样的代码：在子线程里直接调用ui->label->setText()，结果程序没崩，但界面偶尔闪烁、偶尔更新不及时，甚至过一段时间突然崩溃。原因在于Qt的UI类几乎都不是线程安全的，它们依赖主线程的事件循环来维护绘制状态。你在子线程里强行调用，就相当于两个人同时往一个杯子里倒水，可能洒出来，也可能杯子直接碎。

Qt的解决办法是信号槽的跨线程队列投递机制。发送方在某线程发出信号，如果接收方在另一个线程，且连接方式为AutoConnection，Qt会自动判断需要转成QueuedConnection，将调用事件投递到接收方所在线程的事件循环里排队执行。所以“更新UI”这个动作本身没有做错，错的是直接调用，正确的做法是让信号槽机制帮你把调用“投递”回主线程。

这里我再推荐一个硬核兜底方法：不论身处哪个线程、不管用什么框架，只要你想安全地调用主线程里的某个函数，都可以用QMetaObject::invokeMethod指定Qt::QueuedConnection。这个方法不依赖信号槽也能用，特别适合QRunnable这类没有信号能力的场景。

3.2 搞清楚AutoConnection与QueuedConnection的判定规则

连接方式的判定逻辑其实很简单：connect发生的时刻，QObject的thread()返回哪个线程，接收对象就归属于哪个线程。发送信号时，如果发送方所在线程和接收方所在线程不同，AutoConnection自动变成QueuedConnection；相同则是DirectConnection，槽函数在发送方线程里直接同步执行。

这个判定规则有一个常见误用场景：你把一个QObject对象通过moveToThread移动到工作线程后，又想在主线程里直接connect它的信号，此时如果接收方是主线程对象，连接是跨线程队列投递，没问题；但如果你忘了moveToThread，而对象其实是在主线程创建的，那么connect一个工作线程发出的信号到主线程对象的槽函数，也是队列投递，同样没问题。真正容易出错的是“两个对象都以为自己在同一线程”的模糊状态——一定要明确每个QObject所属的线程，这是线程安全的根基。

我遇到过一种顽固的偶发崩溃，排查到最后发现是有人在子线程的run()里new了一个QObject但没有moveToThread，接管了它的生命周期后，在主线程直接delete，导致事件循环还在处理这个对象的事件时对象已被销毁。这类问题用Qt自带的方式很难发现，所以我的经验是：所有在子线程创建的对象，要么绑定明确线程并统一销毁，要么干脆用new+deleteLater的模式让事件循环来收尾。

3.3 QMutex、QReadWriteLock与信号槽之外的原子操作

多线程数据共享时，QSignal没有帮你做任何数据同步，信号只是触发通知，具体数据还是需要通过共享内存、成员变量或者其它机制传递。Qt提供了QMutex和QMutexLocker做互斥锁，如果读多写少可以用QReadWriteLock提升并发度，如果是简单的整数标记或布尔值，用QAtomicInteger让CPU帮助你完成原子操作，省去加锁的开销。

// 用QMutexLocker保护成员变量 void DataBuffer::append(const QByteArray &data) { QMutexLocker locker(&m_mutex); m_buffer.append(data); } QByteArray DataBuffer::takeAll() { QMutexLocker locker(&m_mutex); QByteArray data = m_buffer; m_buffer.clear(); return data; }

这里有个值得养成的习惯：无论锁粒度大小，统一用QMutexLocker的RAII写法，绝不用手动lock/unlock。因为一旦代码逻辑中途异常、提前return，手动unlock很容易漏掉，死锁就随之而来。RAII方式会在作用域结束时自动解锁，这是C++里最优雅的保护方式。

4. 实操案例：串口采集+FFT频谱显示的完整多线程实现

4.1 需求描述与线程模型选型

为了把前面的知识串起来，我用一个实际项目来演示。需求是这样：通过串口接收传感器数据，每包数据512个字节，采样率10kHz，要求实时显示时域波形，并将最新一段数据做FFT转换显示频域波形，界面还要支持暂停/继续、清空显示。

这个需求如果全放主线程，串口每收一包数据就触发一次槽函数，槽函数里还要做FFT运算和重绘。FFT的运算量虽然不算夸张，但QCustomPlot的replot()是完整重绘，数据一密集必然卡顿。我选择的方案是：

• 串口对象放在主线程，收到数据的信号直接连接到主线程的一个槽函数。
• 槽函数里不处理、不绘制，只把原始数据追加到DataBuffer共享缓冲区，然后发出一个DataReady信号。
• 主线程里再启动一个QThread，里面放一个Worker对象，专门负责从DataBuffer中取出数据进行FFT计算，得到频谱数据后通过信号把结果传回主线程。
• 主线程收到频谱结果后只做一件事：更新QCustomPlot曲线。

整个模型里，数据流向是“串口→主线程缓冲区→工作线程FFT→主线程绘图”，工作线程不碰任何UI，主线程也不做耗时计算，两边各司其职。

4.2 关键代码实现与注释

串口接收部分的示意代码：

// MainWindow构造函数中 m_buffer = new DataBuffer(this); m_worker = new Worker(m_buffer); m_workerThread = new QThread(this); m_worker->moveToThread(m_workerThread); connect(serial, &QSerialPort::readyRead, this, &MainWindow::onSerialReadyRead); connect(this, &MainWindow::startProcessing, m_worker, &Worker::start); connect(m_worker, &Worker::spectrumReady, this, &MainWindow::onSpectrumReady); m_workerThread->start(); void MainWindow::onSerialReadyRead() { QByteArray data = serial->readAll(); m_buffer->append(data); emit startProcessing(); // 触发worker处理 } void MainWindow::onSpectrumReady(const QVector<double> &freqs, const QVector<double> &amplitudes) { // 到这里一定在主线程，可以直接操作UI ui->plot->graph(0)->setData(freqs, amplitudes); ui->plot->replot(); }

Worker部分的实现：

Worker::Worker(DataBuffer *buffer) : m_buffer(buffer), m_running(false) {} void Worker::start() { if (m_running) return; m_running = true; QByteArray data = m_buffer->takeAll(); // 省略具体数据解析与FFT运算，假设得到频率和幅度数组 QVector<double> freqs = doFFT(data); QVector<double> amps = computeAmplitudes(data); emit spectrumReady(freqs, amps); m_running = false; }

这里有三个要点：

第一，startProcessing这个信号和Worker::start槽的连接，因为Worker被moveToThread到了工作线程，所以信号投递到工作线程的事件循环中执行。如果Worker被连续触发多次，start槽函数也只会被一个个排队执行，不会并发执行，天然避免了race condition。

第二，串口数据是字节流，不一定每包都恰好是512字节，所以Worker里需要做粘包处理，把缓冲区里的数据按帧切割，不足一帧的先暂存，这个逻辑在DataBuffer类内部完成。我在DataBuffer里维护了一个QByteArray m_cache，takeAll()的时候先把缓存拼上最新数据再切割，多余的留在缓存里。

第三，m_running布尔值我这里用了普通成员变量，严格意义上跨线程读写还不够安全，但这里够用——因为start槽函数本身在工作线程串行执行，主线程只负责发信号，不会同时去写m_running。如果以后改成能并发调用的场景，需要换成QAtomicInteger或者加锁。

4.3 QCustomPlot时域转频域的联动与性能优化

时域转频域这部分推荐用KISSFFT这个小巧的FFT库，相比FFTW，它体积小、无依赖、集成简单，MIT协议商用友好。用qmake的话只需要把它添加进工程编译即可。

要把时域曲线在QCustomPlot上同时显示，常见的做法是分别创建两个graph，一个显示时域数据，一个显示频域数据，或者把QCustomPlot放在两个不同的控件中。考虑到实时刷新性能，我建议时域图的graph数据只保留最近1000个点，频域图输出256个点的幅度谱。

const int FFT_POINTS = 256; kiss_fft_cfg cfg = kiss_fft_alloc(FFT_POINTS, 0); // 填充时域采样数据到kiss_fft_cpx数组，注意可能要加窗函数减少频谱泄漏 kiss_fft(cfg, fft_in, fft_out); // 计算幅度：sqrt(re*re + im*im)，去除直流分量和对称部分后取前N/2个点

操作频率上，QCustomPlot的replot()如果每秒被调用太多次会非常吃CPU。我实际测试下来，10kHz采样率、每秒产生20包数据的情况下，每秒调用replot约20次是可以接受的；但如果把数据包加大到512点、每秒50包，就建议做一个简单的节流：比如设定一个定时器，每100ms重绘一次，期间把多包数据累积到一个缓冲再一次性setData，这样界面会流畅很多。

4.4 线程退出与程序关闭的完整处理

这个环节是很多项目的重灾区：关闭程序时线程没有及时退出，程序挂起几秒甚至直接crash。核心原则是：先停业务，再退线程，最后删对象。

MainWindow::~MainWindow() { // 1. 停止worker，让run循环退出（如果有while循环） m_worker->stop(); // 2. 退出事件循环 m_workerThread->quit(); // 3. 等待线程真正结束 m_workerThread->wait(); // 4. 线程结束后，worker会被deleteLater自动回收 }

如果你的Worker内部有while循环或者阻塞事件，需要加一个volatile风格的停止标记，在start()循环里定期检查。注意stop()这个槽是投递到工作线程执行的，必须放在quit()之前，否则事件还没执行事件循环就退了。

还有一个细节：connect(m_workerThread, &QThread::finished, m_worker, &QObject::deleteLater)这个连接要确保存在，否则worker对象会内存泄漏或出现二次销毁问题。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

5.2 定位多线程Bug的实用手段

多线程bug是最难复现也最难定位的类型。我建议从这几个角度入手：

第一，在槽函数开头和结尾加qDebug() << QThread::currentThreadId()，确认执行的线程符合预期。很多莫名其妙的bug，查到最后是槽函数执行在错误的线程里。

第二，打开Qt的警告输出。在main()里加上qSetMessagePattern，并把环境变量QT_FATAL_WARNINGS设为1，可以让QObject的线程警告直接暴露。很多线程模型错误在运行时其实会有warning输出，只是默认被淹没了。

第三，如果你的崩溃是偶发的，试试编译成Debug版，用AddressSanitizer（ASan）跑一遍。Qt项目在CMake里加一行set(CMAKE_CXX_FLAGS "-fsanitize=address -fno-omit-frame-pointer")就能启用，它会帮你精准定位内存越界、double free这类问题。

5.3 多线程面试高频考点与项目谈法

这部分给正在准备面试的朋友参考。面试官问“你项目里怎么用多线程的”，你不光要说用了QThread，还要能说清楚为什么选它、线程之间怎么通信、怎么保证安全退出。我这边常被问到的点有：

• 信号槽的AutoConnection、QueuedConnection、DirectConnection区别，以及实际项目中哪些场景被迫用过QueuedConnection。
• moveToThread和继承QThread的本质区别，为什么Qt官方更推荐moveToThread。
• 多个线程同时访问一个共享容器会出什么问题，怎么解决（答QMutex不够，要能说出锁粒度、死锁、原子操作）。
• 你项目的线程模型画出来是什么样的，谁在往工作线程投递任务，结果谁接收。
• 如果你用的是线程池，请说明线程池大小怎么确定，为什么不直接new很多线程。

把上面的案例代码吃透，这些问题都能展开得很好。重点不在于背答案，而在于真的亲手调过、踩过坑，能讲出细节。

6. 打包发布时与多线程相关的隐藏坑

6.1 windeployqt打出来的程序为什么换个机器就崩

windeployqt是Qt官方提供的部署工具，它会自动拷贝依赖的DLL和插件。但因为它只会根据可执行文件导入表扫描依赖，如果可执行文件本身没有直接引用到Qt模块，而你的业务代码用到了，就可能导致DLL缺失。如果项目里用了多线程相关的模块，如QtConcurrent，需要在.pro里有QT += concurrent，否则相关DLL不会被部署进去。

另外，如果程序在开发机上正常运行，但通过windeployqt打包后运行时提示“no qt platform plugin could be initialized”，那说明Qt平台插件没被正确找到。这个问题解决方法是确保platforms文件夹里包含qwindows.dll且和主程序在同一级目录，同时环境变量QT_QPA_PLATFORM_PLUGIN_PATH有指向platforms目录。打包时windeployqt通常会自动处理，但如果你手动精简过目录就很容易踩坑。

6.2 发布程序的多线程调试与日志策略

发布版本遇到多线程crash时，最有效的排查手段是日志。我强烈建议在程序里加一个日志系统，用qInstallMessageHandler将qDebug的输出重定向到文件，同时记录每条日志的时间戳和线程ID。这样用户反馈“程序崩了”的时候，你拿日志一看，就知道崩的时候哪些线程还在活跃、哪条日志之后没有后续，往往能直接定位到问题点。

日志系统也要注意线程安全，多个工作线程同时输出日志时，要用QMutex保护写文件操作，否则日志可能交错、错乱甚至少行。这个点经常被忽略，但对线上排查的帮助极大。

提示：正式发布时，建议把qDebug输出级别单独控制，避免日志文件被调试信息灌爆，同时保留有效信息。我一般用QtFatalMsg、QtCriticalMsg、QtWarningMsg记录错误信息，QtInfoMsg记录关键节点状态，QtDebugMsg在发布版默认关闭。

6.3 麒麟x86等国产平台的Qt多线程特殊适配

相关热搜词里出现了qt离线安装 麒麟x86、麒麟系统安装qt，说明不少人在做国产化适配工作。麒麟系统上的Qt多线程开发，和Windows相比有几个值得注意的差异：

一是线程调度策略不同。麒麟的Linux内核默认CFS调度器，一个忙碌的线程不会像Windows那样被快速抢占，所以如果在工作线程里写了while(1)形式的高占用循环，对界面响应的影响可能会更明显。解决方案是让工作线程适当地休眠，比如每处理完一批数据QThread::msleep(1)，或者在循环里等待条件变量。

二是QThread::wait()的行为在Linux上受信号影响。个别情况下会出现wait()长时间不退出的现象，多见于底层库阻塞了系统调用。解决办法是在等待前先调用requestInterruption()或设置退出标记，并且避免在子线程里调用第三方阻塞库。

三是打包问题。麒麟系统上Qt经常需要离线安装GCC和Qt库，windeployqt在Linux平台上依赖ldd扫描依赖。如果目标机器和开发机的库路径不同，很可能会出现“依赖库找不到”的运行时错误。解决方案是用linuxdeployqt工具，配合自己构建的AppImage或复制到固定目录，并设置LD_LIBRARY_PATH。

这些点不算Qt多线程的核心内容，但如果你真的部署到国产环境，视野提前打开能省不少事。

7. 多线程项目里的线程生命周期管理心得

7.1 谁创建谁负责销毁的边界意识

多线程程序写多了，最大的体会是“线程生命周期”的设计比算法本身更重要。很多崩溃根源不是你代码写错了，而是对象的创建线程、所在线程、销毁线程没有统一规划，最终在某个时间点上出现了“交叉使用已销毁对象”或“跨线程delete”的情况。

我的设计原则是：每一个QObject子类都要明确回答三个问题——它在哪里被创建、moveToThread到哪个线程、最终谁负责销毁。把这三个问题的答案注释在类头部或者构造函数旁边，后续维护代码的人一眼就能看懂。新添加的connect语句也要反复确认“这个信号是在哪个线程发射的、槽函数会在哪个线程执行”。

另一个实用的技巧是尽量少用全局指针传递跨线程对象，如果确实需要，最好用线程安全的单例模式，内部用QMutex保护初始化，避免懒加载时出现双重初始化。

7.2 贯穿项目的线程安全检查清单

我自己在项目评审时通常会过一遍下面这个清单，每次都能揪出问题：

• 明确标注每个QObject所属线程，不依赖“应该”这种猜测。
• 是否使用了跨线程直接调用函数，是的话改成信号槽或invokeMethod。
• 槽函数里是否有阻塞操作，有的话是否可以拆分任务或放入线程池。
• 是否所有共享数据都有锁保护，读取方是否也加了锁（只写不加锁也不行）。
• 事件循环什么时候退出，线程是否等待结束，超时时间设多少。
• 析构函数是否按“停业务→退出事件循环→wait→deleteLater”的顺序执行。
• 是否在非主线程里调用了UI方法，用grep搜一遍代码确认没有。
• 是否有new出来的QObject在主线程以外的位置被delete。

这个清单由简入繁，覆盖了从单一QThread到线程池再到跨线程对象传递的各类场景。每次写完多线程代码，我都会按这个清单自查一遍，这几年帮我挡掉了不少线上事故。

多线程这个话题，说起来是几个类、几个函数，真正做好其实是“从设计到实现再到部署”的整套工程能力。希望这篇内容不是又多看了一篇教程，而是你真的能带着里面的方法，回去改进手上的项目——从把耗时操作从主线程里迁出来开始，哪怕只优化了串口接收那一块，界面流畅度的提升都会非常明显。

本文还有配套的精品资源，点击获取