在 Linux 操作系統的廣袤天地里，內存管理宛如一場精密的舞蹈，而 malloc 函數無疑是其中最為關鍵的舞者。當我們編寫 C 或 C++ 程序時，常常會遇到需要在運行時動態分配內存的情況，比如創建一個大小不確定的數組，或者構建復雜的數據結構。

此時，malloc 就像一位神奇的工匠，為我們打造出所需的內存空間。它允許程序在運行過程中根據實際需求靈活地獲取內存，大大增強了程序的適應性和靈活性。但你是否曾好奇，malloc 究竟是如何在幕后運作，精準地分配出我們所需的內存呢？接下來，就讓我們一同揭開 malloc 的神秘面紗，深入探尋其內存分配的奧秘。

一、Malloc基礎入門

1.1malloc 函數簡介

在 C 語言的標準庫中，malloc 函數如同一位神秘的工匠，為程序提供著動態內存分配的關鍵服務。它的定義簡潔而有力：void *malloc(size_t size); ，這個函數接受一個參數 size，用于指定需要分配的內存字節數。其返回值是一個指向所分配內存起始地址的指針 ，類型為 void*，這意味著它可以被轉換為任何類型的指針，以適應不同的數據存儲需求。

malloc 函數在動態內存分配領域占據著核心地位。當我們在編寫程序時，常常會遇到一些場景，比如需要處理用戶輸入的數據，但在程序編寫階段并不知道數據的具體大小；或者構建動態的數據結構，如鏈表、樹等，這些結構的節點數量會隨著程序的運行而動態變化。在這些情況下，靜態內存分配就顯得力不從心，而 malloc 函數則能夠在程序運行時，根據實際需求靈活地分配內存，使得程序能夠高效地處理各種復雜的情況。

1.2與操作系統的關系

雖然 malloc 函數在 C 庫中扮演著重要角色，但它并非直接與操作系統的底層內存管理機制打交道。在 Linux 系統中，malloc 函數是通過 glibc（GNU C Library）來實現的，glibc 作為一個功能強大的 C 庫，為程序員提供了豐富的函數和工具，malloc 便是其中之一。

當我們在程序中調用 malloc 函數時，它會首先在 glibc 維護的內存池中查找是否有足夠的空閑內存來滿足請求。如果內存池中有足夠的空閑內存，malloc 函數會直接從內存池中分配內存，并返回相應的指針。這樣做的好處是可以減少系統調用的開銷，提高內存分配的效率。因為系統調用涉及到用戶態和內核態的切換，這種切換會帶來一定的性能損耗。

然而，如果內存池中的空閑內存不足以滿足請求，malloc 函數就會借助系統調用與操作系統進行交互。在 Linux 系統中，主要涉及到兩個系統調用：brk和mmap 。brk系統調用通過移動程序數據段的結束地址（即 “堆頂” 指針）來增加堆的大小，從而分配新的內存。而mmap系統調用則是通過在文件映射區域分配一塊內存來滿足請求。通常情況下，當請求的內存大小小于一定閾值（在大多數系統中，這個閾值通常為 128KB）時，malloc 函數會優先使用brk系統調用來分配內存；當請求的內存大小大于這個閾值時，則會使用mmap系統調用。通過這種方式，malloc 函數能夠根據不同的內存需求，選擇最合適的方式與操作系統進行交互，實現高效的內存分配。

二、Malloc函數的實現原理

2.1空閑鏈表機制

在malloc函數背后，有著依靠空閑鏈表來管理內存的一套機制。當我們調用malloc函數時，它會沿著空閑鏈表去查找滿足用戶請求大小的內存塊。比如說，鏈表上有多個不同大小的空閑內存塊，它就會依次遍歷這些塊來找到合適的那一個。

找到合適的內存塊后，如果這個內存塊比用戶請求的大小要大，那么就會按需將其分割成兩部分，一部分的大小剛好與用戶請求的大小相等，這部分就會分配給用戶使用，而剩下的那部分則會被放回空閑鏈表中，等待后續其他的內存分配請求再進行分配。例如，空閑鏈表中有一個 50 字節的空閑塊，而用戶請求分配 20 字節的內存，這時malloc就會把這個 50 字節的塊分成 20 字節（分配給用戶）和 30 字節（放回空閑鏈表）兩塊。

而當我們使用free函數釋放內存時，相應被釋放的內存塊又會被重新連接到空閑鏈上。這樣，整個空閑鏈表就處于一個動態變化的過程，不斷地有內存塊被分配出去，也不斷地有釋放的內存塊回歸鏈表，以實現內存的循環利用，避免浪費。不過，隨著程序不斷地分配和釋放內存，空閑鏈有可能會被切成很多的小內存片段，要是后續用戶申請一個較大的內存片段時，空閑鏈上可能暫時沒有可以滿足要求的片段了，這時malloc函數可能就需要進行一些整理操作，比如對這些小的空閑塊嘗試合并等，以便能滿足較大內存請求的情況。

虛擬內存地址和物理內存地址

為了簡單，現代操作系統在處理物理內存地址時，普遍采用虛擬內存地址技術。即在匯編程序層面，當涉及內存地址時，都是使用的虛擬內存地址。采用這種技術時，每個進程仿佛自己獨享一片2N字節的內存，其中N是機器位數。例如在64位CPU和64位操作系統下每個進程的虛擬地址空間為264Byte。

這種虛擬地址空間的作用主要是簡化程序的編寫及方便操作系統對進程間內存的隔離管理，真實中的進程不太可能如此大的空間，實際能用到的空間大小取決于物理內存的大小。由于在機器語言層面都是采用虛擬地址，當實際的機器碼程序涉及到內存操作時，需要根據當前進程運行的實際上下文將虛擬地址轉化為物理內存地址，才能實現對內存數據的操作。這個轉換一般由一個叫MMU的硬件完成。

頁與地址構成

在現代操作系統中，不論是虛擬內存還是物理內存，都不是以字節為單位進行管理的，而是以頁為單位。一個內存頁是一段固定大小的連續的連續內存地址的總稱，具體到Linux中，典型的內存頁大小為4096 Byte。所以內存地址可以分為頁號和頁內偏移量。下面以64位機器，4G物理內存，4K頁大小為例，虛擬內存地址和物理內存地址的組成如下：

圖片

上面是虛擬內存地址，下面是物理內存地址。由于頁大小都是4k，所以頁內偏移都是用低12位表示，而剩下的高地址表示頁號 MMU映射單位并不是字節，而是頁，這個映射通過差一個常駐內存的數據結構頁表來實現。現在計算機具體的內存地址映射比較復雜，為了加快速度會引入一系列緩存和優化，例如TLB等機制，下面給出一個經過簡化的內存地址翻譯示意圖：

圖片

內存頁與磁盤頁

我們知道一般將內存看做磁盤的緩存，有時MMU在工作時，會發現頁表表名某個內存頁不在物理內存頁不在物理內存中，此時會觸發一個缺頁異常，此時系統會到磁盤中相應的地方將磁盤頁載入到內存中，然后重新執行由于缺頁而失敗的機器指令。關于這部分，因為可以看做對malloc實現是透明的，所以不再詳述。

真實地址翻譯流程：

圖片

Linux進程級內存管理

內存排布：明白了虛擬內存和物理內存的關系及相關的映射機制，下面看一下具體在一個進程內是如何排布內存的。以Linux 64位系統為例。理論上，64bit內存地址空間為0x0000000000000000-0xFFFFFFFFFFFFFFF，這是個相當龐大的空間，Linux實際上只用了其中一小部分。具體分布如圖所示：

圖片

對用戶來說主要關心的是User Space。將User Space放大后，可以看到里面主要分成如下幾段：

• Code：這是整個用戶空間的最低地址部分，存放的是指令（也就是程序所編譯成的可執行機器碼） Data：這里存放的是初始化過的全局變量
• BSS：這里存放的是未初始化的全局變量
• Heap：堆，這是我們本文主要關注的地方，堆自底向上由低地址向高地址增長
• Mapping Area：這里是與mmap系統調用相關區域。大多數實際的malloc實現會考慮通過mmap分配較大塊的內存空間，本文不考慮這種情況，這個區域由高地址像低地址增長Stack:棧區域，自高地址像低地址增長 。
• Heap內存模型：一般來說，malloc所申請的內存主要從Heap區域分配，來看看Heap的結構是怎樣的。

圖片

Linux維護一個break指針，這個指針執行堆空間的某個地址，從堆開始到break之間的地址空間為映射好的，可以供進程訪問，而從break往上，是未映射的地址空間，如果訪問這段空間則程序會報錯。

2.2在操作系統中的實現

以常見的操作系統為例，malloc函數需要通過系統調用來從內核申請內存，像brk（用于堆內存）或者mmap（用于內存映射）就是常用的手段。

對于brk系統調用，它主要的作用是調整堆頂的位置，使得堆內存可以從低地址向高地址增長，以此來擴大進程在運行時的堆大小。一般來說，如果分配的內存小于 128K 時，就常常會使用brk調用來獲得虛擬內存。比如在一些小型的數據結構動態分配場景中，brk就能很好地滿足需求。當使用brk分配了一段新的虛擬內存區域后，要注意這并不會立即分配物理內存哦，實際的物理內存分配通常是在訪問新分配的虛擬內存區域時，如果發生了缺頁異常，操作系統才會開始分配并映射相應的物理內存頁面。

而mmap系統調用則是在進程的虛擬地址空間中尋找一塊空閑的虛擬內存，從而獲得一塊可以操作的堆內存，當需要分配較大塊的內存（通常大于 128K 時），就會更多地借助mmap來完成申請操作。一旦通過mmap建立了內存映射關系，進程就可以通過指針的方式來讀寫這塊內存了，并且系統會自動將臟頁（被修改的頁）回寫到相應的磁盤文件上。

在內存分配程序初始化時，要完成諸如將分配程序標識為已經初始化，找到系統中最后一個有效內存地址，然后建立起指向管理的內存的指針等操作，這些都是為了后續能更好地追蹤要分配和回收哪些內存。在整個過程中，會不斷地去記錄內存的分配和回收情況，比如哪些內存塊已經分配出去被使用了，哪些又被釋放回到了可分配的狀態等，通過這些精細的管理，才能讓內存資源在程序運行過程中得到合理的調配。

⑴brk與sbrk

由上文知道，要增加一個進程實際上的可用堆大小，就需要將break指針向高地址移動。Linux通過brk和sbrk系統調用操作break指針。兩個系統調用的原型如下：

int brk(void *addr);
void *sbrk(inptr_t increment);

brk將break指針直接設置為某個地址，而sbrk將break從當前位置移動increment所指定的增量。brk在執行成功時返回0，否則返回-1并設置為errno為ENOMEM,sbrk成功時返回break移動之前所指向的地址，否則返回（void*）-1;

⑵資源限制和rlimirt

系統為每一個進程所分配的資源不是無限的，包括可映射的空間，因此每個進程有一個rlimit表示當前進程可用的資源上限，這個限制可以通過getrlimit系統調用得到，下面代碼獲取當前進程虛擬內存空間的rlimit 其中rlimt是一個結構體

struct rlimit
{
    rlimt_t rlim_cur;
    rlim_t rlim_max;
};

每種資源有硬限制和軟限制，并且可以通過setrlimit對rlimit進行有條件限制作為軟限制的上限，非特權進程只能設置軟限制，且不能超過硬限制

2.3ptmalloc 工作原理

在涉及ptmalloc模塊的情況下，先來了解一下它的軟件架構。ptmalloc中有幾個關鍵概念，比如malloc_state、malloc_chunk等。

malloc_state結構用于統一管理內存分配相關的諸多信息，它里面包含了像fastbinsY（這是用于存儲 16 - 160 字節chunk的空閑鏈表）、top（代表著頂部的內存塊，也就是當其他空閑鏈表中沒有匹配的chunk分配給用戶程序時，會從這里裁剪出可用的chunk分配給用戶）、bins（又可細分為unsortedbins、smallbins、largebins，unsortedbins是chunk緩存區，用于存儲從fastbins合并的空閑chunk；smallbins用于存儲 32 - 1024 字節的chunk；largebins則用于存儲大于 1024 字節大小的空閑chunk）以及binmap（可用bins位圖，方便快速查找可用的bin）等重要成員。

而malloc_chunk則是以其為單位來進行內存的申請和釋放操作。每個malloc_chunk結構體中有記錄前一個chunk大小的mchunk_prev_size成員、表示當前chunk大小的mchunk_size成員，還有像fd（鏈表后驅指針）、bk（鏈表前驅指針）等指針成員（當chunk處于空閑狀態時，會借助內存區域前 16 個字節作為鏈表指針，將chunk插入到相應的空閑鏈表中）。

在內存管理方面，不同大小的內存塊有著不同的管理方式。對于小于 160 字節的內存申請，malloc函數會從fastbins空閑鏈表中查找匹配的chunk進行分配；對于 32 - 1024 字節的內存請求，就會去smallbins中尋找合適的空閑chunk；大于 1024 字節的則在largebins里查找。

當用戶申請內存時，malloc會按照對應的大小范圍去相應的鏈表中尋找可用的chunk，找到就分配給用戶使用。而當用戶釋放內存時，釋放的chunk會依據其大小等情況，被合理地放回fastbins、bins等相應的鏈表中，比如從smallbins中釋放的chunk可能會先進入unsortedbins緩存，后續再根據具體情況進行合并或者重新分配等操作，以此來維持整個內存分配和回收體系的高效、有序運行。

三、內存分配方式

3.1brk 系統調用分配內存

brk 原理剖析：在 Linux 系統中，進程的內存空間布局包含多個段，其中堆（heap）是用于動態內存分配的重要區域。brk 系統調用的核心原理是通過移動堆頂指針（_edata）來擴大堆的空間。當程序調用 brk 系統調用并傳入一個新的地址時，如果這個新地址大于當前堆頂指針的位置，內核會嘗試將堆頂指針移動到新的地址，從而擴大堆的范圍。

在這個過程中，有一個關鍵的概念需要理解，那就是虛擬內存與物理內存的映射關系。當 brk 系統調用擴大堆空間時，實際上只是分配了虛擬內存，并沒有立即分配物理內存。這種映射是延遲的，直到程序第一次訪問新分配的虛擬內存區域時，才會觸發缺頁中斷（page fault） 。此時，操作系統會負責分配物理內存，并建立虛擬內存與物理內存之間的映射關系。這一機制有效地提高了內存使用效率，避免了過早分配物理內存造成的浪費。

小內存分配示例：假設我們在程序中調用malloc函數申請一塊小于 128KB 的內存，例如申請 30KB 的內存。在這種情況下，malloc函數通常會調用 brk 系統調用來完成內存分配。

當程序執行到malloc(30 * 1024)時，malloc函數會向內核發起 brk 系統調用。內核接收到這個調用后，會檢查當前堆頂指針的位置，假設當前堆頂指針為_edata，其值為 0x10000000。內核會將_edata指針向高地址方向移動 30KB，即移動到 0x10007800（30 * 1024 = 30720，十六進制表示為 0x7800）。此時，從 0x10000000 到 0x10007800 這一段虛擬內存空間就被分配給了程序。

需要注意的是，雖然虛擬內存已經分配，但在程序第一次訪問這部分內存之前，并沒有實際的物理內存與之對應。例如，如果程序執行*(int*)0x10000000 = 10; ，這是對新分配內存的第一次訪問，此時會觸發缺頁中斷。操作系統捕獲到這個缺頁中斷后，會為該虛擬內存頁分配物理內存頁，并建立兩者之間的映射關系，然后程序才能繼續正常執行。

這種分配方式在處理小內存分配時具有一定的優勢，它相對簡單高效，減少了系統調用的開銷。但也存在一些潛在的問題，例如隨著內存的頻繁分配和釋放，可能會導致堆內存中出現大量的碎片，降低內存的利用率。

3.2mmap 系統調用分配內存

mmap 原理闡述：mmap 系統調用是另一種重要的內存分配方式，它與 brk 系統調用有著本質的區別。mmap 系統調用主要用于在文件映射區域分配內存，它通過在進程的虛擬地址空間中（堆和棧中間，稱為文件映射區域的地方）找一塊空閑的虛擬內存來滿足內存分配請求。

具體來說，mmap 系統調用可以創建一個新的虛擬內存區域，并將一個文件或設備的內容映射到這個區域中。當用于內存分配時，通常會使用私有匿名映射（private anonymous mapping） ，即創建一個匿名的虛擬內存區域，這個區域與任何文件都沒有關聯，并且對該區域的寫入操作不會影響到其他進程。在這種情況下，mmap 系統調用會在文件映射區域中找到一塊合適的空閑虛擬內存，并將其分配給調用者。

與 brk 系統調用不同，mmap 系統調用分配的內存是獨立的，它不會與堆內存連續，并且在釋放時可以單獨釋放，不會受到其他內存塊的影響。這使得 mmap 在處理大內存分配和需要頻繁分配和釋放內存的場景中具有明顯的優勢。

大內存分配示例：當程序調用malloc函數申請一塊大于 128KB 的內存時，例如申請 200KB 的內存，malloc函數通常會使用 mmap 系統調用來完成分配。

當程序執行到malloc(200 * 1024)時，malloc函數會向內核發起 mmap 系統調用。內核接收到這個調用后，會在文件映射區域中查找一塊大小為 200KB 的空閑虛擬內存。假設找到的空閑虛擬內存區域起始地址為 0x20000000，內核會將這塊虛擬內存分配給程序。

與 brk 系統調用類似，此時分配的只是虛擬內存，在程序第一次訪問這部分內存時才會觸發缺頁中斷，操作系統會為其分配物理內存并建立映射關系。但與 brk 不同的是，mmap 分配的內存具有更好的獨立性和可管理性。例如，當程序不再需要這塊內存時，調用free函數會直接通過 munmap 系統調用將這塊內存釋放回操作系統，不會影響到其他內存塊的使用，有效地避免了內存碎片的問題。在一些對內存管理要求較高的場景，如數據庫系統、大型游戲開發等，mmap 系統調用的這種優勢能夠顯著提高系統的性能和穩定性。

四、Malloc內存分配策略

4.1閾值設定與分配決策

在 malloc 的源碼世界里，有一個至關重要的閾值設定，它如同一個精密的開關，決定著內存分配的走向。這個閾值通常被設定為 128KB ，成為了 brk 和 mmap 兩種內存分配方式的分水嶺。當我們在程序中調用 malloc 函數申請內存時，它會首先對申請的內存大小進行判斷。

如果申請的內存大小小于 128KB，malloc 函數會傾向于選擇 brk 系統調用來分配內存。這是因為 brk 系統調用在處理小內存分配時具有獨特的優勢，它通過簡單地移動堆頂指針來擴大堆空間，這種方式相對高效，減少了系統調用的開銷，能夠快速地滿足小內存的分配需求。

而當申請的內存大小大于或等于 128KB 時，malloc 函數則會啟用 mmap 系統調用。mmap 系統調用在處理大內存分配時表現出色，它能夠在文件映射區域為程序分配一塊獨立的內存空間。這樣做的好處是可以避免在堆區產生大量的內存碎片，因為 mmap 分配的內存塊在釋放時可以單獨釋放，不會受到其他內存塊的影響，從而提高了內存的利用率和管理效率。

需要注意的是，這個 128KB 的閾值并非一成不變，不同的 glibc 版本可能會根據實際情況對其進行調整。例如，在某些特定的系統環境或應用場景下，為了優化內存分配的性能，glibc 版本可能會將閾值設定為其他值。因此，在深入研究 malloc 的內存分配機制時，我們需要關注具體的 glibc 版本及其配置，以準確把握內存分配的策略和行為。

4.2內存池與預分配機制

在 malloc 的內存分配策略中，內存池與預分配機制起著至關重要的作用，以默認內存管理器 Ptmalloc2 為例，當我們調用 malloc 函數申請內存時，它并非僅僅按照我們請求的字節數來分配內存，而是會預分配更大的空間作為內存池。

以主進程（主線程）下的內存分配為例，當我們申請 1 字節的內存時，Ptmalloc2 會預分配 132KB 的內存，這個預分配的內存區域被稱為 Main Arena。在這個 132KB 的內存池中，Ptmalloc2 會根據后續的內存申請請求，從其中切割出合適大小的內存塊分配給用戶。當用戶釋放內存時，Ptmalloc2 并不會立即將內存歸還給操作系統，而是會根據一些策略來判斷是否釋放。如果不釋放，這塊內存會被重新放回內存池中，供下次申請時使用。這種機制大大提高了內存分配的效率，減少了頻繁向操作系統申請內存的開銷。

在子線程下，內存分配的策略又有所不同。每個子線程會預先分配 HEAP_MAX_SIZE 大小的內存（64 位系統下為 64MB，32 位系統下為 1MB），這被稱為 Thread Arena。并且，單個子線程的內存池數量最大可以達到 8 倍的 CPU 數。雖然這種預分配機制會占用一定的內存空間，但它在多線程環境下能夠顯著加快內存分配的速度，減少線程之間的競爭和等待時間，提高程序的整體性能。

內存池的預分配機制并非完美無缺。在多線程環境下，如果線程數量眾多，每個線程都預分配了大量的內存，可能會導致系統內存資源的緊張。例如，在一個擁有 100 個線程的程序中，每個線程預分配 64MB 的內存，那么僅僅內存池就會占用 6GB 的內存空間。這可能會對系統的其他進程產生影響，甚至導致系統性能下降。因此，在實際應用中，我們需要根據程序的特點和運行環境，合理地調整內存池的預分配策略，以平衡內存使用和性能之間的關系。

五、Free釋放內存機制

5.1brk 方式申請內存的釋放

當我們使用 free 函數釋放通過 brk 方式申請的內存時，內存并不會立即歸還給操作系統。這是因為 brk 系統調用分配的內存是在堆空間中，free 函數將內存釋放后，這塊內存會被緩存在 malloc 的內存池中。這樣做的目的是為了提高內存的復用效率，當程序后續再次申請內存時，如果內存池中有合適大小的空閑內存塊，就可以直接從內存池中分配，而無需再次向操作系統發起 brk 系統調用，從而減少了系統調用的開銷和時間成本。

內存池復用機制在一定程度上提高了內存分配的效率，但也帶來了潛在的內存碎片問題。隨著程序中頻繁地進行內存分配和釋放操作，堆內存中可能會出現許多不連續的空閑內存塊，這些小塊內存由于大小和位置的限制，可能無法滿足后續較大內存分配的需求，從而導致內存利用率降低。例如，假設程序先申請了 10KB、20KB 和 30KB 的三塊內存，然后釋放了 10KB 和 20KB 的內存塊。此時，堆內存中會出現兩個空閑的內存塊，但如果后續需要申請 40KB 的內存，由于這兩個空閑內存塊不連續，無法合并成一個足夠大的內存塊，就會導致雖然堆內存中有空閑空間，但仍然無法滿足分配需求的情況，這就是內存碎片問題的體現。

5.2mmap 方式申請內存的釋放

與 brk 方式不同，當使用 free 函數釋放通過 mmap 方式申請的內存時，內存會立即歸還給操作系統。這是因為 mmap 系統調用分配的內存是在文件映射區域，與堆內存相互獨立。當調用 free 函數時，實際上是通過 munmap 系統調用來取消內存映射，將內存從進程的虛擬地址空間中移除，并將其歸還給操作系統，使得這部分內存可以被其他進程使用。

mmap 方式申請內存的釋放機制使得內存的管理更加靈活和高效，尤其是在處理大內存塊的分配和釋放時，能夠有效地避免內存碎片的產生。例如，在一個需要頻繁分配和釋放大內存塊的程序中，如果使用 brk 方式，隨著內存的不斷分配和釋放，堆內存中很容易產生大量的碎片，導致內存利用率下降。而使用 mmap 方式，每次釋放內存時都能將其完整地歸還給操作系統，不會產生碎片問題，保證了內存的高效利用和系統的穩定性。

六、為何不全部使用 brk 或 mmap

6.1不全部使用 brk 的原因

在內存分配的世界里，brk 系統調用雖然在處理小內存分配時展現出一定的優勢，但如果全部使用 brk 來分配內存，會帶來一系列嚴重的問題。其中最突出的問題便是內存碎片的產生。

讓我們通過一個具體的場景來深入理解這個問題。假設我們有一個程序，它需要頻繁地進行小內存的分配和釋放操作。程序首先通過 brk 系統調用申請了一塊 10KB 的內存，用于存儲一些臨時數據；接著又申請了一塊 20KB 的內存，用于其他任務；隨后再申請一塊 30KB 的內存。此時，堆內存的布局是連續的三塊內存區域，分別為 10KB、20KB 和 30KB。

隨著程序的運行，當不再需要第一塊 10KB 和第二塊 20KB 的內存時，我們調用 free 函數將它們釋放。由于 brk 系統調用分配的內存是在堆空間中，釋放后的內存并不會立即歸還給操作系統，而是緩存在 malloc 的內存池中。這就導致堆內存中出現了兩塊空閑的內存區域，它們分別是 10KB 和 20KB，并且這兩塊空閑內存區域之間被一塊正在使用的 30KB 內存隔開。

當程序后續需要申請一塊 40KB 的內存時，盡管堆內存中總的空閑內存大小是足夠的（10KB + 20KB = 30KB），但由于這兩塊空閑內存不連續，無法合并成一個足夠大的內存塊來滿足 40KB 的分配需求。這樣，就會出現雖然堆內存中有空閑空間，但仍然無法滿足分配需求的情況，這就是典型的內存碎片問題。

隨著程序中這種頻繁的內存分配和釋放操作不斷進行，堆內存中會逐漸產生越來越多這樣不連續的小空閑內存塊，這些內存碎片會占據大量的內存空間，卻無法被有效地利用，導致內存利用率急劇下降。這種情況在一些長時間運行且需要頻繁進行小內存分配和釋放的程序中尤為明顯，例如數據庫管理系統中的緩存模塊、圖形渲染引擎中的資源分配模塊等。如果這些系統全部使用 brk 系統調用進行內存分配，隨著時間的推移，內存碎片問題會越來越嚴重，最終可能導致系統性能大幅下降，甚至出現內存耗盡的錯誤。

6.2不全部使用 mmap 的原因

雖然 mmap 系統調用在處理大內存分配時具有明顯的優勢，能夠有效避免內存碎片問題，但如果全部使用 mmap 來分配內存，同樣會面臨一些嚴重的問題，主要體現在系統調用開銷和缺頁中斷方面。

從系統調用開銷的角度來看，mmap 系統調用涉及到用戶態和內核態的切換，這種切換會帶來一定的性能損耗。當我們在程序中調用 mmap 系統調用時，CPU 需要保存當前用戶態的上下文信息，然后切換到內核態執行 mmap 的相關操作。在內核態完成內存映射等操作后，又需要將上下文信息恢復，切換回用戶態。這個過程需要消耗一定的時間和 CPU 資源，如果頻繁地進行 mmap 系統調用，系統調用的開銷將會顯著增加，導致程序的整體性能下降。

缺頁中斷也是一個不可忽視的問題。當使用 mmap 系統調用分配內存時，雖然虛擬內存會被立即分配，但在程序第一次訪問這些虛擬內存時，會觸發缺頁中斷。這是因為此時物理內存尚未分配，操作系統需要捕獲這個缺頁中斷，為該虛擬內存頁分配物理內存，并建立虛擬內存與物理內存之間的映射關系。如果全部使用 mmap 來分配內存，并且程序頻繁地進行內存分配和訪問操作，那么就會頻繁地觸發缺頁中斷。每一次缺頁中斷都需要操作系統進行一系列的處理操作，這會消耗大量的 CPU 資源，導致 CPU 的利用率升高，程序的執行效率降低。

在一個需要頻繁進行內存分配和釋放的高性能計算程序中，如果全部使用 mmap 系統調用，系統調用的開銷和頻繁的缺頁中斷會使得 CPU 忙于處理這些中斷和上下文切換，而無法專注于程序的核心計算任務，從而導致程序的運行速度大幅減慢，無法滿足高性能計算的需求。因此，在實際的內存分配中，不能全部使用 mmap 系統調用，而是需要根據內存分配的大小和具體的應用場景，合理地選擇 brk 和 mmap 系統調用，以實現高效的內存管理。

七、Malloc使用中的常見問題與注意事項

7.1內存泄漏風險

在使用 malloc 進行內存分配時，內存泄漏是一個需要特別關注的問題。內存泄漏就像是程序中的一個隱藏漏洞，它會逐漸吞噬系統的內存資源，導致程序性能下降，甚至可能引發系統崩潰。在實際的編程中，尤其是在一些復雜的代碼邏輯中，內存泄漏的問題很容易被忽視。

假設我們有一個處理用戶數據的函數，函數內部使用 malloc 分配了一塊內存來存儲用戶輸入的數據。代碼如下：

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void processUserData() {
    char *userInput = (char *)malloc(100);
    if (userInput == NULL) {
        // 處理內存分配失敗的情況
        printf("Memory allocation failed\n");
        return;
    }

    // 模擬獲取用戶輸入
    strcpy(userInput, "Some user data");

    // 假設這里有一些復雜的邏輯處理用戶數據

    // 錯誤示范：忘記釋放內存
    // free(userInput);
}

在這個例子中，processUserData函數使用 malloc 分配了 100 字節的內存來存儲用戶輸入。在函數執行過程中，我們對這塊內存進行了一些操作，比如模擬獲取用戶輸入并存儲到這塊內存中。但是，在函數結束時，我們忘記了調用 free 函數來釋放這塊內存。隨著程序的不斷運行，如果這個函數被頻繁調用，每次調用都會分配新的內存而不釋放舊的內存，那么系統的內存資源會逐漸被耗盡，最終導致內存泄漏。

為了檢測內存泄漏問題，我們可以借助一些工具，如 Valgrind 和 AddressSanitizer。Valgrind 是一款功能強大的內存調試工具，它可以詳細地檢測出程序中的內存泄漏情況，并給出具體的泄漏位置和相關的調用棧信息。使用 Valgrind 非常簡單，只需要在命令行中運行valgrind --leak-check=full your_program，其中your_program是你要檢測的可執行程序。AddressSanitizer 則是一個由 LLVM 和 GCC 支持的內存錯誤檢測工具，它可以在編譯時啟用，通過在代碼中插入一些檢測代碼來實時檢測內存泄漏和其他內存相關的錯誤。在 GCC 中，可以使用-fsanitize=address選項來啟用 AddressSanitizer 進行編譯。

為了避免內存泄漏，我們需要養成良好的編程習慣。在使用 malloc 分配內存后，一定要記得在不再需要這塊內存時調用 free 函數進行釋放。可以在分配內存的地方添加注釋，提醒自己在適當的時候釋放內存。同時，對于一些復雜的函數邏輯，要仔細檢查是否存在分支路徑導致內存沒有被釋放的情況。例如，在上面的processUserData函數中，如果在獲取用戶輸入時發生錯誤，導致函數提前返回，那么之前分配的內存也會泄漏。因此，在可能提前返回的地方，也需要確保釋放已經分配的內存。

7.2訪問已釋放內存

訪問已釋放內存（UAF，Use - After - Free）是一種在內存管理中非常危險的錯誤行為。它指的是程序在使用 free 函數釋放了一塊內存之后，仍然通過指向這塊內存的指針來訪問它。這種錯誤就像是在拆除了一座房子后，還試圖進入房子里尋找東西，其結果是不可預測的，可能會導致程序崩潰、數據損壞，甚至引發安全漏洞，讓攻擊者有機會執行惡意代碼。

當我們使用 brk 系統調用分配內存時，假設我們有以下代碼：

#include <stdio.h>
#include <stdlib.h>

int main() {
    char *ptr = (char *)malloc(100);
    if (ptr == NULL) {
        printf("Memory allocation failed\n");
        return 1;
    }

    // 使用ptr指向的內存
    strcpy(ptr, "Some data");
    printf("Data: %s\n", ptr);

    // 釋放內存
    free(ptr);

    // 錯誤示范：訪問已釋放的內存
    printf("Data after free: %s\n", ptr);

    return 0;
}

在這段代碼中，我們首先使用 malloc 分配了 100 字節的內存，并將其賦值給指針ptr。然后，我們在這塊內存中存儲了一些數據并打印出來。接著，我們調用 free 函數釋放了這塊內存。然而，在釋放內存之后，我們又試圖通過ptr指針來訪問這塊已經被釋放的內存，并打印其中的數據。由于內存已經被釋放，ptr指向的內存區域已經不再屬于我們的程序，此時訪問這塊內存會導致未定義行為。在某些情況下，程序可能會崩潰，提示段錯誤（Segmentation fault）；而在另一些情況下，可能會打印出一些隨機的數據，因為這塊內存可能已經被操作系統重新分配給其他程序使用，其內容已經被修改。

如果是通過 mmap 系統調用分配內存，同樣會出現類似的問題。例如：

#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>

int main() {
    int fd = open("test.txt", O_RDWR | O_CREAT, 0666);
    if (fd == -1) {
        perror("open");
        return 1;
    }

    // 擴展文件大小
    if (lseek(fd, 100 - 1, SEEK_SET) == -1) {
        perror("lseek");
        close(fd);
        return 1;
    }
    if (write(fd, "", 1) == -1) {
        perror("write");
        close(fd);
        return 1;
    }

    char *ptr = (char *)mmap(0, 100, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
    if (ptr == MAP_FAILED) {
        perror("mmap");
        close(fd);
        return 1;
    }

    // 使用ptr指向的內存
    strcpy(ptr, "Some data");
    printf("Data: %s\n", ptr);

    // 釋放內存
    if (munmap(ptr, 100) == -1) {
        perror("munmap");
        close(fd);
        return 1;
    }

    // 錯誤示范：訪問已釋放的內存
    printf("Data after free: %s\n", ptr);

    close(fd);
    return 0;
}

在這個例子中，我們通過 mmap 系統調用將文件映射到內存中，并獲取了一個指向映射內存區域的指針ptr。在使用完內存后，我們調用 munmap 函數釋放了這塊內存。但之后又試圖訪問已經釋放的內存，這同樣會導致未定義行為。與 brk 方式不同的是，mmap 分配的內存通常與文件映射相關，訪問已釋放的 mmap 內存可能會導致更復雜的問題，比如影響文件系統的一致性，因為文件映射的內存與文件的內容是關聯的。如果在釋放后還繼續訪問，可能會導致文件內容被錯誤地修改，從而引發數據損壞的問題。