简介一份演示在MFC中为线程自定义消息循环的完整示例工程适合具备基础MFC使用经验、希望深入理解Windows消息机制与多线程开发的读者。工程围绕CWinThread派生线程类展开覆盖InitInstance初始化、Run方法内GetMessage/TranslateMessage/DispatchMessage消息循环编写、线程退出清理以及PostThreadMessage线程间通信等关键点可帮助开发者快速掌握让工作线程响应UI或自定义消息的实现路径。包内共19个文件以.h头文件、.cpp源文件、.rc资源定义、.vcxproj工程文件及.ico图标等为主压缩包仅154KB结构简洁便于直接打开工程对照学习。已有874人学习下载内含可直接编译运行的MFC程序框架代码注释与工程配置完整适合作为编写线程消息循环的参考模板也可在此基础上扩展消息类型加深对MFC消息循环机制的理解。 做MFC界面开发绕不开两个东西消息循环和线程。标题里这个“MFC线程自定义消息循环”说白了就是解决一个很现实的问题当你的工作线程需要接收外部指令、需要把处理进度回传给界面、或者线程内部根本就是一个需要事件驱动的常驻任务时光靠全局标志加Sleep轮询是行不通的。程序照样能跑但后面你会慢慢被各种关窗崩溃、状态刷新不及时、退出卡死折磨到怀疑人生。这篇文章我会从原理讲到代码再讲到我实际排过的坑。适合正在做MFC开发、被后台线程和UI通信搞到头大的人也适合刚接触MFC消息机制、想系统理清这套东西的C开发者。看完你可以直接照着写一个能用的线程消息循环出来。1. MFC消息循环与线程的关系1.1 消息循环到底在转什么消息循环本质上就是一个取消息、翻译消息、分发消息的while循环。你可以把它理解成一个前台接待员窗口是工位消息是来访客户客户到了前台接待员按顺序喊号喊到谁谁就处理自己的事。MFC的主线程不用你操心CWinApp::Run()在程序启动后就开始维护主消息循环。主窗口上的鼠标点击、键盘输入、WM_TIMER、界面重绘全部都是通过这个循环一条条分发出去的。这也是为什么你写MFC的时候基本不需要手动管消息框架帮你转完了。但工作线程不一样。你用AfxBeginThread创建出来的线程默认就是一条纯执行代码的裸线程跑完函数就结束中间没有消息队列、没有消息循环外部也没办法通过PostMessage给它发指令。这时候你如果想让线程在跑任务的同时还能响应“暂停”“停止”“改参数”之类的指令就需要手动给它造一个消息循环。1.2 哪些场景必须给线程配消息循环不是所有线程都需要消息循环。如果线程只是闷头算数据、写文件、查数据库做完了就退出那不需要但下面这几类情况你最好认真考虑给它配一个常驻后台线程需要接收主界面随时下发的控制指令比如开始、停止、切换模式线程内部创建了窗口或控件这些窗口必须维护自己的消息循环才能正常显示和响应消息线程间通信希望走消息机制比裸共享变量更安全有序线程要驱动定时刷新比如MFC里做OpenGL渲染循环、基于绘制的动画需要在WM_TIMER或自定义刷新消息里不断重绘。我在实际项目里见过不少人为了省事在线程里写一个while(!stopFlag) { Sleep(200); ... }然后主线程处理关窗时去置标志位。表面看工作正常但线程可能正阻塞在某个耗时的调用上标志位没机会被检查到最后导致窗口关了线程还在跑程序退出时偶发崩溃。消息循环的好处是它给了外部一个标准化的指令入口而且Windows的消息队列天然带排队和等待能力你不需要自己拿锁去保护指令状态。1.3 UI线程与工作线程的边界MFC里有一个很关键的概念谁创建了窗口谁就是UI线程。UI线程必须要有消息循环否则窗口不会响应任何操作。反过来工作线程如果没创建窗口正常情况下系统不会给它安排消息队列但这不代表它永远不能有。Windows的实现是线程的“消息队列”是按需创建的。一个普通线程第一次调用GetMessage、PeekMessage这类user32消息函数时系统才为它创建队列。所以在线程里搞自定义消息循环第一件事就是确保队列存在后面我会具体讲代码写法。还要注意MFC界面对象基本都不是线程安全的。工作线程里不要直接操作CWnd派生对象的方法更不要跨线程操作CListCtrl、CEdit之类的控件。正确的姿势是把数据封装好通过消息传给主线程让主线程的界面代码去更新控件。这也是线程消息循环最常见的用途之一。2. 自定义消息的设计编号、处理函数与映射2.1 消息编号别乱用WM_USER、WM_APP和安全区在MFC里定义自定义消息第一个动作就是选编号。很多人直接写#define WM_MY_THREAD_MSG WM_USER 100这在早期控件自定义消息里很常见但不代表所有场景都合适。WM_USER是0x0400它是微软给控件类预留的私有消息区间。你随便用一个控件控件内部就有一大堆WM_USER N的消息和通知。如果你的自定义消息编号恰好和某个控件的内部消息撞了轻则消息行为怪异重则整个控件状态错乱。所以除非消息只在你自己的类内部使用且你能保证不冲突否则尽量别用它。更保险的区间是WM_APP0x8000到0xBFFF这是微软明确留给应用程序自定义消息使用的。线程之间通信、程序内部各模块之间通信的消息号统一从这个区间起撞车概率小很多。习惯上我喜欢这样定义#define WM_MY_THREAD_MSG (WM_APP 100) // 线程命令消息 #define WM_MY_THREAD_PROGRESS (WM_APP 101) // 线程进度回传 #define WM_MY_THREAD_QUIT (WM_APP 102) // 线程退出消息2.2 处理函数与ON_MESSAGE映射在MFC类中使用ON_MESSAGE消息映射处理函数的签名必须是固定的格式afx_msg LRESULT OnThreadMsg(WPARAM wParam, LPARAM lParam);wParam和lParam是两个通用参数具体含义由你自己定。我通常用wParam传递指令编号或进度百分比用lParam传递指针或者自定义结构体地址。映射宏写进消息映射表里就行BEGIN_MESSAGE_MAP(CMyThread, CWinThread) ON_MESSAGE(WM_MY_THREAD_MSG, CMyThread::OnThreadMsg) END_MESSAGE_MAP()需要提醒的是CWinThread的消息映射处理的是“线程消息”也就是通过PostThreadMessage发过来、hwnd为NULL的消息。这一点和窗口消息的分发路径不一样细节我在第3章代码里会展开。2.3 线程消息队列是“用的时候才创建”这个我前面提了一句这里必须展开。Windows给线程创建消息队列是懒加载机制第一次调用GetMessage、PeekMessage等函数时才创建。如果目标线程还没进入消息循环你就从外部调用PostThreadMessage去投递可能得到的是失败返回码消息压根送不进去。所以一个标准动作是在线程入口函数最开始强制创建队列MSG msg; PeekMessage(msg, NULL, 0, 0, PM_NOREMOVE);这行代码不取出任何消息只负责触发系统为当前线程创建消息队列。这之后你再往里PostThreadMessage就能稳定投递。我见过有人不写这句然后偶尔复现“消息丢失”“第一次发不进去”的诡异问题基本都是这个原因。3. 线程自定义消息循环的两种实现3.1 方案一纯GetMessage循环自己分发这种最贴合“自定义消息循环”的字面意思线程函数里自己写循环自己决定怎么处理消息。伪代码结构如下UINT WorkThreadProc(LPVOID pParam) { // 强制创建消息队列 MSG msg; PeekMessage(msg, NULL, 0, 0, PM_NOREMOVE); // 进入消息循环 while (GetMessage(msg, NULL, 0, 0)) { // 先判断是不是自定义指令 if (msg.message WM_MY_THREAD_MSG) { // 按需处理 OnThreadCommand(msg.wParam, msg.lParam); } else if (msg.message WM_MY_THREAD_QUIT) { // 做清理工作然后退出 DoCleanup(); break; } else { TranslateMessage(msg); DispatchMessage(msg); } } return 0; }虽然是连窗口句柄都没有的线程DispatchMessage不会分发到任何窗口过程但保留标准的TranslateMessage和DispatchMessage调用并没有坏处因为这类线程里如果谁又创建了隐藏窗口这套调用就能无缝衔接。这里再强调一个关键点如果你用GetMessage循环WM_QUIT消息会让GetMessage返回0从而退出循环。所以在线程里想优雅退出最标准的做法是先发自定义退出消息做清理清理完再PostThreadMessage(GetCurrentThreadId(), WM_QUIT, 0, 0)。WM_QUIT本身不会出现在上面分支里它直接让GetMessage返回0。3.2 方案二CWinThread派生类收编进MFC消息映射如果项目本身就重度使用MFC我更推荐派生一个CWinThread子类把线程消息循环收编进MFC自己的消息泵机制。// MyThread.h class CMyThread : public CWinThread { DECLARE_DYNCREATE(CMyThread) public: BOOL InitInstance() override; int ExitInstance() override; afx_msg LRESULT OnThreadCommand(WPARAM wParam, LPARAM lParam); afx_msg LRESULT OnThreadQuit(WPARAM wParam, LPARAM lParam); DECLARE_MESSAGE_MAP() HWND m_hMainWnd; // 主窗口句柄用于回传 BOOL m_bRunning; }; // MyThread.cpp IMPLEMENT_DYNCREATE(CMyThread, CWinThread) BEGIN_MESSAGE_MAP(CMyThread, CWinThread) ON_MESSAGE(WM_MY_THREAD_MSG, CMyThread::OnThreadCommand) ON_MESSAGE(WM_MY_THREAD_QUIT, CMyThread::OnThreadQuit) END_MESSAGE_MAP() BOOL CMyThread::InitInstance() { // 和线程函数一样先强制创建消息队列 MSG msg; PeekMessage(msg, NULL, 0, 0, PM_NOREMOVE); m_bRunning TRUE; return TRUE; // 返回TRUE进入消息循环 } int CMyThread::ExitInstance() { m_bRunning FALSE; return CWinThread::ExitInstance(); } LRESULT CMyThread::OnThreadCommand(WPARAM wParam, LPARAM lParam) { // 收到主线程的消息后在这里干活 // 比如 wParam 1 表示开始2 表示停止 return 0; } LRESULT CMyThread::OnThreadQuit(WPARAM, LPARAM) { // 清理资源 m_bRunning FALSE; // 发WM_QUIT退出Run()内部的消息循环 PostThreadMessage(GetCurrentThreadId(), WM_QUIT, 0, 0); return 0; }在业务侧创建线程要用AfxBeginThread的RUNTIME_CLASS版本CMyThread* pThread (CMyThread*)AfxBeginThread(RUNTIME_CLASS(CMyThread)); pThread-m_hMainWnd GetSafeHwnd(); DWORD dwThreadId pThread-m_nThreadID;这里有个细节不是让你重写Run()。CWinThread::Run()内部已经实现了消息泵并且在出消息时会检查hwnd是否为NULL。对于PostThreadMessage发来的、没有窗口句柄的消息MFC会把它们路由到CWinThread的消息映射表所以ON_MESSAGE才能处理到。如果你自己重写Run()但又想继续用ON_MESSAGE就得自己处理这条路由逻辑等于把MFC内部机制重造一遍没必要。3.3 两种方案怎么选简单总结一下纯GetMessage循环写法直观、可控性强、不依赖MFC类体系适合要在线程里塞大量自定义逻辑或者不想引入CWinThread派生类的场景CWinThread派生类代码干净、有标准消息映射适合线程本身就像一个小型对象、需要封装成员变量和业务方法的场景。我自己的判断标准是线程逻辑超过50行我就用CWinThread派生类只是临时后台干个活需要接收两三条指令用线程函数加GetMessage循环就够了。4. 线程通信、回传与退出收尾4.1 主线程往工作线程发指令消息循环跑起来之后主线程往工作线程发指令用PostThreadMessage::PostThreadMessage(dwThreadId, WM_MY_THREAD_MSG, (WPARAM)CMD_START, 0); ::PostThreadMessage(dwThreadId, WM_MY_THREAD_MSG, (WPARAM)CMD_STOP, 0); ::PostThreadMessage(dwThreadId, WM_MY_THREAD_QUIT, 0, 0);使用PostThreadMessage时注意目标线程ID要用正确的dwThreadId。如果你保存的是CWinThread*指针记得这个指针在线程退出后不一定还有效但m_nThreadID这个DWORD值是安全的你可以在线程创建后立刻保存下来。另外一个常被忽略的点是消息投递顺序。PostThreadMessage的数据进入目标线程的消息队列后是按FIFO顺序处理的。所以即使主线程连发多条指令目标线程也会依次处理不会出现“还没初始化完就收到停止指令”这种乱序。这一点比共享变量加标志位的方案靠谱得多。4.2 工作线程给主窗口回传进度与结果工作线程有一个m_hMainWnd句柄回传进度时直接构造一个用户消息PostMessage到主窗口// 工作线程内 ::PostMessage(m_hMainWnd, WM_MY_THREAD_PROGRESS, (WPARAM)percent, 0);主窗口那边照常加ON_MESSAGE映射。这样做的最大好处是更新控件的代码始终在主线程执行完全规避了跨线程操作MFC控件的问题。这里我建议一个克制原则工作线程里不要高频往主窗口发消息。比如你在一个循环里每1毫秒发一次进度主窗口的消息队列会被刷爆界面卡顿、刷新闪烁都来了。更稳的写法是在线程内部做个限频比如每100毫秒或者进度变化超过1%才发一次。UI上100毫秒一次的进度刷新用户看着已经很流畅了。4.3 线程退出WM_QUIT、自定义退出和等待句柄线程退出有几种处理情况如果是业务任务自然结束你希望线程退出去那在线程内部发一个WM_QUIT就行。WM_QUIT会让GetMessage返回0消息循环自然结束线程函数返回。但更常见的是主线程主动关停子线程。我的做法是先发WM_MY_THREAD_QUIT让线程有机会把自己手里的资源清掉然后在处理函数末尾再发一个WM_QUIT。这样线程能确定性地退出而不是被一刀砍死。等待子线程退出时很多人直接写WaitForSingleObject(pThread-m_hThread, INFINITE);这条代码在大多数场景下没问题但如果子线程在退出前要向主窗口发消息而主线程此时正在卡着等待就会出问题。后面第5章我会专门讲这个死锁场景这里先说结论如果子线程可能往主线程窗口发送消息就不要用无限等待来阻塞主线程要么等一个有限超时要么用MsgWaitForMultipleObjects在等待期间继续泵消息。另外在主窗口关闭时一定要先停掉所有后台线程再让主线程退出。我在项目中见过太多次因为主窗口销毁、子线程还拿着主窗口句柄发消息导致的崩溃都是收尾顺序没控制好。5. 常见问题与排查技巧5.1 消息不响应先查这三个地方遇到消息发过去石沉大海我最先检查这三处现象可能原因处理方式PostThreadMessage返回0GetLastError显示无效线程ID线程还没创建完成或线程已经退出先确保线程启动成功并保存了正确的m_nThreadID线程退出后就别再投递消息发成功了但线程没反应目标线程没有消息循环或还没进入循环线程入口首先PeekMessage强制创建队列等线程进入循环后再发指令CWinThread的ON_MESSAGE没触发重写了Run()丢掉了MFC对NULL窗口消息的特殊路由别重写Run()用基类默认消息泵或者换用纯GetMessage方案手动分发尤其是最后一种我见过有人把CWinThread::Run()整个重写成一个空循环然后到处找为什么ON_MESSAGE收不到消息。其实MFC里线程消息能走消息映射靠的正是基类Run()内部对hwnd NULL消息做的特殊处理。你一旦绕过基类这个机制自然就失效了。5.2 消息循环被长任务卡住怎么办这个问题很隐蔽。你以为是消息循环在正常工作实际上某一次收到指令后消息处理函数里写了一个耗时的for循环结果整个线程的消息泵被堵住了后续指令全部排队等待。想避免这种情况有三种思路第一种是让业务任务分片执行。每次消息处理只做一小步做完后发一条同样的消息给自己相当于用消息循环驱动一个状态机。这样消息泵永远有空闲时间处理新指令。第二种是把业务循环里插入消息泵检出的动作while (m_bRunning) { // 非阻塞地处理当前队列里的消息 while (PeekMessage(msg, NULL, 0, 0, PM_REMOVE)) { TranslateMessage(msg); DispatchMessage(msg); } // 做一小块实际工作 DoSingleStep(); }第三种是干脆把耗时工作拆到另一个更底层的线程队列里不要让耗时操作占用带消息循环的线程。这个属于架构层面的取舍看项目复杂度决定。5.3 死锁等待子线程时的经典陷阱这是线程消息循环项目里最经典的死锁场景主线程在某按钮响应里执行WaitForSingleObject(hThread, INFINITE)等待子线程结束。子线程在退出前调用SendMessage(hMainWnd, WM_MY_THREAD_PROGRESS, ...)打算把最后结果同步交给主窗口。结果主窗口压根处理不了这个消息因为主线程已经阻塞在等待函数里了。SendMessage又是个同步调用会一直等到目标窗口处理完才返回。两边互相等程序卡死。解决办法有几个把子线程的SendMessage改成PostMessage发完就返回不等待主线程处理在等待子线程退出期间用MsgWaitForMultipleObjects替代WaitForSingleObject同时泵主线程的消息队列调整设计让主线程先发退出指令给子线程然后立刻返回等WM_DESTROY或自定义通知消息再统一收尾。我个人的建议是线程间通信能走PostMessage就不走SendMessage。PostMessage投递后立刻返回不会有持有锁等待的问题。真正需要等待结果的场景用一个一次性事件对象CEvent来控制更清晰。5.4 消息处理函数里的线程安全还有一个容易忽略的点是消息处理函数在子线程上下文执行里面访问的成员变量如果同时被主线程或别的线程读写仍然需要加锁。比如前面CMyThread里的m_bRunning如果只是消息处理函数自己写、自己读问题不大但如果你在主线程里也直接读取这个变量判断线程是否活着那就是跨线程访问了。稳妥做法是用volatile加原子操作或者干脆用CWinThread的m_bRunning辅助判定再配合线程句柄的等待结果来判断不要裸读成员变量。共享数据量大的话用CCriticalSection或者CSingleLock保护临界区。注意临界区锁的范围越小越好千万不能在持锁状态下调用PostMessage去等对方处理否则又绕回死锁。最后再分享一点个人体会。我早期做MFC后台线程时习惯用全局标志加Sleep轮询代码写起来似乎简单但一旦涉及界面退出、任务取消、异常中断标志位方案就开始漏洞百出。后来全线切到线程自定义消息循环把一切外部指令都消息化代码结构反而更清爽指令是有序的、可追溯的。如果你正在为MFC线程间通信发愁建议直接按这篇文章的思路搭一套消息循环的骨架后面再往里填业务踩坑概率会小很多。本文还有配套的精品资源点击获取 
长河君 · 2026/9/8 7:53:44 · 阅读 1.2k MFC线程自定义消息循环：从原理到代码实战
简介一份演示在MFC中为线程自定义消息循环的完整示例工程适合具备基础MFC使用经验、希望深入理解Windows消息机制与多线程开发的读者。工程围绕CWinThread派生线程类展开覆盖InitInstance初始化、Run方法内GetMessage/TranslateMessage/DispatchMessage消息循环编写、线程退出清理以及PostThreadMessage线程间通信等关键点可帮助开发者快速掌握让工作线程响应UI或自定义消息的实现路径。包内共19个文件以.h头文件、.cpp源文件、.rc资源定义、.vcxproj工程文件及.ico图标等为主压缩包仅154KB结构简洁便于直接打开工程对照学习。已有874人学习下载内含可直接编译运行的MFC程序框架代码注释与工程配置完整适合作为编写线程消息循环的参考模板也可在此基础上扩展消息类型加深对MFC消息循环机制的理解。 做MFC界面开发绕不开两个东西消息循环和线程。标题里这个“MFC线程自定义消息循环”说白了就是解决一个很现实的问题当你的工作线程需要接收外部指令、需要把处理进度回传给界面、或者线程内部根本就是一个需要事件驱动的常驻任务时光靠全局标志加Sleep轮询是行不通的。程序照样能跑但后面你会慢慢被各种关窗崩溃、状态刷新不及时、退出卡死折磨到怀疑人生。这篇文章我会从原理讲到代码再讲到我实际排过的坑。适合正在做MFC开发、被后台线程和UI通信搞到头大的人也适合刚接触MFC消息机制、想系统理清这套东西的C开发者。看完你可以直接照着写一个能用的线程消息循环出来。1. MFC消息循环与线程的关系1.1 消息循环到底在转什么消息循环本质上就是一个取消息、翻译消息、分发消息的while循环。你可以把它理解成一个前台接待员窗口是工位消息是来访客户客户到了前台接待员按顺序喊号喊到谁谁就处理自己的事。MFC的主线程不用你操心CWinApp::Run()在程序启动后就开始维护主消息循环。主窗口上的鼠标点击、键盘输入、WM_TIMER、界面重绘全部都是通过这个循环一条条分发出去的。这也是为什么你写MFC的时候基本不需要手动管消息框架帮你转完了。但工作线程不一样。你用AfxBeginThread创建出来的线程默认就是一条纯执行代码的裸线程跑完函数就结束中间没有消息队列、没有消息循环外部也没办法通过PostMessage给它发指令。这时候你如果想让线程在跑任务的同时还能响应“暂停”“停止”“改参数”之类的指令就需要手动给它造一个消息循环。1.2 哪些场景必须给线程配消息循环不是所有线程都需要消息循环。如果线程只是闷头算数据、写文件、查数据库做完了就退出那不需要但下面这几类情况你最好认真考虑给它配一个常驻后台线程需要接收主界面随时下发的控制指令比如开始、停止、切换模式线程内部创建了窗口或控件这些窗口必须维护自己的消息循环才能正常显示和响应消息线程间通信希望走消息机制比裸共享变量更安全有序线程要驱动定时刷新比如MFC里做OpenGL渲染循环、基于绘制的动画需要在WM_TIMER或自定义刷新消息里不断重绘。我在实际项目里见过不少人为了省事在线程里写一个while(!stopFlag) { Sleep(200); ... }然后主线程处理关窗时去置标志位。表面看工作正常但线程可能正阻塞在某个耗时的调用上标志位没机会被检查到最后导致窗口关了线程还在跑程序退出时偶发崩溃。消息循环的好处是它给了外部一个标准化的指令入口而且Windows的消息队列天然带排队和等待能力你不需要自己拿锁去保护指令状态。1.3 UI线程与工作线程的边界MFC里有一个很关键的概念谁创建了窗口谁就是UI线程。UI线程必须要有消息循环否则窗口不会响应任何操作。反过来工作线程如果没创建窗口正常情况下系统不会给它安排消息队列但这不代表它永远不能有。Windows的实现是线程的“消息队列”是按需创建的。一个普通线程第一次调用GetMessage、PeekMessage这类user32消息函数时系统才为它创建队列。所以在线程里搞自定义消息循环第一件事就是确保队列存在后面我会具体讲代码写法。还要注意MFC界面对象基本都不是线程安全的。工作线程里不要直接操作CWnd派生对象的方法更不要跨线程操作CListCtrl、CEdit之类的控件。正确的姿势是把数据封装好通过消息传给主线程让主线程的界面代码去更新控件。这也是线程消息循环最常见的用途之一。2. 自定义消息的设计编号、处理函数与映射2.1 消息编号别乱用WM_USER、WM_APP和安全区在MFC里定义自定义消息第一个动作就是选编号。很多人直接写#define WM_MY_THREAD_MSG WM_USER 100这在早期控件自定义消息里很常见但不代表所有场景都合适。WM_USER是0x0400它是微软给控件类预留的私有消息区间。你随便用一个控件控件内部就有一大堆WM_USER N的消息和通知。如果你的自定义消息编号恰好和某个控件的内部消息撞了轻则消息行为怪异重则整个控件状态错乱。所以除非消息只在你自己的类内部使用且你能保证不冲突否则尽量别用它。更保险的区间是WM_APP0x8000到0xBFFF这是微软明确留给应用程序自定义消息使用的。线程之间通信、程序内部各模块之间通信的消息号统一从这个区间起撞车概率小很多。习惯上我喜欢这样定义#define WM_MY_THREAD_MSG (WM_APP 100) // 线程命令消息 #define WM_MY_THREAD_PROGRESS (WM_APP 101) // 线程进度回传 #define WM_MY_THREAD_QUIT (WM_APP 102) // 线程退出消息2.2 处理函数与ON_MESSAGE映射在MFC类中使用ON_MESSAGE消息映射处理函数的签名必须是固定的格式afx_msg LRESULT OnThreadMsg(WPARAM wParam, LPARAM lParam);wParam和lParam是两个通用参数具体含义由你自己定。我通常用wParam传递指令编号或进度百分比用lParam传递指针或者自定义结构体地址。映射宏写进消息映射表里就行BEGIN_MESSAGE_MAP(CMyThread, CWinThread) ON_MESSAGE(WM_MY_THREAD_MSG, CMyThread::OnThreadMsg) END_MESSAGE_MAP()需要提醒的是CWinThread的消息映射处理的是“线程消息”也就是通过PostThreadMessage发过来、hwnd为NULL的消息。这一点和窗口消息的分发路径不一样细节我在第3章代码里会展开。2.3 线程消息队列是“用的时候才创建”这个我前面提了一句这里必须展开。Windows给线程创建消息队列是懒加载机制第一次调用GetMessage、PeekMessage等函数时才创建。如果目标线程还没进入消息循环你就从外部调用PostThreadMessage去投递可能得到的是失败返回码消息压根送不进去。所以一个标准动作是在线程入口函数最开始强制创建队列MSG msg; PeekMessage(msg, NULL, 0, 0, PM_NOREMOVE);这行代码不取出任何消息只负责触发系统为当前线程创建消息队列。这之后你再往里PostThreadMessage就能稳定投递。我见过有人不写这句然后偶尔复现“消息丢失”“第一次发不进去”的诡异问题基本都是这个原因。3. 线程自定义消息循环的两种实现3.1 方案一纯GetMessage循环自己分发这种最贴合“自定义消息循环”的字面意思线程函数里自己写循环自己决定怎么处理消息。伪代码结构如下UINT WorkThreadProc(LPVOID pParam) { // 强制创建消息队列 MSG msg; PeekMessage(msg, NULL, 0, 0, PM_NOREMOVE); // 进入消息循环 while (GetMessage(msg, NULL, 0, 0)) { // 先判断是不是自定义指令 if (msg.message WM_MY_THREAD_MSG) { // 按需处理 OnThreadCommand(msg.wParam, msg.lParam); } else if (msg.message WM_MY_THREAD_QUIT) { // 做清理工作然后退出 DoCleanup(); break; } else { TranslateMessage(msg); DispatchMessage(msg); } } return 0; }虽然是连窗口句柄都没有的线程DispatchMessage不会分发到任何窗口过程但保留标准的TranslateMessage和DispatchMessage调用并没有坏处因为这类线程里如果谁又创建了隐藏窗口这套调用就能无缝衔接。这里再强调一个关键点如果你用GetMessage循环WM_QUIT消息会让GetMessage返回0从而退出循环。所以在线程里想优雅退出最标准的做法是先发自定义退出消息做清理清理完再PostThreadMessage(GetCurrentThreadId(), WM_QUIT, 0, 0)。WM_QUIT本身不会出现在上面分支里它直接让GetMessage返回0。3.2 方案二CWinThread派生类收编进MFC消息映射如果项目本身就重度使用MFC我更推荐派生一个CWinThread子类把线程消息循环收编进MFC自己的消息泵机制。// MyThread.h class CMyThread : public CWinThread { DECLARE_DYNCREATE(CMyThread) public: BOOL InitInstance() override; int ExitInstance() override; afx_msg LRESULT OnThreadCommand(WPARAM wParam, LPARAM lParam); afx_msg LRESULT OnThreadQuit(WPARAM wParam, LPARAM lParam); DECLARE_MESSAGE_MAP() HWND m_hMainWnd; // 主窗口句柄用于回传 BOOL m_bRunning; }; // MyThread.cpp IMPLEMENT_DYNCREATE(CMyThread, CWinThread) BEGIN_MESSAGE_MAP(CMyThread, CWinThread) ON_MESSAGE(WM_MY_THREAD_MSG, CMyThread::OnThreadCommand) ON_MESSAGE(WM_MY_THREAD_QUIT, CMyThread::OnThreadQuit) END_MESSAGE_MAP() BOOL CMyThread::InitInstance() { // 和线程函数一样先强制创建消息队列 MSG msg; PeekMessage(msg, NULL, 0, 0, PM_NOREMOVE); m_bRunning TRUE; return TRUE; // 返回TRUE进入消息循环 } int CMyThread::ExitInstance() { m_bRunning FALSE; return CWinThread::ExitInstance(); } LRESULT CMyThread::OnThreadCommand(WPARAM wParam, LPARAM lParam) { // 收到主线程的消息后在这里干活 // 比如 wParam 1 表示开始2 表示停止 return 0; } LRESULT CMyThread::OnThreadQuit(WPARAM, LPARAM) { // 清理资源 m_bRunning FALSE; // 发WM_QUIT退出Run()内部的消息循环 PostThreadMessage(GetCurrentThreadId(), WM_QUIT, 0, 0); return 0; }在业务侧创建线程要用AfxBeginThread的RUNTIME_CLASS版本CMyThread* pThread (CMyThread*)AfxBeginThread(RUNTIME_CLASS(CMyThread)); pThread-m_hMainWnd GetSafeHwnd(); DWORD dwThreadId pThread-m_nThreadID;这里有个细节不是让你重写Run()。CWinThread::Run()内部已经实现了消息泵并且在出消息时会检查hwnd是否为NULL。对于PostThreadMessage发来的、没有窗口句柄的消息MFC会把它们路由到CWinThread的消息映射表所以ON_MESSAGE才能处理到。如果你自己重写Run()但又想继续用ON_MESSAGE就得自己处理这条路由逻辑等于把MFC内部机制重造一遍没必要。3.3 两种方案怎么选简单总结一下纯GetMessage循环写法直观、可控性强、不依赖MFC类体系适合要在线程里塞大量自定义逻辑或者不想引入CWinThread派生类的场景CWinThread派生类代码干净、有标准消息映射适合线程本身就像一个小型对象、需要封装成员变量和业务方法的场景。我自己的判断标准是线程逻辑超过50行我就用CWinThread派生类只是临时后台干个活需要接收两三条指令用线程函数加GetMessage循环就够了。4. 线程通信、回传与退出收尾4.1 主线程往工作线程发指令消息循环跑起来之后主线程往工作线程发指令用PostThreadMessage::PostThreadMessage(dwThreadId, WM_MY_THREAD_MSG, (WPARAM)CMD_START, 0); ::PostThreadMessage(dwThreadId, WM_MY_THREAD_MSG, (WPARAM)CMD_STOP, 0); ::PostThreadMessage(dwThreadId, WM_MY_THREAD_QUIT, 0, 0);使用PostThreadMessage时注意目标线程ID要用正确的dwThreadId。如果你保存的是CWinThread*指针记得这个指针在线程退出后不一定还有效但m_nThreadID这个DWORD值是安全的你可以在线程创建后立刻保存下来。另外一个常被忽略的点是消息投递顺序。PostThreadMessage的数据进入目标线程的消息队列后是按FIFO顺序处理的。所以即使主线程连发多条指令目标线程也会依次处理不会出现“还没初始化完就收到停止指令”这种乱序。这一点比共享变量加标志位的方案靠谱得多。4.2 工作线程给主窗口回传进度与结果工作线程有一个m_hMainWnd句柄回传进度时直接构造一个用户消息PostMessage到主窗口// 工作线程内 ::PostMessage(m_hMainWnd, WM_MY_THREAD_PROGRESS, (WPARAM)percent, 0);主窗口那边照常加ON_MESSAGE映射。这样做的最大好处是更新控件的代码始终在主线程执行完全规避了跨线程操作MFC控件的问题。这里我建议一个克制原则工作线程里不要高频往主窗口发消息。比如你在一个循环里每1毫秒发一次进度主窗口的消息队列会被刷爆界面卡顿、刷新闪烁都来了。更稳的写法是在线程内部做个限频比如每100毫秒或者进度变化超过1%才发一次。UI上100毫秒一次的进度刷新用户看着已经很流畅了。4.3 线程退出WM_QUIT、自定义退出和等待句柄线程退出有几种处理情况如果是业务任务自然结束你希望线程退出去那在线程内部发一个WM_QUIT就行。WM_QUIT会让GetMessage返回0消息循环自然结束线程函数返回。但更常见的是主线程主动关停子线程。我的做法是先发WM_MY_THREAD_QUIT让线程有机会把自己手里的资源清掉然后在处理函数末尾再发一个WM_QUIT。这样线程能确定性地退出而不是被一刀砍死。等待子线程退出时很多人直接写WaitForSingleObject(pThread-m_hThread, INFINITE);这条代码在大多数场景下没问题但如果子线程在退出前要向主窗口发消息而主线程此时正在卡着等待就会出问题。后面第5章我会专门讲这个死锁场景这里先说结论如果子线程可能往主线程窗口发送消息就不要用无限等待来阻塞主线程要么等一个有限超时要么用MsgWaitForMultipleObjects在等待期间继续泵消息。另外在主窗口关闭时一定要先停掉所有后台线程再让主线程退出。我在项目中见过太多次因为主窗口销毁、子线程还拿着主窗口句柄发消息导致的崩溃都是收尾顺序没控制好。5. 常见问题与排查技巧5.1 消息不响应先查这三个地方遇到消息发过去石沉大海我最先检查这三处现象可能原因处理方式PostThreadMessage返回0GetLastError显示无效线程ID线程还没创建完成或线程已经退出先确保线程启动成功并保存了正确的m_nThreadID线程退出后就别再投递消息发成功了但线程没反应目标线程没有消息循环或还没进入循环线程入口首先PeekMessage强制创建队列等线程进入循环后再发指令CWinThread的ON_MESSAGE没触发重写了Run()丢掉了MFC对NULL窗口消息的特殊路由别重写Run()用基类默认消息泵或者换用纯GetMessage方案手动分发尤其是最后一种我见过有人把CWinThread::Run()整个重写成一个空循环然后到处找为什么ON_MESSAGE收不到消息。其实MFC里线程消息能走消息映射靠的正是基类Run()内部对hwnd NULL消息做的特殊处理。你一旦绕过基类这个机制自然就失效了。5.2 消息循环被长任务卡住怎么办这个问题很隐蔽。你以为是消息循环在正常工作实际上某一次收到指令后消息处理函数里写了一个耗时的for循环结果整个线程的消息泵被堵住了后续指令全部排队等待。想避免这种情况有三种思路第一种是让业务任务分片执行。每次消息处理只做一小步做完后发一条同样的消息给自己相当于用消息循环驱动一个状态机。这样消息泵永远有空闲时间处理新指令。第二种是把业务循环里插入消息泵检出的动作while (m_bRunning) { // 非阻塞地处理当前队列里的消息 while (PeekMessage(msg, NULL, 0, 0, PM_REMOVE)) { TranslateMessage(msg); DispatchMessage(msg); } // 做一小块实际工作 DoSingleStep(); }第三种是干脆把耗时工作拆到另一个更底层的线程队列里不要让耗时操作占用带消息循环的线程。这个属于架构层面的取舍看项目复杂度决定。5.3 死锁等待子线程时的经典陷阱这是线程消息循环项目里最经典的死锁场景主线程在某按钮响应里执行WaitForSingleObject(hThread, INFINITE)等待子线程结束。子线程在退出前调用SendMessage(hMainWnd, WM_MY_THREAD_PROGRESS, ...)打算把最后结果同步交给主窗口。结果主窗口压根处理不了这个消息因为主线程已经阻塞在等待函数里了。SendMessage又是个同步调用会一直等到目标窗口处理完才返回。两边互相等程序卡死。解决办法有几个把子线程的SendMessage改成PostMessage发完就返回不等待主线程处理在等待子线程退出期间用MsgWaitForMultipleObjects替代WaitForSingleObject同时泵主线程的消息队列调整设计让主线程先发退出指令给子线程然后立刻返回等WM_DESTROY或自定义通知消息再统一收尾。我个人的建议是线程间通信能走PostMessage就不走SendMessage。PostMessage投递后立刻返回不会有持有锁等待的问题。真正需要等待结果的场景用一个一次性事件对象CEvent来控制更清晰。5.4 消息处理函数里的线程安全还有一个容易忽略的点是消息处理函数在子线程上下文执行里面访问的成员变量如果同时被主线程或别的线程读写仍然需要加锁。比如前面CMyThread里的m_bRunning如果只是消息处理函数自己写、自己读问题不大但如果你在主线程里也直接读取这个变量判断线程是否活着那就是跨线程访问了。稳妥做法是用volatile加原子操作或者干脆用CWinThread的m_bRunning辅助判定再配合线程句柄的等待结果来判断不要裸读成员变量。共享数据量大的话用CCriticalSection或者CSingleLock保护临界区。注意临界区锁的范围越小越好千万不能在持锁状态下调用PostMessage去等对方处理否则又绕回死锁。最后再分享一点个人体会。我早期做MFC后台线程时习惯用全局标志加Sleep轮询代码写起来似乎简单但一旦涉及界面退出、任务取消、异常中断标志位方案就开始漏洞百出。后来全线切到线程自定义消息循环把一切外部指令都消息化代码结构反而更清爽指令是有序的、可追溯的。如果你正在为MFC线程间通信发愁建议直接按这篇文章的思路搭一套消息循环的骨架后面再往里填业务踩坑概率会小很多。本文还有配套的精品资源点击获取