C++ 垃圾回收實踐：智慧指標與 RAII 替代方案

C++ 故意不內建統一垃圾回收（GC），但透過 RAII（資源獲取即初始化）、智慧指標、標準容器 等機制，已能在不犧牲效能、不破壞底層控制力的前提下，解決 99% 的記憶體管理問題。本文從語言哲學切入，逐步建構適用於不同場景的「按需 GC」方案。

為什麼 C++ 沒有內建 GC？

Bjarne Stroustrup 在《The Design and Evolution of C++》中指出：

「我有意設計 C++ 不依賴自動 GC。基於經驗，我懼怕其嚴重的時空開銷、實現與移植複雜度，以及 GC 會讓 C++ 不適合底層系統程式設計——這正是其設計目標之一。但我喜歡 GC 的思想，它能簡化設計、消除大量錯誤根源。」

核心哲學：「不為不使用的功能付費」。統一 GC 強迫所有程式承擔開銷，違背 C++ 精神。

C++ 內建的「輕量級 GC」三層防線

第一層：RAII + 建構子/解構子

資源（記憶體、鎖、檔案控制代碼）在建構時獲取，解構時自動釋放：

class String {
    char* data_;
public:
    String(const char* s) { data_ = new char[strlen(s)+1]; strcpy(data_, s); }
    ~String() { delete[] data_; }
    const char* c_str() const { return data_; }
};

void foo() {
    String s("hello"); // 區域物件，離開作用域自動釋放
    std::cout << s.c_str();
} // 此處自動呼叫 ~String()，零洩漏

甚至發生例外時，C++ 保證堆疊展開會正確呼叫解構子——這就是異常安全的基石。

第二層：std::unique_ptr (C++11) / std::auto_ptr (C++98)

獨佔所有權，移動語義轉移擁有權，零額外開銷：

#include <memory>
void bar() {
    std::unique_ptr<String> p(new String("hello")); // C++11
    // std::auto_ptr<String> p(new String("hello")); // C++98 僅供參考
    std::cout << p->c_str();
} // 自動 delete

auto_ptr 的複製語義是所有權轉移（來源變空），易誤用；unique_ptr 禁止複製，只能 std::move，編譯期強制安全。

第三層：std::shared_ptr (C++11) —— 共享所有權 GC

引用計數機制，最後一個 shared_ptr 銷毀時自動釋放資源：

template <typename T>
class shared_ptr {
    struct ControlBlock { T* ptr; size_t refs; /* weak count */ };
    ControlBlock* ctrl_;
    // ... 建構、複製、移動、解構、operator*, operator->
    void dec() { if (--ctrl_->refs == 0) { delete ctrl_->ptr; delete ctrl_; } }
};

用法：

void foo1(std::shared_ptr<int>& p) {
    std::shared_ptr<int> tmp(p); // 計數 +1
    *tmp = 300; // 修改共享物件
} // tmp 解構，計數 -1，物件存活

void foo2(std::shared_ptr<int>& p) {
    p = std::make_shared<int>(200); // 重新指派，舊物件計數 -1
}

int main() {
    auto p = std::make_shared<int>(100);
    foo1(p); // 共享修改
    foo2(p); // 替換為新物件
    // 離開 main 時自動釋放，全程無 delete
}

注意：循環參考需配合 std::weak_ptr 打斷；多執行緒下控制區塊的引用計數為原子操作，有微小開銷。

標準容器：集合層面的自動管理

std::vector、std::list、std::map 等容器內部以 RAII 管理元素生命週期：

• 元素為值型別：容器銷毀時自動銷毀所有元素。
• 元素為智慧指標：容器管理指標，指標管理物件，雙重保障。

避免 在容器中存放原始指標（std::vector<T*>），否則容器銷毀不會釋放物件，極易洩漏。

進階：針對特定類型的自訂 GC

若標準智慧指標無法滿足（如效能極致、特定所有權語義），可自行實作：

• Object Pool：預先分配大塊記憶體，避免頻繁 new/delete。
• Region-based Allocation：同一生命週期物件群組配置，整體釋放（如 Apache HTTPD 的 pool）。
• GC 框架整合：Boehm GC、gc.h 等可選整合，但需評估移植性與效能影響。

語言層面為何不強制 GC？

1. 多樣性：即時系統、嵌入式、高頻交易、遊戲引擎對延遲、記憶體佔用、確定性有嚴格要求，統一 GC 無法滿足。
2. 零開銷抽象：C++ 目標是「抽象不付費」，智慧指標編譯後與手寫 RAII 幾乎等價。
3. 程式設計師責任：C++ 信任開發者能選擇適合的工具，而非強迫單一模式。

最佳實踐清單

總結

C++ 沒有「垃圾回收器」，但擁有更強大的「資源管理框架」：

• RAII 將資源綁定物件生命週期，語言保證釋放時機。
• 智慧指標 以零/極低開銷實現所有權語義（獨佔/共享/弱參考）。
• 標準容器 自動管理集合元素。
• 按需選擇，不為不使用的功能付費，保留底層控制權。

掌握這套體系，你就擁有了比 GC 更精確、更高效、更適合系統級開發的記憶體管理能力。