這兩天在做一個(gè)數(shù)據(jù)結(jié)構(gòu)，使用樹(shù)結(jié)構(gòu)，兩層，第一層的數(shù)據(jù)元素為第二層的n個(gè)分支

遇到問(wèn)題如下：

1：使用vector在debug下運(yùn)行正常，在release下源碼運(yùn)行正常封裝后運(yùn)行失敗

請(qǐng)教了多人，覺(jué)得可能是vector的使用問(wèn)題，因?yàn)槲覍⒌谝粚臃庋b為dll，而在第二層使用源文件，導(dǎo)致在第二層申請(qǐng)的內(nèi)存在第一層釋放時(shí)出現(xiàn)問(wèn)題。

2：為了避免vector的內(nèi)存釋放問(wèn)題，自己寫(xiě)了鏈表，結(jié)果出現(xiàn)了同樣的問(wèn)題，

最終將第一層和第二層都封裝在一個(gè)dll內(nèi)，此時(shí)運(yùn)行通過(guò)（同一個(gè)heap句柄）

總結(jié)：

1：申請(qǐng)一個(gè)元素用new int，delete 申請(qǐng)多個(gè)元素用new int[n],n>1; delete [] ?否則會(huì)出現(xiàn)釋放內(nèi)存上的問(wèn)題，要配套使用，就將這個(gè)歸結(jié)為一個(gè)編碼規(guī)范吧，沒(méi)有做進(jìn)一步測(cè)試,?

2：dll內(nèi)部申請(qǐng)內(nèi)存的代碼要全部封裝進(jìn)去，以避免系統(tǒng)認(rèn)為內(nèi)存在外部申請(qǐng)出現(xiàn)釋放報(bào)錯(cuò)的問(wèn)題，要徹徹底底的遵循一個(gè)原則，誰(shuí)申請(qǐng)誰(shuí)釋放，尤其在封裝為dll時(shí)必須要如此。

3：生成dll插件程序和調(diào)用程序均設(shè)置為?MultiThread DLL debug 模式，運(yùn)行元程序運(yùn)行正常，原設(shè)置為MultiThread debug，vector的調(diào)用是沒(méi)問(wèn)題的，問(wèn)題在于設(shè)置引起的heap釋放問(wèn)題。

在一次面試中突然被問(wèn)到這個(gè)問(wèn)題，當(dāng)時(shí)還真不明白，回來(lái)在網(wǎng)上找到了說(shuō)法：

?因?yàn)閙alloc/free,new/delete都是調(diào)用HeapAlloc/HeapFree來(lái)實(shí)現(xiàn)來(lái)實(shí)現(xiàn)內(nèi)存分配是釋放的。

查看Windows的API可以看到，這兩個(gè)函數(shù)都需要一個(gè)Heap的HANDLE做為參數(shù)。CRT庫(kù)采用了全局變量來(lái)保存這個(gè)HANDLE。如果是CRT靜態(tài)鏈接，CRT庫(kù)的代碼會(huì)鏈接到各個(gè)DLL中去，也包括這個(gè)全局變量。

也就是說(shuō)，每個(gè)使用CRT靜態(tài)鏈接的dll中都有一個(gè)自己的全局堆句柄，他們自己都在這個(gè)句柄上使用內(nèi)存。當(dāng)釋放dll中分配的內(nèi)存時(shí)由于使用的堆句柄不一致于是出錯(cuò)。

當(dāng)使用CRT動(dòng)態(tài)鏈接時(shí)，有于每個(gè)dll都是去調(diào)用CRT庫(kù)的dll函數(shù)來(lái)分配和釋放內(nèi)存的，使用的是同一個(gè)句柄，所以就沒(méi)有這個(gè)問(wèn)題。

一般是哪里申請(qǐng)哪里釋放,誰(shuí)申請(qǐng)的內(nèi)存由誰(shuí)釋放，這是封裝的基本原則。???
??dll內(nèi)部（對(duì)外隱藏）的內(nèi)存分配，顯然要dll自己處理啦。當(dāng)然也可以由調(diào)用它的程序釋放, 但不推薦，高內(nèi)聚,且不安全?

???dll外部的由外部程序分配后傳進(jìn)dll，使用完后，可以由外部程序釋放，也可以調(diào)用dll內(nèi)部函數(shù)幫助釋放。

? 如果導(dǎo)出的是類(lèi)，則可以在類(lèi)中定義自我是釋放的Release導(dǎo)出函數(shù)： ??
? void ? release() ??
? { ??
? ? ? ? delete ? this; ??
? }??

COM的內(nèi)存釋放就是采用這樣的方法?

?總結(jié)：靜態(tài)鏈接的dll中申請(qǐng)的內(nèi)存，必須由內(nèi)部釋放；動(dòng)態(tài)鏈接的dll中申請(qǐng)的內(nèi)存，可以由外部釋放。

一個(gè)模塊一個(gè)堆，一個(gè)線程一個(gè)棧。
dll里malloc的內(nèi)存，在exe里free會(huì)出錯(cuò)。

CRT（C運(yùn)行時(shí)期庫(kù)）不是使用進(jìn)程缺省的堆來(lái)實(shí)現(xiàn)malloc（new中調(diào)用malloc）的，而是使用一個(gè)全局句柄HANDLE _crtheap來(lái)分配內(nèi)存的。這個(gè)_crtheap是在XXXCRTStartUp（CRT提供的進(jìn)口點(diǎn)函數(shù)）中創(chuàng)建的。??
? 由于CRT靜態(tài)連接，則樓主的DLL里有也有一個(gè)CRT，因此也有一個(gè)_crtheap。而在dll中的new使用dll中的_crtheap句柄分配堆，在exe中的delete使用exe中的_crtheap釋放堆，當(dāng)然失敗！

解決辦法：
1。在DLL中輸出一個(gè)函數(shù)給EXE調(diào)用，專(zhuān)門(mén)用來(lái)釋放由DLL分配的內(nèi)存；
2。用GlobalAlloc()代替new，用GlobalFree()代替delete；
3。使用單一的堆，分配內(nèi)存使用HeapAlloc(GetProcessHeap(),0,size)，釋放內(nèi)存使用HeapFree(GetProcessHeap(),0,p)；
4。把dll和exe的Settings的C/C++選項(xiàng)卡的Code?? Generation的Use?? Run-time?? liberary改成Debug?? Multithreaded?? DLL，在Release版本中改成Multithreaded?? DLL；這樣使用一個(gè)CRT了——MSVCRT.DLL。
?

以上是在網(wǎng)上找到的資料,今天做過(guò)詳細(xì)測(cè)試,結(jié)果如下:

測(cè)試1：使用malloc/free組合來(lái)分配和釋放內(nèi)存,DLL中使用malloc分配，exe中使用free釋放。
我建的是Win32 DLL工程, C/C++->Code generation 設(shè)置是 Multithread DLL debug, 但是exe工程設(shè)置是MultiThread debug,所以不管怎么樣,總是會(huì)拋異常. 這就間接證明了上述的描述是正確的, 若我修改exe工程設(shè)置是 MultiThread DLL debug, 那么malloc/free組合就能很好的工作起來(lái)了。

測(cè)試2：使用HeapAlloc/HeapFree組合來(lái)分配和釋放內(nèi)存，DLL中使用HeapAlloc分配，exe中釋放。
exe的配置還是MultiThread Debug，DLL中HeapAlloc(GetProcessheap(), HEAP_ZERO_MEMORY, 1024)分配，exe中HeapFree(GetProcessHeap(), 0, p)釋放，,則還是無(wú)法正常運(yùn)行，還是拋異常。若exe中設(shè)置成MultiThread DLL debug就正常運(yùn)行了。

測(cè)試3：還是使用HeapAlloc/HeapFree來(lái)進(jìn)行，但是DLL中導(dǎo)出一個(gè)方法來(lái)釋放DLL中分配的內(nèi)存。
若exe配置是MultiThread Debug，無(wú)法正常運(yùn)行，拋異常。若修改成MultiThread DLL debug正常運(yùn)行。
?
所以得到的結(jié)論如下：
不管是使用malloc/free組合還是HeapAlloc/HeapFree組合，exe工程均需要設(shè)置成MultiThread DLL debug才能正常運(yùn)行起來(lái)的，CSDN上的那個(gè)討論在這兒貌似是有出入的，因?yàn)檎{(diào)用GetProcessHeap()得到的是當(dāng)前堆（其實(shí)就跟new一樣了），依然借還不在同一個(gè)地方，所以錯(cuò)的。而且DLL的設(shè)置不能隨意修改。所以若有涉及到這種問(wèn)題的，最好的辦法還是在哪個(gè)模塊分配的就在哪個(gè)模塊釋放最好，要不然反倒會(huì)引來(lái)更多的麻煩

總結(jié)

以上是生活随笔為你收集整理的C++中的Dll内存问题的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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