(一)       SendMessage 的工作機(jī)制

首先我要先簡要的說明一個(gè)和這個(gè)話題有關(guān)系的消息處理機(jī)制：

    在Window操作系統(tǒng)當(dāng)中，窗口時(shí)屬于所在Thread的也就是說 你這個(gè)窗口在那個(gè)Thread 當(dāng)中Create 的那么你這個(gè)窗口就屬于那個(gè)Thread。同時(shí)窗口的消息處理函數(shù)也都會在這個(gè)Thread 當(dāng)中被執(zhí)行的。（不要問為什么 Window 就是這么設(shè)計(jì)的 嘿嘿）

在講死鎖之前我們先把SendMessage的工作機(jī)制搞清楚；

SendMessage 發(fā)送出來的消息 到底進(jìn)入不進(jìn)入消息隊(duì)列，有人說進(jìn)入，有人說不進(jìn)入，其實(shí)都是錯(cuò)誤的，確切的說是有時(shí)進(jìn)入，有時(shí)不進(jìn)入。那么什么時(shí)候進(jìn)入，什么時(shí)候不進(jìn)入呢？ 我們舉一例子來說：假如在 Thread A 中有一個(gè) 窗口W1，那么 在 Thread A 中像 W1 SendMessage 一個(gè)消息，那么這個(gè)消息將不會被放入消息隊(duì)列，而是直接調(diào)用了W1的消息處理函數(shù)來直接處理了這個(gè)消息。這是不被放入隊(duì)列的情況；假如現(xiàn)在又多了一個(gè)Thread B ，那么在 Thread B 中 像 W1 SendMessage 發(fā)送消息 這個(gè)時(shí)候 W1 將被放入到 Thread A 的消息隊(duì)列當(dāng)中，這些Thread A 中的消息循環(huán)的GetMessage 會Get到這個(gè)消息 并處理之。 這就是進(jìn)入消息隊(duì)列情況；根據(jù)在哪里我們來看看我的測試結(jié)果：

測試1：我創(chuàng)建了一個(gè)無DOC/View 之支持的單文檔工程：

我在CMainFrame添加如下代碼：

        BEGIN_MESSAGE_MAP(CMainFrame, CFrameWnd)

               ON_WM_CREATE()

               ON_WM_SETFOCUS()

               ON_MESSAGE(WM_USER + 100,OnMy)

ON_MESSAGE(WM_USER + 200,OnMy2)

END_MESSAGE_MAP()

LRESULT CMainFrame::OnMy(WPARAM wParam,LPARAM lParam)

{

             int i = 0;

             return TRUE;

}

LRESULT CMainFrame::OnMy2(WPARAM wParam,LPARAM lParam)

{

             int i = 2;

             return TRUE;

}

然后我再 int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct) 的最后 加入了一行代碼：

SendMessage(WM_USER + 100,0,0);

此主題相關(guān)圖片如下：

然后直接 F5 運(yùn)行程序 等到 程序停止在斷點(diǎn)上，我們看看Call Stack 的調(diào)用順序：

此主題相關(guān)圖片如下：

然后 我又將 SendMessage 改成：

PostMessage(WM_USER + 100,0,0);

然后直接 F5 運(yùn)行程序 等到 程序停止在斷點(diǎn)上，我們再看看Call Stack 的調(diào)用順序：

此主題相關(guān)圖片如下：

通過這2個(gè) Call Stack 大家可以很清楚的看到,執(zhí)行SendMessage的時(shí)候，是直接調(diào)用了 AfxWndProcBase 這個(gè) 消息處理函數(shù)(MFC 通過HOOK 將所有窗口的處理函數(shù)都重定向到這個(gè) 函數(shù)上了，AfxWndProcBase()不明白的自己去看《MFC深入淺出》)，大家可以很清楚的看到，在SendMessage 到 AfxWindProcBase 之間根本沒有調(diào)用CWinApp::Run() ，也就是說從SendMessage 到執(zhí)行OnMy()根本沒有通過程序的主消息循環(huán)的GetMessage （Run 內(nèi)部好像用的PeekMessage記不清楚了）取消息。那么有人會問，SendMessage的內(nèi)部就不會先發(fā)消息放入隊(duì)列再通過GetMesssage把消息取出來了嗎？答根本沒必要那樣做，那是脫褲子放P多此一舉。

從這個(gè)測試?yán)拥慕Y(jié)果我判定SendMessage 在 Thread A 中向 W1

SendMessage 的消息根本不進(jìn)入消息隊(duì)列。

測試2：那么什么時(shí)候進(jìn)入隊(duì)列呢我來看看這個(gè)例子

沿用上面那個(gè)例子的代碼我將 OnCreate 中的 SendMessage 和 PostMessage 都刪除掉。然后加入如下代碼：

//Thread Proc

UINT ThreadProc(LPVOID lParam)

{

             CMainFrame * v_pFrameWnd = (CMainFrame *)lParam;

             if(v_pFrameWnd)

             {

                v_pFrameWnd->SendMessage(WM_USER + 100,0,0);

             }

             return 0;

}

并且 在 OnCreate 種加入如下代碼：

AfxBeginThread(ThreadProc,this);

然后F5 運(yùn)行 等待程序停在斷點(diǎn)處，看Call Stack 如下：

此主題相關(guān)圖片如下：

我們發(fā)現(xiàn)這個(gè) Call Stack 就和剛才那個(gè)PostMessage 的Call Stack 是一樣的 這個(gè) WM_USER + 100 消息是通過 Run 內(nèi)部的 GetMessage 取出來的 。所以我斷定：

在 Thread B 中向W1 SendMessage 發(fā)送消息 ，消息是放入了 Thread A 的消息隊(duì)列中。由于SendMessage的特性只有當(dāng)消息被執(zhí)行完畢才能夠返回，所以Thread B 中的SendMessage 要等 Thread A 當(dāng)中消息執(zhí)行完畢后才能夠返回。

(一)       SendMessage 產(chǎn)生的 死鎖問題

Thread 死鎖肯定是發(fā)生在2個(gè)Thread 之間，A等B ，B等 A，就產(chǎn)生了死鎖。大家看了上面測試之后一定會發(fā)現(xiàn)，SendMessage 的死鎖和上面的第二個(gè)例子有關(guān)系，也就是 說 通過 Thread B 向 W1 發(fā)送消息的時(shí)候又可能會產(chǎn)生死鎖。

那么死鎖 何時(shí)產(chǎn)生呢 ？通過上面的例子我們知道了 如果Thread B 向 W1 SendMessage一個(gè)消息，那么 Thread B 的這個(gè)SendMessage 就要等 Thread A 的隊(duì)列中的 消息執(zhí)行完畢才能夠返回，如果在 Thread B SendMessage 的同時(shí) Thread A 等待 Thread B 中的某一處理完畢才能夠繼續(xù)處理消息的話，那么這個(gè)時(shí)候就發(fā)送了死鎖。

我們繼續(xù)以測試來說明：

測試3：

    首先在 CMainFrame中加入一個(gè) 成員變量：m_bThreadExit （Public）

    我們將 UINT ThreadProc(LPVOID lParam) 加入一樣代碼如下：

       UINT ThreadProc(LPVOID lParam)

{

          CMainFrame * v_pFrameWnd = (CMainFrame *)lParam;

          if(v_pFrameWnd)

          {

             v_pFrameWnd->SendMessage(WM_USER + 100,0,0);

          }

          v_pFrameWnd->m_bThreadExit = TRUE;

          return 0;

}

然后再 OnCreate 當(dāng)中添加如下代碼：

                             m_bThreadExit = FALSE;

          AfxBeginThread(ThreadProc,this);

          while(TRUE)

          {

             if(m_bThreadExit)

                break;

             Sleep(55);

}

 OK 編譯 F5 運(yùn)行 發(fā)現(xiàn)程序 進(jìn)入無響應(yīng)狀態(tài)，好這時(shí)我么讓程序 暫停：

看看 2個(gè)Thread 的 Call Stack 都停在那里了？

Main Thread如下：

此主題相關(guān)圖片如下：

在看看 另一個(gè)線成：

此主題相關(guān)圖片如下：

這會 是不是 很明了了

MainThread 停在 循環(huán)內(nèi) 等待 m_bThreadExit 為 True，而 另一個(gè)線成 則等待 MainThread 處理完畢 WM_USER + 100 這個(gè)消息，結(jié)果你等我，我等你，死了。。。。

(一)       處理辦法

1． 針對上面的例子 我們 可以通過 把SendMessage 改成 PostMessage 的方法來放棄等待。 這樣就解決了

2． 有些時(shí)候 第1種方法不符合要求比如下面這中情況

UINT ThreadProc(LPVOID lParam)

{

          CMainFrame * v_pFrameWnd = (CMainFrame *)lParam;

          if(v_pFrameWnd)

          {

          v_pFrameWnd->SetWindowText("lvyang");

          }

          v_pFrameWnd->m_bThreadExit = TRUE;

          return 0;

}

這里面的CWnd：：SetWindowText里面實(shí)際上調(diào)用的是：：SetWindowText 而：：SetWindowText 里面有調(diào)用 SendMessage 發(fā)送一個(gè)消息給CWnd 的窗口 ，因?yàn)椋海?span>SetWindowText 內(nèi)部的我們沒有辦法來修改，那我只能去修改 MainThread 當(dāng)中的 While 循環(huán)了。

那如何修改呢？ ThreadProc 當(dāng)中 SetWindowText之所以被諸塞，就是因?yàn)?它向 MainThread SendMessage 的消息沒有得到處理，那么我們讓他處理的不就OK了嗎？好那我們就讓他處理，代碼如下：

MSG msg;

       while(TRUE)

       {

          if(m_bThreadExit)

             break;

          if(::PeekMessage(&msg,NULL,NULL,NULL,PM_NOREMOVE))

          {

             if(::GetMessage(&msg,NULL,NULL,NULL))

             {

                if(!PreTranslateMessage(&msg))

                {

                   ::TranslateMessage(&msg);

                   ::DispatchMessage(&msg);

                }

             }

          }

          Sleep(55);

}

終于搞完了