VirtualAlloc 一次分配 1PAGE 以上的 RAM. 每次分配都是 PAGE 的整数倍. 你不会想为了分配 1 个 BYTE 的空间而浪费剩下的 4095 字节. OK, 你可以自己写算法, 多分配几 PAGE. 然后每次分配少量数据时就从那几 PAGE 中划分出来. KERNEL32 提供了一个解决办法, 用 HeapAlloc/GlobalAlloc 分配 RAM. 这样, KERNEL32 帮助完成分配动作, 并且尽量在减少用于跟踪空闲区域和已占用区域消耗的数据结构.
很久以前也有个产品叫做 WINDOWS. 那时候的 WINDOWS 是 16BIT 的, 地址空间有些紧俏, 有钱不够, 还需要粮票肉票才能拿到. 你已经调用 GlobalAlloc 和已经出钱的性质一样. GlobalAlloc 还不够, 有时候需要 GlocalLock 才能确定你的东西确实可以拿到手, 不然你的指针会非法, 被充公, 你的应用会被杀头. 扯远了. 后来 OS 进化了, 觉得可以取消粮票肉票, 但是你必须用新版钞票才行. 那就是 HeapAlloc. 只要市场上的 RAM 数量没问题, 你的 HeapAlloc 没问题, 那就总能拿到东西. 但是, 你总不能说有了 2000 版的钞票, 那 80 版的马上作废啊, 那 GlobalAlloc 也只好继续流通下去. 至于可以流通到什么时候, 没人知道.
GlobalAlloc 和 LocalAlloc 都是 Windows 系统提供的内存分配函数, 他们的区别源于 16BIT 代码时代, 那时没有不同的进程内存空间, GlobalAlloc 是在全局的, 公用的远堆上分配; LocalAlloc 则在任务自己的近堆上分配. 在 Win32 平台下这两个函数是完全相同的, 都是在进程自己的内存空间中分配, Lock 之后的结果是普通指针(32位近指针). new 与它们的区别未免太大, 因为与 C++ 的构造函数和异常机制有关. 一般编译器中的 new 都是用 malloc 来分配内存的. 用 malloc 与其它两个函数比较应该更合理. 一般 malloc 的实现并不是从系统的堆中分配的, 而是从编译器连接的运行库自己管理的堆中, 在 Win32 平台上的开发工具的编译结果中, 通常是用 HeapCreate 创建一个堆, 用 HeapAlloc 和 HeapRealloc 维护堆的空间增长, 在最后用 HeapDestroy 删除堆. 而在用 malloc 分配, 用 free 释放时则由运行库的代码负责从这个堆中分配空间和向这个堆中归还空间, 并维护这个堆中的数据结构. 由于 malloc 堆的管理是由运行库自己管理的, 所在当我们使用静态运行库时, 如果在一个 DLL 中用 malloc 分配了内存而在另一个 DLL 中用 free 去释放它, 通常都会产生问题. 这是因为每个DLL都连接了一份运行库的代码, 从而也都有一个自己的局部堆, 而在用 free 释放时它会假设这块内存是在自己的堆中分配的, 从而导致错误. 而通过 GlobalAlloc 和 LocalAlloc 分配的内存不存在这个问题.
HeapCreate 就已经完成了创建堆的操作. HeapAlloc, HeapReAlloc 和 HeapFree 都是从这个堆中分配, 释放内存的函数. 也就是说, Windows 系统其实已经为我们提供了完整的一套使用自己的局部堆的操作, 不过没有看到指定分配策略的方法. 根据编译器提供的源代码来 看, VC 中的 malloc, realloc 和 free 等函数主要功能就是用这几个 API 函数来实现的, 而 BC 中的实现相当复杂, 似乎是维护了一套自己的逻辑. 据说 BC 的内存分配比 VC 快, 大概是这个原因.
