realloc的雙面真相：C語言動態數組的無聲陷阱

【編者按】本文是C語言動態數組系列的第二篇。在上一篇中，我們構建了一個固定容量的數組，它在超出初始大小時直接罷工。今天，我們要解決一個更棘手的問題：如何讓數組自動增長，而這背后的核心機制——realloc，可能是C標準庫中最容易被誤用的函數。 正文： 周三下午，一個C程序員寫下了一行看似無害的代碼：`arr->data = realloc(arr->data, new_size)`。他不知道的是，這行代碼里藏著兩個陷阱，任何一個都足以讓程序在某個隨機時刻崩潰，而且這種崩潰往往發生在代碼審查通過很久之后。 此刻他的數組還好好的，但種子已經埋下。 這和上一步我們留下的那個固定容量數組形成鮮明對比。那個數組的問題很清楚：空間用完了，`array_push`返回-1，拒絕合作。用戶要么提前知道需要多少空間，要么就得承擔反復分配和拷貝的痛苦。這不是一個真正的動態數組，它只是一個帶友好API的定長緩沖區。 真正的動態數組必須解決核心矛盾：調用者不知道自己需要存儲5個元素還是500萬個。 realloc就是為此而生的。它的函數簽名簡潔到具有欺騙性：`void *realloc(void *ptr, size_t new_size)`——傳入一個已分配內存的指針，傳回一個至少有新大小字節的內存塊指針，舊數據原封不動。 但在這個簡單接口背后，藏著兩件完全不同的事。 第一種情況：原地擴展。如果在堆上你當前分配塊的后面恰好有足夠的空閑空間，內存分配器只需要把這個塊的邊界往后挪一挪。指針不變，沒有新分配，沒有拷貝。這是最快的路徑，也是你永遠不能指望的路徑。 第二種情況：分配-拷貝-釋放。如果當前塊后面沒有空間，分配器會找一塊新的、足夠大的內存區域，把舊數據全部拷貝過去，然后釋放原來的塊。指針會變，舊指針立刻失效。 這就是第一個陷阱的名字：指針失效。在realloc調用之后，任何指向舊緩沖區內部的指針都變成了懸空指針。這不是理論上的擔憂，這是C代碼庫中最常見的use-after-free問題來源之一。當你寫下`arr->data = realloc(arr->data, new_size)`時，如果realloc在內部執行了第二種情況，舊的內存已經被歸還給操作系統，而你之前在數組里保存的那些指向特定元素的指針——它們現在全指向了已釋放的內存。 更危險的是，這個bug可能很長時間都不會暴露。如果碰巧大多數時候realloc都在原地擴展，指針一直有效，測試通過，代碼上線。然后在某個生產環境的特殊條件下，堆的布局變了，realloc決定搬家，程序開始隨機崩潰。 但還有第二個陷阱，和失敗處理有關。 realloc可能失敗。當系統內存耗盡時，它會返回NULL?，F在回到那行代碼：`arr->data = realloc(arr->data, new_size)`。如果realloc失敗返回NULL，NULL被賦值給了arr->data，而你原本的數據指針被覆蓋了。結果是：舊數據的內存還在那里，但你已經丟了指向它的指針——內存泄漏了，數據也丟了。 解決這兩個陷阱的正確方法是"臨時指針"模式，它只有三行代碼，但三行代碼的區別就是：一個數組在內存耗盡時能體面降級，另一個會泄露數據然后崩潰。 這三行的邏輯很簡單：先把realloc的結果存到一個臨時變量里，檢查它是不是NULL，如果不是，再把臨時變量賦給arr->data。這樣即使分配失敗，arr->data仍然指向舊的有效數據，數組可以繼續使用或體面地清理。 當你把這個臨時指針模式應用到數組的自動擴容邏輯中時，整個機制就變得清晰：當size達到capacity，用realloc把緩沖區翻倍，檢查是否成功，更新capacity計數，然后繼續push。用戶從頭到尾都不需要關心capacity這個字段的存在，他們只需要調用push。 但用戶不需要關心，不代表你不應該理解。自動增長帶來了便利，也帶來了代價。每次realloc可能搬家時，都是一次隱藏的拷貝操作。翻倍策略雖然攤銷了拷貝的成本，但如果你提前知道需要存儲100萬個元素，一次性分配好仍然是更高效的選擇。 動態數組的關鍵不在于"無限大"，而在于"讓容量管理從用戶的責任變為數組自己的責任"。realloc是把這個轉移變成現實的那一環，但前提是你得知道它的兩面性：它可能移動你的數據，你絕不能把它的結果直接賦值給你正在重新分配的那個指針。 當你理解了這兩點，大多數教程關于realloc的講解就變成了明顯的反例。你開始看懂那些看似無害的代碼里藏著什么，也開始明白為什么C語言動態數組的實現總是圍繞這個臨時指針展開——不是因為它復雜，而是因為直接賦值的誘惑太自然了。