用推文回太長了, 所以單獨回這段 推 dreamboat66: 所以exe跟dll會allicate在不同的heap這講法是錯的嗎 應該說，和 exe/dll 沒有因果關係。 另一方面，就算是所謂的 "同一個 exe" 內，也不見得保證使用相同的 heap。 連結 dynamic/static link library 不會有什麼不同而造成各自獨立的 heap。 差別只是載入與解析 symbol 的時機不同。事實上，malloc 根本就無法分辨是被 exe 或是 dll 呼叫，所以要從不同的 heap 來配置。例如 main (a.out) -> foo (libfoo.so) -> bar (a.out) -> malloc (libc.so) 在這樣的 call chain 下，malloc 該從哪個 heap 配置呢？ 一般來說，會各自動態連結 runtime library (ex: msvcrt.dll/libc.so)。 之後 loader 又將同一個 process 的 exe/dll 呼叫的 malloc 解析成同一個 functoin，那就會受同一個 heap 管理。 當然也可以不同的 heap，但這是寫的人自已明確指定 heap。使不使用同一個 heap 純粹是怎麼設計資源管理上的問題，在既定的 API 規範下，可能會有不 同的實作，不需要臆測底層怎麼運作寫出不 portable 的 code ，就像正常不 會想能不能把 fopen 出來的東西用 POSIX close() 或 Windows 的 CloseHandle() 去關閉一樣。 使用獨立的 heap 通常有幾個考量 1. 避免 resource leak。例如在 delete 掉一個複雜的 object 後, 自動把所有 透過他 allocate 出來的其他 object 一並 release 2. 避免 fragment 。如果 allocate 出來的 object 大小都一樣，可以減少記錄 used/free 區塊大小的 overhead 3. 其他。例如 stack allocator。對有 first in last out 特性的 allocate 方式 可以減少追蹤分散的 free-list 的 overhead。 4. 避免 thread contention 這些考量都跟動態 library 沒有直接關係，而且 (2) (4) 在現代的 memory allocator 實作多少都可以有一定程度的優化 例如使用 dlopen/dlclose 在執行時期載入的第三方外掛，為了避免因為外掛本身 的 bug 造成 leak 影響主程式，也是有可能使用獨立的 heap 在 unload 時自動 free 掉整個 heap。 以 Windows 為例 HANDLE myHeap; BOOLEAN WINAPI DllMain(IN HINSTANCE hDllHandle, IN DWORD nReason, IN LPVOID Reserved) { BOOLEAN bSuccess = TRUE; switch (nReason) { case DLL_PROCESS_ATTACH: myHeap = HeapCreate(0, SIZE_OF_INIT, SIZE_OF_MAX); break; case DLL_PROCESS_DETACH: HeapDestroy(myHeap); break; } } 配置時不直接使用 malloc, 而是使用 HeapAlloc ptr = HeapAlloc(myHeap, 0, sizeof(obj)); 在 Linux 的話，類似的機制可以用 constructor/destructor 來初始獨立的 heap， 以 dlmalloc 的 mspace 為例，使用起來大略是像這樣 mspace ms; __attribute__ ((constructor)) void foo_load () { ms = create_mspace(....); } __attribute__ ((destructor)) void foo_unload () { destroy_mspace(ms); } 配置時則是使用 mspace_malloc(ms, bytes) --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.32.204.230 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/C_and_CPP/M.1507628404.A.ECF.html ※ 編輯: cole945 (114.32.204.230), 10/10/2017 19:06:13