请注意，本文编写于 1072 天前，最后修改于 276 天前，其中某些信息可能已经过时。
In the man page of
malloc, there(NOTES section) is a paragraph as follows:
Normally, malloc() allocates memory from the heap, and adjusts the size of the heap as required, using sbrk(2). When allocating blocks of memory larger than MMAP_THRESHOLD bytes, the glibc malloc() implementation allocates the memory as a private anonymous mapping using mmap(2). MMAP_THRESHOLD is 128 kB by default, but is adjustable using mallopt(3). Prior to Linux 4.7 allocations performed using mmap(2) were unaffected by the RLIMIT_DATA resource limit; since Linux 4.7, this limit is also enforced for allocations performed using mmap(2).
So when you apply for more than
MMAP_THRESHOLD of space,
malloc() will call
Someone asked three
mmap() when apply for large space?
Is there some difference between
mmap cause a context switching?
Anonymous pages applied by
mmap will be freed by
glibc does this kind of works. As for small space,
free will release it to the process's heap. So it will still belongs to the process. But
munmap will release the space to the os.
mmap won't allocate pages immediately. They will be allocated the first time they are accessed, when kernel must erase them to zero, intending to avoid leakage of information between processes.
It won't cause context switching when called. But it will eventually cause one. Specifically, mmap is a non-blocking system call. When you
mmap a file on disk to memory,
mmap just create a map and not allocate pages immediately.