C語言記憶體管理深度解析：棧、堆與常見陷阱

引言

記憶體管理是 C 語言程式設計的核心難點，亦是面試高頻考點。本文透過經典 itoa 錯誤返回事例，系統剖析棧、堆、靜態區的生命週期差異，給出三種修正方案並對比優劣，最後總結記憶體分配原則與 sizeof 誤區，助你構建穩健的記憶體模型。

一、經典錯誤：返回區域變量指針

char *itoa(int n) {
    char retbuf[20];
    sprintf(retbuf, "%d", n);
    return retbuf;  // 錯誤：返回棧上陣列地址
}

現象：呼叫 char *str5 = itoa(5) 後，str5 指向的內容不可預期，極大機率非 "5"。

根因：retbuf 為函數內部區域陣列，存放於棧區。函數返回時棧幀銷毀，記憶體標記為可覆寫，指針懸空。

二、三種修正方案對比

方案 3 範例

char *itoa(int n, char *retbuf) {
    sprintf(retbuf, "%d", n);
    return retbuf;
}
// 使用
char buf[20];
itoa(5, buf);

三、記憶體區域總覽

• .data：已初始化全域/靜態變量，程式全期有效。
• .bss：未初始化全域/靜態變量，程式全期有效，編譯器自動清零。
• .stack：函數調用棧，編譯器自動管理，函數返回即失效。
• .heap：malloc/free 手動管理，忘記釋放即洩漏。

四、核心原則：誰分配誰釋放

「自己使用的記憶體最好自己申請和釋放。」

• 避免「函數分配、呼叫者釋放」的非對稱設計。
• 使用指針前務必確認其指向合法區域，防範野指針與空指針解引用。

五、sizeof 陷阱

char *p = malloc(1024);
int nMemSize = sizeof(p); // 錯誤：得到指針大小（4/8 bytes），而非 1024

sizeof 僅在編譯期計算型別大小，無法查詢動態分配塊大小。需自行記錄或封裝管理結構。

六、棧記憶體再探

char *GetString(void) {
    char p[] = "hello world";
    return p; // 編譯器警告：返回區域陣列地址
}

雖然指針值不變，但指向記憶體已標記可複用，內容隨時可能被覆寫，屬未定義行為。

七、工程規範建議

參考成熟編碼規範（如林銳《高質量 C/C++ 編程指南》），將經驗內化為團隊標準，涵蓋：

• 記憶體所有權約定
• 錯誤碼與資源清理路徑
• 靜態分析工具整合（Coverity, Clang Static Analyzer）

結語

記憶體問題隱蔽且破壞力強，掌握區域模型、明確所有權、善用工具檢測，是寫出可靠 C 代碼的必修課。