glibc中内存管理

一下是自己对glibc的一些个人理解。

非主分配区：

mmap一片大的内存，如果 top-chunk 包含了整个 sub-heap，ptmalloc 会调用 munmap 把整个 sub-heap 的内存返回给操作系统。

主分配区：

当该 次回收的空闲内存大小达到某个阈值，并且 top chunk 的大小也超过了收缩阈值，会执行内 存收缩，减小

top chunk 的大小，但至少要保留一个页大小的空闲内存，从而把内存归还给 操作系统。

当需要分配的 chunk 足够大，而且 fast bins 和 bins 都不能满足要求，甚至 top chunk 本

身也不能满足分配需求时， ptmalloc 会使用 mmap 来直接使用内存映射来将页映射到进程空

间。这样分配的 chunk 在被 free 时将直接解除映射，于是就将内存归还给了操作系统，

Last remainder：

这是一种特殊的chunk，这种chunk是会进行分裂的。

当用户的请求超过 mmap 分配阈值，并且主分配区使用 sbrk()分配失败的时候，或是非 主分配区在 top chunk 中不能分配到需要的内存时， ptmalloc 会尝试使用 mmap()直接映射一 块内存到进程内存空间。使用 mmap()直接映射的 chunk 在释放时直接解除映射，而不再属 于进程的内存空间。（也就是说现在映射的内存的空间就是一个chunk，就是分配给用户程序的空间，不会再继续进行切割，不同于sud_heap等，不过Last remainder是个特例，这种chunk是可以分裂的）

之前一直以为，程序既然是在虚拟地址空间，所以程序能够分配到多少的内存是由编译器是32bit的还是64bit决定的，But，经过自己的实践证明，能够分配到多少的内存还受到程序所在的系统的实际内存的限制。

我分别在64bit的编译器下的

62G+（虚拟）7.8G机器 ， 大约可以申请62G，申请63G会失败

110G+（虚拟）22G机器，可以申请127G内存，申请128G会失败

512G+（虚拟）1G可以申请1.3G，申请1.4G会失败。

除此以外发现一个奇怪的现象，当系统中存在磁盘的cache占用了内存的时候，这部分的内存是可以被malloc所利用的，这部分内存也就从cache状态转成了used状态。貌似是一个释放chche的方法，

25 const size_t SIZE = (long)1024*1024*1024*1.3;
26 int main(){
27     char *buf = (char*) malloc(SIZE);
28     if(buf == NULL){
29
30     |   cout<<"FAILED"<<endl;
31     |   return 1;
32     }
33     double sum = 0 ;
34     for(size_t i = 0 ; i < SIZE ; i++){
35     |   buf[i] = i;
36     }
37     cout<<sum<<endl;
38
39
40 }

测试代码大约长成上面这个样子