C++ 物件「自殺」模式深度解析：四大場景與四種實現策略

前言

「物件自殺」指：物件**主動決定**結束自身生命週期，而非被擁有者 delete。本文剖析四類典型自殺場景，對比四種實現策略（發送訊息、回調、開線程自刪、垃圾回收站），並強調「自殺」與「借刀殺人」的本質區別。

物件正常銷毀的五種情況（非自殺）

1. 成員變數：隨擁有者析構銷毀
2. 函數局部物件：離開作用域自動銷毀
3. 動態分配：擁有者持有指標，決定何時 delete
4. 全域/靜態物件：程式結束前由系統銷毀
5. 其他：智慧指標、容器管理等

以上皆為**被動**銷毀，控制權在外部。

四大自殺觸發場景

場景 1：任務完成自主結束

視頻播放器物件：上層建立並傳入資源資訊 → 物件內部執行播放 → **只有物件知道何時播完** → 上層無法及時感知 → 物件自殺最乾淨，或通知上層「可殺我」。

場景 2：緩衝區排空後延遲自殺

網路發送器：上層塞數據到緩衝區 → 物件定時發送 → 上層發現數據全塞完 → 通知物件「可自殺」 → 物件**等緩衝區排空後**才自殺。

場景 3：異常觸發保護性自殺

發送器遇網路嚴重錯誤 → 繼續發送會污染接收端 → 物件決定**立即停止並自殺**，確保資源釋放與後續邏輯正常。

場景 4：小結

以上場景均可用「上層輪詢狀態」替代，自殺只是**另一條路徑**。核心區別：控制權在物件內部。

兩種自殺本質

• 自行了斷：物件親自執行銷毀代碼（如線程中 delete this）
• 借刀殺人：物件通知外部，由外部執行 delete（如發送訊息、回調）

四種實現策略對比

策略 3 代碼示意

class Task {
public:
    void RequestSuicide() {
        std::thread([this]() {
            // 可選：通知外部「我要死了」
            delete this;  // 線程上下文中安全刪除
        }).detach();
    }
    // 成員函數不可在 delete this 後繼續執行任何代碼！
};

核心警示

1. delete this **之後絕不可執行任何成員代碼**（含返回語句），this 已失效
2. 外部持有指標必須同步置空或改用 std::weak_ptr 觀察
3. 多線程環境需考慮記憶體可見性（std::atomic 標記狀態）
4. 優先考慮**智慧指標 + 所有權轉移**，物件自殺多為舊代碼/特殊約束下的妥協

結語

物件自殺是「控制權內移」的設計選擇。理解四大場景、兩種本質、四種策略及風險，能在必要時做出正確決策。現代 C++ 應優先用 RAII/智慧指標表達生命週期。本文出自「對影成三人」博客。