記憶體釋放的本質：並非清零，而是標記可用

核心結論

釋放記憶體（free/delete）不會將記憶體內容歸零，核心動作是向記憶體管理器（分配器/作業系統）宣告：「這塊區塊不再使用，可供後續分配請求複用」。

為什麼不清零？效能優先

逐位元寫入 0 需耗費 CPU 週期與記憶體頻寬。對於大型區塊或高頻分配/釋放場景，清零開銷不可忽視。現代分配器（如 glibc malloc、Windows Heap、Jemalloc）皆採用「標記空閒」策略：

• 維護空閒鏈表/樹/位圖，記錄哪些區塊可用。
• 釋放時僅更新元資料（Header/Footer、Bitmap），時間複雜度 O(1) 或 O(log n)。
• 實際資料保留原樣，直到被覆寫為止。

生活化類比：檔案刪除與磁碟格式化

• 刪除檔案：檔案系統僅在目錄表移除索引、將對應叢集標記為「未配置」，資料實體仍留在磁碟，故可用復原軟體救回（前提是未被新資料覆寫）。
• 快速格式化：重建檔案系統結構（FAT/MFT），不掃描/清零資料區。
• 完整格式化：會掃描壞軌、可選擇清零，耗時較久。

記憶體釋放類似「快速刪除/快速格式化」，為了速度犧牲即時清零。

重複釋放為何崩潰？

首次釋放後，區塊已被標記「空閒」並從「已配置」記錄移除。第二次釋放時，分配器發現該區塊不在「已配置」清單中（或 Header 魔數已損壞），判定為 Double Free，觸發 SIGABRT/HEAP CORRUPTION 終止程式，避免後續未定義行為（如惡意利用）。

安全實務建議

1. 釋放後立即置空指標：free(ptr); ptr = nullptr; 防止誤用懸空指標。
2. 使用智慧指標：C++ 採用 std::unique_ptr/shared_ptr，RAII 自動管理生命週期，根除手動釋放錯誤。
3. 敏感資料主動清零：密鑰、密碼等機密資料釋放前，需呼叫 memset_s/SecureZeroMemory 等安全清零函式，防止殘留被讀取。

總結

記憶體釋放 = 更新管理元資料，歸還所有權，而非清零資料。理解此機制，有助於避免 Double Free、Use-After-Free 等經典錯誤，也能在安全敏感場景做正確處理。