用推文回太长了, 所以单独回这段
推 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)