很多開發(fā)者不清楚這兩者之間的關(guān)系，他們隨意選一個(gè)函數(shù)來用，發(fā)現(xiàn)也沒有什么大問題，于是就忙于解決更為緊迫的任務(wù)去了。等到有一天忽然發(fā)現(xiàn)一個(gè)程序運(yùn)行時(shí)間很長(zhǎng)的時(shí)候會(huì)有細(xì)微的內(nèi)存泄露，開發(fā)者絕對(duì)不會(huì)想到是因?yàn)檫@兩套函數(shù)用混的結(jié)果

我們知道在Windows下創(chuàng)建一個(gè)線程的方法有兩種，一種就是調(diào)用Windows API CreateThread()來創(chuàng)建線程；另外一種就是調(diào)用MSVC CRT的函數(shù)_beginthread()或_beginthreadex()來創(chuàng)建線程。相應(yīng)的退出線程也有兩個(gè)函數(shù)Windows API的ExitThread()和CRT的_endthread()。這兩套函數(shù)都是用來創(chuàng)建和退出線程的，它們有什么區(qū)別呢？

很多開發(fā)者不清楚這兩者之間的關(guān)系，他們隨意選一個(gè)函數(shù)來用，發(fā)現(xiàn)也沒有什么大問題，于是就忙于解決更為緊迫的任務(wù)去了，而沒有對(duì)它們進(jìn)行深究。等到有一天忽然發(fā)現(xiàn)一個(gè)程序運(yùn)行時(shí)間很長(zhǎng)的時(shí)候會(huì)有細(xì)微的內(nèi)存泄露，開發(fā)者絕對(duì)不會(huì)想到是因?yàn)檫@兩套函數(shù)用混的結(jié)果。

根據(jù)Windows API和MSVC CRT的關(guān)系，可以看出來_beginthread()是對(duì)CreateThread()的包裝，它最終還是調(diào)用CreateThread()來創(chuàng)建線程。那么在_beginthread()調(diào)用CreateThread()之前做了什么呢？我們可以看一下_beginthread()的源代碼，它位于CRT源代碼中的thread.c。我們可以發(fā)現(xiàn)它在調(diào)用CreateThread()之前申請(qǐng)了一個(gè)叫_tiddata的結(jié)構(gòu)，然后將這個(gè)結(jié)構(gòu)用_initptd()函數(shù)初始化之后傳遞給_beginthread()自己的線程入口函數(shù)_threadstart。_threadstart首先把由_beginthread()傳過來的_tiddata結(jié)構(gòu)指針保存到線程的顯式TLS數(shù)組，然后它調(diào)用用戶的線程入口真正開始線程。在用戶線程結(jié)束之后，_threadstart()函數(shù)調(diào)用_endthread()結(jié)束線程。并且_threadstart還用__try/__except將用戶線程入口函數(shù)包起來，用于捕獲所有未處理的信號(hào)，并且將這些信號(hào)交給CRT處理。

所以除了信號(hào)之外，很明顯CRT包裝Windows API線程接口的最主要目的就是那個(gè)_tiddata。這個(gè)線程私有的結(jié)構(gòu)里面保存的是什么呢？我們可以從mtdll.h中找到它的定義，它里面保存的是諸如線程ID、線程句柄、erron、strtok()的前一次調(diào)用位置、rand()函數(shù)的種子、異常處理等與CRT有關(guān)的而且是線程私有的信息。可見MSVC CRT并沒有使用我們前面所說的__declspec(thread)這種方式來定義線程私有變量，從而防止庫函數(shù)在多線程下失效，而是采用在堆上申請(qǐng)一個(gè)_tiddata結(jié)構(gòu)，把線程私有變量放在結(jié)構(gòu)內(nèi)部，由顯式TLS保存_tiddata的指針。

了解了這些信息以后，我們應(yīng)該會(huì)想到一個(gè)問題，那就是如果我們用CreateThread()創(chuàng)建一個(gè)線程然后調(diào)用CRT的strtok()函數(shù)，按理說應(yīng)該會(huì)出錯(cuò)，因?yàn)閟trtok()所需要的_tiddata并不存在，可是我們好像從來沒碰到過這樣的問題。查看strtok()函數(shù)就會(huì)發(fā)現(xiàn)，當(dāng)一開始調(diào)用_getptd()去得到線程的_tiddata結(jié)構(gòu)時(shí)，這個(gè)函數(shù)如果發(fā)現(xiàn)線程沒有申請(qǐng)_tiddata結(jié)構(gòu)，它就會(huì)申請(qǐng)這個(gè)結(jié)構(gòu)并且負(fù)責(zé)初始化。于是無論我們調(diào)用哪個(gè)函數(shù)創(chuàng)建線程，都可以安全調(diào)用所有需要_tiddata的函數(shù)，因?yàn)橐坏┻@個(gè)結(jié)構(gòu)不存在，它就會(huì)被創(chuàng)建出來。

那么_tiddata在什么時(shí)候會(huì)被釋放呢？ExitThread()肯定不會(huì)，因?yàn)樗静恢烙衉tiddata這樣一個(gè)結(jié)構(gòu)存在，那么很明顯是_endthread()釋放的，這也正是CRT的做法。不過我們很多時(shí)候會(huì)發(fā)現(xiàn)，即使使用CreateThread()和ExitThread() （不調(diào)用ExitThread()直接退出線程函數(shù)的效果相同），也不會(huì)發(fā)現(xiàn)任何內(nèi)存泄露，這又是為什么呢？經(jīng)過仔細(xì)檢查之后，我們發(fā)現(xiàn)原來密碼在CRT DLL的入口函數(shù)DllMain中。我們知道，當(dāng)一個(gè)進(jìn)程/線程開始或退出的時(shí)候，每個(gè)DLL的DllMain都會(huì)被調(diào)用一次，于是動(dòng)態(tài)鏈接版的CRT就有機(jī)會(huì)在DllMain中釋放線程的_tiddata。可是DllMain只有當(dāng)CRT是動(dòng)態(tài)鏈接版的時(shí)候才起作用，靜態(tài)鏈接CRT是沒有DllMain的！這就是造成使用CreateThread()會(huì)導(dǎo)致內(nèi)存泄露的一種情況，在這種情況下，_tiddata在線程結(jié)束時(shí)無法釋放，造成了泄露。

我們可以用下面這個(gè)小程序來測(cè)試：

復(fù)制代碼 代碼如下:
#include <Windows.h>
#include <process.h>
void thread(void *a)
{
??? char* r = strtok( "aaa", "b" );
??? ExitThread(0); // 這個(gè)函數(shù)是否調(diào)用都無所謂
}
int main(int argc, char* argv[])
{
??? while(1) {
??????? CreateThread(? 0, 0, (LPTHREAD_START_ROUTINE)thread, 0, 0, 0 );
??????? Sleep( 5 );
??? }
return 0;
}

如果用動(dòng)態(tài)鏈接的CRT （/MD，/MDd）就不會(huì)有問題，但是，如果使用靜態(tài)鏈接CRT （/MT，/MTd），運(yùn)行程序后在進(jìn)程管理器中觀察它就會(huì)發(fā)現(xiàn)內(nèi)存用量不停地上升，但是如果我們把thread()函數(shù)中的ExitThread()改成_endthread()就不會(huì)有問題，因?yàn)開endthread()會(huì)將_tiddata()釋放。

這個(gè)問題可以總結(jié)為：當(dāng)使用CRT時(shí)（基本上所有的程序都使用CRT），請(qǐng)盡量使用_beginthread()/_beginthreadex()/_endthread()/_endthreadex()這組函數(shù)來創(chuàng)建線程。在MFC中，還有一組類似的函數(shù)是AfxBeginThread()和AfxEndThread()，根據(jù)上面的原理類推，它是MFC層面的線程包裝函數(shù)，它們會(huì)維護(hù)線程與MFC相關(guān)的結(jié)構(gòu)，當(dāng)我們使用MFC類庫時(shí)，盡量使用它提供的線程包裝函數(shù)以保證程序運(yùn)行正確。

總結(jié)

以上是生活随笔為你收集整理的CreateThread()与beginthread()的区别详细解析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。