VC6内存管理malloc（3）

ioinit申请内存0x130字节。把007d0ed0地址传给上游，之后调整剩余内存大小为ec0，ff0-130，因为在debug模式，所以还需要调整指针，返回实际使用内存的指针。00000002表示CRT_BLOCK，main函数内内存malloc，标记为NORMAL_BLOCK。程序执行到最后，链表中还有_CRT_BLOCK，不是内存泄漏，如果有NORMAL_BLOCK才是内存泄漏。内存申请完，剩余大小还是大于等于1k，还是在原先链表。

VirtualAlloc内存申请，MEM_RESERVE，虚拟地址申请，MEM_COMMIT，实际内存申请。

0x130，由18list供应，使用32组bitmap，每个bitmap64bit表示每个链表是否内存可供内存使用。但是在最开始，只有最后一个list有空间可供使用。

第二次内存申请，0x240大小。查bitmap，相应bit位还是0，还是最后一个链表供应。每个Group的cntEntries表示内存申请次数，为0，表示没有申请，或申请后都还了回来。indGroupUse表示目前用32个group中的那个，目前使用0号group。

第三次内存申请，0x70大小。查bitmap，相应bit位还是0，还是最后一个链表供应。0号Group的cntEntries为3。

第15次，内存释放0x240，cntEntries减一，变成13，是第2次内存申请。由35list负责收回，0号的group的35bit置为1。

第19次分配0x190，本应由25list分配，但是bit为0。往大的list顺序查找，由35list分配，不要在最大的链表直接分配，这样便于释放时合并。0x240分配0x190后，剩余0xb0。list调整移动，移动到24list，并调整相应bitmap。

 

第n的分配0x230，第0号group，bitmap情况为02000014 00000000表示3个链表挂有区块，不足0x230内存分配，所以使用下个group进行内存分配。indGroupUse表示成1。

内存合并：300回收，301表示正在使用，但是前后都是300，表示目前没有使用。合并后链到相应的list中。

首先确定落到那个1M中，在确定位于那个group，在确定那个list。使用夹逼法来确定范围。

sbh实际是分段管理。把header的1M分成32个，group可以便于充分回收，因为1M全部回收十分困难。如何判断一个group是否全部回收？？cntEntries为0，表示这个group全部回收。

全回收的group不是立即还回操作系统。有2个全回收的group，才会还一个group。如果16个header使用完，会继续申请，16，32。。。

_sbh_pHeaderDefer指向哪个header，_sbh_indGroupDefer指向哪个header中哪个group。所有的区块都被一个指针链着。

程序不同层次的内存申请优化。都有复杂的设计！！！每层做优化，是浪费，但是有必要做，因为每层不能预测依赖下层是否做了内存优化，所以自己要做。