整理的參考文獻，記不清了

1 背景簡介

出現疑似”內存泄露”問題： malloc申請的內存，free釋放以后沒有歸還操作系統，比如內存模塊占用的內存為10GB，釋放內存以后，通過TOP命令或者/proc/pid/status查看占用的內存有時仍然為10G，有時為5G，有時為3G, etc，內存釋放的行為不確定。

2 malloc()/free(), mmap(), brk(), 用戶程序-->glibc -->linux kernel之間的關系

1） malloc()/free() 是C語言中常用的兩個內存 分配/釋放 函數，但是ANSI C并沒有指定它們具體應該如何實現。因此在各個系統級平臺上（windows, mac, linux等等），函數的底層的內存操縱方式并不一樣。
2） 在linux下，malloc()/free()的實現是由 ?glibc庫 負責，它會根據一定的策略與系統底層通信（調用系統API），所以，用戶程序并不會直接和linux kernel進行交互，而是交由glibc托管，提供默認的內存管理器。關系為：用戶程序 ---->glibc---->linux kernel。
3） glibc使用了 ptmalloc 作為其內存管理器的實現。

* brk分配的內chunk list，只能從top開始線性向下釋放。中間釋放掉的chunk，無法歸還給OS，而是鏈入到了bins/fast bins的容器中。

* mmap分配的內存，等于直接從物理內存中映射了一塊過來,釋放這塊內存時，可以直接歸還給OS。

* 對于request的一塊內存，到底是由brk分配，還是由mmap分配，這是由glibc策略機制決定的。 有個threshold，可以調節這種策略，默認小于threshold由brk分配，大于等于則由mmap分配, threshold默認為128kb。glibc具體從那個版本開始支持動態調節threshold需要調查。默認下，在64位系統上，brk可以動態調整到從 128kb到32mb。調整策略基本可以概括為：發現對頂可以release的可用內存超過256kb的話，就將threshold調整到256kb，依次類推直到32mb.

glibc使用的兩種用戶程序內存管理機制，考慮了與系統底層通信代價，如果直接操縱大量小塊內存，頻繁地與系統調用進行通信，會降低程序的運行效率。將小塊內存放入brk維護的堆中，等于實現了一 塊緩存（cache），用完了可以先攢起來，到時候可以一起歸還給系統。但是由于它的實現，只維護了堆頂的一個指針。因此想要內存歸還系統，必須從頂向下，依次歸還。在這種機制下，如果堆頂有塊內存一直被占用，底下所有內存雖然都已經沒用了，但是這種設計決定內存此時不可以還給系統，因此出現了“洞（Hole）”的問題。這種設計對一些由于業務需求，頻繁申請/釋放小塊內存的用戶程序而言，問題會比較突出。雖然glibc制定了這種有些“強硬”的內存管理方案，但是也提供了一些方法允許調節相關閾值（threshold），雖然不能干涉管理內存，但可以通過這些方法，決定“多大算大，多小算小”以及“攢到多少就歸還”等這類問題。

3 mallopt() 與 malloc_trim(0)

1） mallopt是一個專門調節相關閾值的函數

URL: http://man7.org/linux/man-pages/man3/mallopt.3.html

#include < malloc.h > int mallopt(int param, int value);M_MMAP_THRESHOLD For allocations greater than or equal to the limit specified (in bytes) by M_MMAP_THRESHOLD that can't be satisfied from the free list, the memory-allocation functions employ mmap(2) instead of increasing the program break using sbrk(2).Allocating memory using mmap(2) has the significant advantage that the allocated memory blocks can always be independently released back to the system. (By contrast, the heap can be trimmed only if memory is freed at the top end.) On the other hand, there are some disadvantages to the use of mmap(2): deallocated space is not placed on the free list for reuse by later allocations; memory may be wasted because mmap(2) allocations must be page-aligned; and the kernel must perform the expensive task of zeroing out memory allocated via mmap(2). Balancing these factors leads to a default setting of 128*1024 for the M_MMAP_THRESHOLD parameter. The lower limit for this parameter is 0. The upper limit is DEFAULT_MMAP_THRESHOLD_MAX: 512x1024 on 32-bit systems or 4x1024x1024xsizeof(long) on 64-bit systems.Note: Nowadays, glibc uses a dynamic mmap threshold by default. The initial value of the threshold is 128x1024, but when blocks larger than the currentthreshold and less than or equal to DEFAULT_MMAP_THRESHOLD_MAX are freed, the threshold is adjusted upwards to the size of the freed block.When dynamic mmap thresholding is in effect, the threshold for trimming the heap is also dynamically adjusted to be twice the dynamic mmap threshold.Dynamic adjustment of the mmap threshold is disabled if any of the M_TRIM_THRESHOLD, M_TOP_PAD, M_MMAP_THRESHOLD, or M_MMAP_MAX parameters is set.

The mallopt() function adjusts parameters that control the behavior of the memory-allocation functions (see malloc(3)). The param argument specifies the parameter to be modified, and value specifies the new value for that parameter.

The following values can be specified for param:

M_CHECK_ACTION

Setting this parameter controls how glibc responds when various kinds of programming errors are detected (e.g., freeing the same pointer twice). The 3 least significant bits (2, 1, and 0) of the value assigned to this parameter determine the glibc behavior, as follows:

Bit 0 If this bit is set,

then print a one-line message on stderr that provides details about the error. The message starts with the string "*** glibc detected ***", followed by the program name, the name of the memory-allocation function in which the error was detected, a brief description of the error, and the memory address where the error was detected.

Bit 1 If this bit is set,

then, after printing any error message specified by bit 0, the program is terminated by calling abort(3). In glibc versions since 2.4, if bit 0 is also set, then, between printing the error message and aborting, the program also prints a stack trace in the manner of backtrace(3), and prints the process's memory mapping in the style of /proc/[pid]/maps (see proc(5)).

Bit 2 (since glibc 2.4),

This bit has an effect only if bit 0 is also set. If this bit is set, then the one-line message describing the error is simplified to contain just the name of the function where the error was detected and the brief description of the error.

The remaining bits in value are ignored.

Combining the above details, the following numeric values are meaningful for M_CHECK_ACTION:

0 Ignore error conditions; continue execution (with undefined results).
1 Print a detailed error message and continue execution.
2 Abort the program.
3 Print detailed error message, stack trace, and memorymappings, and abort the program.
5 Print a simple error message and continue execution.
7 Print simple error message, stack trace, and memory mappings, and abort the program.

Since glibc 2.3.4, the default value for the M_CHECK_ACTION parameter is 3. In glibc version 2.3.3 and earlier, the default value is 1. Using a nonzero M_CHECK_ACTION value can be useful because otherwise a crash may happen much later, and the true cause of the problem is then very hard to track down.

M_MMAP_MAX

This parameter specifies the maximum number of allocation requests that may be simultaneously serviced using mmap(2). This parameter exists because some systems have a limited number of internal tables for use by mmap(2), and using more than a few of them may degrade performance.

The default value is 65,536, a value which has no special significance and which servers only as a safeguard. Setting this parameter to 0 disables the use of mmap(2) for servicing large allocation requests.

M_MMAP_THRESHOLD

For allocations greater than or equal to the limit specified (in bytes) by M_MMAP_THRESHOLD that can't be satisfied from the free list, the memory-allocation functions employ mmap(2) instead of increasing the program break using sbrk(2).

Allocating memory using mmap(2) has the significant advantage that the allocated memory blocks can always be independently released back to the system. (By contrast, the heap can be trimmed only if memory is freed at the top end.) On the other hand, there are some disadvantages to the use of mmap(2): deallocated space is not placed on the free list for reuse by later allocations; memory may be wasted because mmap(2) allocations must be page-aligned; and the kernel must perform the expensive task of zeroing out memory allocated via mmap(2). Balancing these factors leads to a default setting of 128*1024 for the M_MMAP_THRESHOLD parameter. The lower limit for this parameter is 0. The upper limit is DEFAULT_MMAP_THRESHOLD_MAX: 512*1024 on 32-bit systems or 4*1024*1024*sizeof(long) on 64-bit systems. Note: Nowadays, glibc uses a dynamic mmap threshold by default. The initial value of the threshold is 128*1024, but when blocks larger than the current threshold and less than or equal to DEFAULT_MMAP_THRESHOLD_MAX are freed, the threshold is adjusted upward to the size of the freed block. When dynamic mmap thresholding is in effect, the threshold for trimming the heap is also dynamically adjusted to be twice the dynamic mmap threshold. Dynamic adjustment of the mmap threshold is disabled if any of the M_TRIM_THRESHOLD, M_TOP_PAD, M_MMAP_THRESHOLD, or M_MMAP_MAX parameters is set.

M_MXFAST (since glibc 2.3)

Set the upper limit for memory allocation requests that are satisfied using "fastbins". (The measurement unit for this parameter is bytes.) Fastbins are storage areas that hold deallocated blocks of memory of the same size without merging adjacent free blocks. Subsequent reallocation of blocks of the same size can be handled very quickly by allocating from the fastbin, although memory fragmentation and the overall memory footprint of the program can increase. The default value for this parameter is 64*sizeof(size_t)/4 (i.e., 64 on 32-bit architectures). The range for this parameter is 0 to 80*sizeof(size_t)/4. Setting M_MXFAST to 0 disables the use of fastbins.

M_PERTURB (since glibc 2.4)

If this parameter is set to a nonzero value, then bytes of allocated memory (other than allocations via calloc(3)) are initialized to the complement of the value in the least significant byte of value, and when allocated memory is released using free(3), the freed bytes are set to the least significant byte of value. This can be useful for detecting errors where programs incorrectly rely on allocated memory being initialized to zero, or reuse values in memory that has already been freed.

M_TOP_PAD

This parameter defines the amount of padding to employ when calling sbrk(2) to modify the program break. (The measurement unit for this parameter is bytes.) This parameter has an effect in the following circumstances:

• When the program break is increased, then M_TOP_PAD bytes are added to the sbrk(2) request.
• When the heap is trimmed as a consequence of calling free(3) (see the discussion of M_TRIM_THRESHOLD) this much free space is preserved at the top of the heap.

In either case, the amount of padding is always rounded to a system page boundary. Modifying M_TOP_PAD is a trade-off between increasing the number of system calls (when the parameter is set low) and wasting unused memory at the top of the heap (when the parameter is set high). The default value for this parameter is 128*1024.

M_TRIM_THRESHOLD

When the amount of contiguous free memory at the top of the heap grows sufficiently large, free(3) employs sbrk(2) to release this memory back to the system. (This can be useful in programs that continue to execute for a long period after freeing a significant amount of memory.) The M_TRIM_THRESHOLD parameter specifies the minimum size (in bytes) that this block of memory must reach before sbrk(2) is used to trim the heap.

The default value for this parameter is 128*1024. Setting M_TRIM_THRESHOLD to -1 disables trimming completely. Modifying M_TRIM_THRESHOLD is a trade-off between increasing the number of system calls (when the parameter is set low) and wasting unused memory at the top of the heap (when the parameter is set high).

Environment variables

A number of environment variables can be defined to modify some of the same parameters as are controlled by mallopt(). Using these variables has the advantage that the source code of the program need not be changed. To be effective, these variables must be defined before the first call to a memory-allocation function. (If the same parameters are adjusted via mallopt(), then the mallopt() settings take precedence.) For security reasons, these variables are ignored in set-user-ID and set-group-ID programs.

The environment variables are as follows (note the trailing underscore at the end of the name of each variable):

MALLOC_CHECK_

This environment variable controls the same parameter as mallopt() M_CHECK_ACTION. If this variable is set to a nonzero value, then a special implementation of the memory- allocation functions is used. (This is accomplished using the malloc_hook(3) feature.) This implementation performs additional error checking, but is slower than the standard set of memory-allocation functions. (This implementation does not detect all possible errors; memory leaks can still occur.)

The value assigned to this environment variable should be a single digit, whose meaning is as described for M_CHECK_ACTION. Any characters beyond the initial digit are ignored. For security reasons, the effect of MALLOC_CHECK_ is disabled by default for set-user-ID and set-group-ID programs. However, if the file /etc/suid-debug exists (the content of the file is irrelevant), then MALLOC_CHECK_ also has an effect for set-user-ID and set-group-ID programs.

MALLOC_MMAP_MAX_

Controls the same parameter as mallopt() M_MMAP_MAX.

MALLOC_MMAP_THRESHOLD_

Controls the same parameter as mallopt() M_MMAP_THRESHOLD.

MALLOC_PERTURB_

Controls the same parameter as mallopt() M_PERTURB.

MALLOC_TRIM_THRESHOLD_

Controls the same parameter as mallopt() M_TRIM_THRESHOLD.

MALLOC_TOP_PAD_

Controls the same parameter as mallopt() M_TOP_PAD.

2） malloc_trim()

負責告訴glibc在brk維護的堆隊列中，堆頂留下多少的空余空間（free space），其他往上的空余空間全部歸還給系統。它不能歸還除堆頂之外的內存。

URL: http://man7.org/linux/man-pages/man3/malloc_trim.3.html

#include <malloc.h>int malloc_trim(size_t pad);

The malloc_trim () function attempts to release free memory at the top of the heap (by calling ?sbrk(2) with a suitable argument).

The pad argument specifies the amount of free space to leave untrimmed at the top of the heap. If this argument is 0, only the minimum amount of memory is maintained at the top of the heap (i.e., one page or less). A nonzero argument can be used to maintain some trailing space at the top of the heap in order to allow future allocations to be made without having to extend the heap with ?sbrk(2) .

4 解決方法

從操作系統的角度看，進程的內存分配由兩個系統調用完成：brk和mmap。brk是將數據段(.data)的最高地址指針 _edata往高地址推，mmap是在進程的虛擬地址空間中找一塊空閑的。其中，mmap分配的內存由munmap釋放，內存釋放時將立即歸還操作系統； 而brk分配的內存需要等到高地址內存釋放以后才能釋放。 也就是說，如果先后通過brk申請了A和B兩塊內存，在B釋放之前，A是不可能釋放的，仍然被進程占用，通過TOP查看疑似”內存泄露”。默認情況下，大 于等于128KB的內存分配會調用mmap/mummap，小于128KB的內存請求調用sbrk（可以通過設置M_MMAP_THRESHOLD來調 整）。Glibc的：M_MMAP_THRESHOLD可以動態調整。M_MMAP_THRESHOLD的值在128KB到32MB(32位機)或者64MB(64位機)之間動態調整，每次申請并釋放一個大小為2MB的內存后，M_MMAP_THRESHOLD的值被調整為2M到2M + 4K之間的一個值. 例如：

char* no_used = new char[2 * 1024 * 1024]; memset(no_used, 0xfe, 2 * 1024 * 1024); delete[] no_used;

這樣,M_MMAP_THRESHOLD的值調整為2M到2M + 4K之間的一個值，后續申請 <= 2 * 1024 * 1024的內存塊都會走sbrk而不是mmap，而sbrk需要等到高地址內存釋放以后低地址內存才能釋放。

可以顯式設置M_MMAP_THRESHOLD或者 M_MMAP_MAX來關閉M_MMAP_THRESHOLD動態調整的特性，從而避免上述問題。

當然，mmap調用是會導致進程產生缺頁中斷的，為了提高性能，常見的做法如下：

1) 將動態內存改為靜態，比如采用內存池技術或者啟動的時候給每個線程分配一定大小，比如8MB的內存，以后直接使用；

2) 禁止mmap內存調用，禁止Glibc內存縮緊將內存歸還系統，Glibc相當于實現了一個內存池功能。只需要在進程啟動的時候加入兩行代碼：

mallopt(M_MMAP_MAX, 0); // 禁止malloc調用mmap分配內存

mallopt(M_TRIM_THRESHOLD, 0); // 禁止內存縮進，sbrk申請的內存釋放后不會歸還給操作系統

總結

以上是生活随笔為你收集整理的Linux下glibc内存管理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。