mallopt change malloc/new action

     使用new/delete：

int32_t i = 0;
std::queue<char *> vTest;
for (i = 0; i < 1000000; i ++) 

{
    char *p = new char[100];
    vTest.push(p);
    char *p1 = vTest.front();
    delete[] p1;
    vTest.pop();
}

当在一个循环内，如果申请空间，在循环内, 并释放掉，内存不会引起增长，即使重复上面的单元也不会增长内存，但是当：

int32_t i = 0;

std::queue<char *> vTest;
for (i = 0; i < 1000000; i ++)

 {

    char *p = new char[100];
    vTest.push(p); 
}

while( !vTest.empty() )

 {
    char *p1 = vTest.front();
    delete[] p1;
    vTest.pop();
}

      通过delete[]后，内存并没有减少，即使重复上面的单元，内存只会增加，不会减少，用valgrind的memcheck工具查看，也无内存泄漏。

      其实，这个与malloc的实现有关，一般来说，系统都会有默认的malloc行为，针对FreeBSD和Linux系列，对于大于1M的数 据，malloc行为会直接调用系统的接口，直接向操作系统申请一块比数据块更大内存，然后划分成若干过chunk单元（这里会有一些算法设计），而这些 chunk分配给数据后，肯定还会剩下很多的trunk单元，留给以后的分配用，但这里耗费系统资源，代价较大；

       而对于小于等于1M的数据，则 malloc行为会利用那些trunk单元，占用系统资源少，速度快。同理free的时候，数据占用的内存被释放，如果大于1M，则系统会回收掉内存，节 省资源，而小于等于1M的数据，则内存释放时，不会还给操作系统，以空trunk形式存在，并由当前进程空间维护着。说到底，这种策略就是一个内存池的概 念。

        内存池灵活度更加方便，针对FreeBSD和Linux系列，每个trunk最小容纳的字节数是16bytes，而自行设计的内存池，可以更 加优化，节省大量产生的内存碎片，像上面的代码就是因为内存虽然释放，但是这些内存都没有还给操作系统，导致内存碎片越来越多，最好的设计方式就是使用一 个内存池，针对经常使用的分配大小，可以多分配这样的trunk，而其他大小的trunk可以少产生，从而达到优化目的。

     还可以使用mallopt来直接调整malloc的行为：

int mallopt (int PARAM, int VALUE)

     When calling `mallopt', the PARAM argument specifies the parameter
     to be set, and VALUE the new value to be set.  Possible choices
     for PARAM, as defined in `malloc.h', are:

    `M_TRIM_THRESHOLD'
         堆顶内存回收阀值，当堆顶连续空闲内存数量大于该阀值时，libc的内存管理其将调用系统调用brk，来调整堆顶地址，释放内存。该值缺省为128k。
    `M_TOP_PAD'
         当在堆顶的空闲空间（通过sbrk释放得到的）到达设定的值时，则将这些内存还给系统。这样做的目的是在堆项保留一些空闲空间，防止频繁的申请内存的系统调用。该值缺省为 0.
     `M_MMAP_THRESHOLD'

         超过这个设定值的内存分配，会采用mmap系统调用而不是brk，

      如果小于该阀值的内存申请，内存管理其使用brk系统调用来扩展堆顶指针。该阀值缺省值为128kB。

          All chunks larger than this value are allocated outside the

          normal heap, using the `mmap' system call.  This way it is
          guaranteed that the memory for these chunks can be returned
          to the system on `free'.  Note that requests smaller than
          this threshold might still be allocated via `mmap'.
     `M_MMAP_MAX'
          使用mmap分配的最大chunk数量，0表示禁用mmapy，默认值为65536。

`M_MXFAST'

     小块内存阀值，小于该阀值的小块空闲内存将不会去尝试合并，其缺省值为64

`M_ALLOC_ARENA_MAX'

      glibc为了分配内存的性能的问题，使用了很多叫做arena的memory pool,缺省配置在64bit下面是每一个arena为64M，一个进程可以最多有 cores * 8个arena。假设你的机器是4核的，那么最多可以有4 * 8 = 32个arena，也就是使用32 * 64 = 2048M内存。 当然你也可以通过设置环境变量来改变arena的数量。

      hadoop推荐把这个值设置为4。当然了，既然是多核的机器，而arena的引进是为了解决多线程内存分配竞争的问题，那么设置为cpu核的数量估计也是一个不错的选择。设置这个值以后最好能对你的程序做一下压力测试，用以看看改变arena的数量是否会对程序的性能有影响。

glibc 的思路和tcmalloc相似

      mallopt是malloc底层的函数，使用info mallopt来查看相关帮助信息。

     内存的跟踪
     使用 mtrace 检测内存泄漏
1、 引入头文件 #include <mcheck.h>
2、 在需要跟踪的程序中需要包含头文件，而且在main()函数的最开始包含一个函数调用：mtrace()。由于在main 函数的最开头调用了mtrace()，所以该进程后面的一切分配和释放内存的操作都可以由mtrace来跟踪和分析。
3、 在运行进程前定义一个环境变量，用来指示一个文件。该文件用来输出 log 信息。如下的例子：
$ export MALLOC_TRACE=mymemory.log
4、 正常运行程序。此时程序中的关于内存分配和释放的操作都可以记录下来。

vector 使用注意事项：

尽量成批reserve一块内存使用。减少在容器已满的情况下仍然push_back单个元素的操作，这样非常容易产生碎片。

即使是在栈上分配一个std::vector（意味着出栈即被回收），也要注意它维护的队列是分配在heap上的。即这样的临时对象所操作过的内存，依然可能产生碎片。如果这样的函数被频繁调用，碎片就会非常多。

即使我们做过shrink_to_fit的工作（std::vector<t*>(v).swap(v)），如果里面是碎片，那也会被驻留在brk维护的free_list中，不会被释放。