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

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

根據(jù)Windows API和MSVC CRT的關(guān)系，可以看出來_beginthread()是對CreateThread()的包裝，它最終還是調(diào)用CreateThread()來創(chuàng)建線程。那么在_beginthread()調(diào)用CreateThread()之前做了什么呢？我們可以看一下_beginthread()的源代碼，它位于CRT源代碼中的thread.c。我們可以發(fā)現(xiàn)它在調(diào)用CreateThread()之前申請了一個叫_tiddata的結(jié)構(gòu)，然后將這個結(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ù)包起來，用于捕獲所有未處理的信號，并且將這些信號交給CRT處理。

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

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

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

我們可以用下面這個小程序來測試：

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

最新評論