「C++ 」借來的資源，何如還的瀟灑？-有解無憂

前言

本文的內容將專門對付記憶體管理，培養起有借有還的好習慣，方可消除資源管理的問題，

正文

所謂的資源就是，一旦用了它，將來必須還給系統，如果不是這樣，糟糕的事情就會發生，

C++ 程式內常見的資源：

動態分配記憶體
檔案描述符
互斥鎖
圖形頁面中的字型和筆刷
資料庫連接
網路 sockets

無論哪一種資源，重要的是，當你不再使用它時，必須將它還給系統，有借有還是個好習慣，

細節 01 ：以物件管理資源

把資源放在解構式，交給解構式釋放資源

假設某個 class 含有個工廠函式，該函式獲取了物件的指標：

A* createA();    // 回傳指標，指向的是動態分配物件，
                 // 呼叫者有責任洗掉它，

如上述注釋所言，createA 的呼叫端使用了函式回傳的物件后，有責任洗掉它，現在考慮有個f函式履行了這個責任:

void f()
{
    A *pa = createA();  // 呼叫工廠函式
    ...                 // 其他代碼
    delete pa;          // 釋放資源
}

這看起來穩妥，但存在若干情況f函式可能無法執行到delete pa陳述句，也就會造成資源泄漏，例如如下情況：

或許因為「…」區域內的一個過早的 return 陳述句；
或許因為「…」區域內的一個回圈陳述句過早的continue 或 goto 陳述句退出；
或許因為「…」區域內的陳述句拋出例外，無法執行到 delete，

當然可以通過謹慎地撰寫程式可以防止這一類錯誤，但你必須想想，代碼可能會在時間漸漸過去后被修改，如果是一個新手沒有注意這一類情況，那必然又會再次有記憶體泄漏的可能性，

為確保 A 回傳的資源都是被回收，我們需要將資源放進物件內，當物件離開作用域時，該物件的解構式會自動釋放資源，

「智能指標」是個好幫手，交給它去管理指標物件，

對于是由動態分配（new）于堆記憶體的物件，指標物件離開了作用域并不會自動呼叫解構式（需手動delete），為了讓指標物件能像普通物件一樣，離開作用域自動呼叫解構式回收資源，我們需要借助「智能指標」的特性，

常用的「智能指標」有如下三個：

std::auto_ptr（ C++ 98 提供、C++ 11 建議摒棄不用）
std::unique_ptr（ C++ 11 提供）
std::shared_ptr（ C++ 11 提供）

std::auto_ptr

下面示范如何使用 std::auto_ptr 以避免 f 函式潛在的資源泄漏可能性：

void f()
{
    std::auto_ptr<A> pa (createA()); // 呼叫工廠函式
    ...  // 一如既往的使用pa
}        // 離開作用域后，經由 auto_ptr 的解構式自動洗掉pa;

這個簡單的例子示范「以物件管理資源」的兩個關鍵想法：

獲得資源后立刻放進管理物件內，以上代碼中 createA 回傳的資源被當做其管理者 auto_ptr 的初值，也就立刻被放進了管理物件中，
管理物件運用解構式確保資源釋放，不論控制流如何離開區塊，一旦物件被銷毀（例如當物件離開作用域）其解構式自然會被自動呼叫，于是資源被釋放，

為什么在 C++11 建議棄用 auto_ptr 嗎？當然是 auto_ptr 存在缺陷，所以后續不被建議使用，

auto_ptr 有一個不尋常的特質：若通過「復制建構式或賦值運算子函式」 copy 它們，它們會變成 null ，而復制所得的指標將獲取資源的唯一擁有權！
見如下例子說明：

std::auto_ptr<A> pa1(createA()); // pa1 指向 createA 回傳物

std::auto_ptr<A> pa2(pa1); // 現在 pa2 指向物件，pa1將被設定為 null

pa1 = pa2; // 現在 pa1 指向物件，pa2 將被設定為 null

這一詭異的復制行為，如果再次使用指向為 null 的指標，那必然會導致程式奔潰，
意味著 auto_ptr 并非管理動態分配資源的神兵利器，

std::unique_ptr

unique_ptr 也采用所有權模型，但是在使用時，是直接禁止通過復制建構式或賦值運算子函式 copy 指標物件，如下例子在編譯時，會出錯：

std::unique_ptr<A> pa1(createA()); // pa1 指向 createA 回傳物

std::unique_ptr<A> pa2(pa1); // 編譯出錯！

pa1 = pa2; // 編譯出錯！

std::shared_ptr

shared_ptr 在使用復制建構式或賦值運算子函式后，參考計會數累加并且兩個指標物件指向的都是同一個塊記憶體，這就與 unique_ptr、auto_ptr 不同之處，

void f()
{
    std::shared_ptr<A> pa1(createA()); // pa1 指向 createA 回傳物

    std::shared_ptr<A> pa2(pa1); // 參考計數+1，pa2和pa1指向同一個記憶體

    pa1 = pa2; // 參考計數+1，pa2和pa1指向同一個記憶體
}

當一個物件離開作用域，shared_ptr 會把參考計數值 -1 ，直到參考計數值為 0 時，才會進行洗掉物件，

由于 shared_ptr 釋放空間時會事先要判斷參考計數值的大小，因此不會出現多次洗掉一個物件的錯誤，

小結 - 請記住

為防止資源泄漏，請使用 RAII（Resource Acquisition Is Initaliaztion - 資源取得時機便是初始化時機）物件，它們在建構式中獲取資源，并在解構式中是釋放資源

兩個建議使用的 RAII classes 分別是 std::unique_ptr 和 std::shared_ptr，前者不允許 copy 動作，后者允許 copy 動作，但是不建議用 std::auto_ptr，若選 auto_ptr，復制動作會使它（被復制物）指向 null ，

細節 02：在資源管理類中小心 copying 行為

假設，我們使用 C 語音的 API 函式處理型別為 Mutex 的互斥物件，共有 lock 和 unlock 兩函式可用：

void locak(Mutex *pm);  // 鎖定 pm 所指的互斥器
void unlock(Mutex* pm); // 將互斥器解除鎖定

為確保絕不會忘記一個被鎖住的 Mutex 解鎖，我們可能會希望創立一個 class 來管理鎖資源，這樣的 class 要遵守 RAII 守則，也就是「資源在構造期間獲得，在析構釋放期間釋放」：

class Lock
{
public:
    explicit Lock(Mutex *pm) // 建構式
        : pMutex(pm)
    {
        lock(pMutex);
    }

    ~Lock()  // 解構式
    {
        unlock(pMutex);
    }
private:
    Mutex* pMutex;
};

這樣定義的 Lock，用法符合 RAII 方式：

Mutex m;      //定義你需要的互斥鎖
... 
{                 // 建立一個區域區塊作用域
    Lock m1(&m);  // 鎖定互斥器
    ...
}                 // 在離開區塊作用域，自動解除互斥器鎖定

這很好，但如果 Lock 物件被復制，會發生什么事情？

Lock m1(&m);  // 鎖定m
Lock m2(&m1); // 將 m1 復制到 m2身上，這會發生什么？

這是我們需要思考和面對的：「當一個 RAII 物件被復制，會發生什么事情？」大多數時候你會選擇以下兩種可能：

禁止復制，如果 RAII 不允許被復制，那我們需要將 class 的復制建構式和賦值運算子函式宣告在 private，
使用參考計數法，有時候我們希望保有資源，直到它直的最后一個物件被消耗，這種情況下復制 RAII 物件時，應該將資源的「被參考數」遞增，std::shared_ptr 便是如此，

如果前述的 Lock 打算使用使用參考計數法，它可以使用 std::shared_ptr 來管理 pMutex 指標，然后很不幸 std::shared_ptr 的默認行為是「當參考次數為 0 時洗掉其所指物」那不是我們想要的行為，因為要對 Mutex 釋放動作是解鎖而非洗掉，

幸運的是 std::shared_ptr 允許指定自定義的洗掉方式，那是一個函式或函式物件，如下：

class Lock
{
public:
    explicit Lock(Mutex *pm)  
        : pMutex(pm, unlock)  // 以某個 Mutex 初始化 shared_ptr，
                              // 并以 unlock 函式為洗掉器，
    {
        lock(pMutex.get());  // get 獲取指標地址
    }

private:
    std::shared_ptr<Mutex> pMutex; // 使用 shared_ptr
};

請注意，本例的 Lock class 不再宣告解構式，因為編譯器會自動創立默認的解構式，來自動呼叫其 non-static 成員變數（本例為 pMutex ）的解構式，

而 pMutex 的解構式會在互斥器的參考次數為 0 時，自動呼叫 std::shared_ptr 的洗掉器（本例為 unlock ），

小結 - 請記住

復制 RAII 物件必須一并復制它的所管理的資源（深拷貝），所以資源的 copying 行為決定 RAII 物件的 copying 行為，

普通而常見的 RAII class copying 行為是：禁止 copying、施行參考計數法，

細節 03 ：在資源類中提供對原始資源的訪問

智能指標「顯式」轉換，也就是通過 get 成員函式的方式轉換為原始指標物件，

上面提到的「智能指標」分別是：std::auto_ptr、std::unique_ptr、std::shared_ptr，它們都有訪問原始資源的辦法，都提供了一個 get 成員函式，用來執行顯式轉換，也就是它會回傳智能指標內部的原始指標（的復件），

舉個例子，使用智能指標如 std::shared_ptr 保存 createA() 回傳的指標物件：

std::shared_ptr<A> pA(createA());

假設你希望以某個函式處理 A 物件，像這樣：

int getInfo(const A* pA);

你想這么呼叫它：

std::shared_ptr<A> pA(createA());
getInfo(pA);       // 錯誤！！

會編譯錯誤，因為 getInfo 需要的是 A 指標物件，而不是型別為 std::shared_ptr<A> 的物件，

這時候就需要用 std::shared_ptr 智能指標提供的 get 成員函式訪問原始的資源：

std::shared_ptr<A> pA(createA());
getInfo(pA.get());   // 很好，將 pA 內的原始指標傳遞給 getInfo

智能指標「隱式」轉換的方式，是通過指標取值運算子，

智能指標都多載了指標取值運算子（operator->和operator*），它們允許隱式轉換至底部原始指標：

class A
{
public：
    bool isExist() const;
    ...
};

A* createA();  // 工廠函式，創建指標物件

std::shared_ptr<A> pA(createA()); // 令 shared_ptr 管理物件資源

bool exist = pA->isExist();    // 經由 operator-> 訪問資源
bool exist2 = (*pA).isExist(); // 經由 operator* 訪問資源

多數設計良好的 classes 一樣，它隱藏了程式員不需要看到的部分，但是有程式員需要的所有東西，

所以對于自身設計 RAII classes 我們也要提供一個「取得其所管理的資源」的辦法，

小結 - 請記住

APIs 往往要求訪問原始資源，所以每一個 RAII class 應該提供一個「取得其所管理的資源」的辦法，

對原始資源的訪問可能經由顯式轉換或隱式轉換，一般而言顯式轉換比較安全，但隱式轉換比較方便，

細節 04：成對使用 new 和 delete

以下動作有什么錯？

std::string* strArray = new std::string[100];
...
delete strArray;

每件事情看起來都井然有序，使用了 new，也搭配了對應的 delete，但還是有某樣東西完全錯誤，strArray 所含的 100 個 string 物件中的 99 個不太可能被適當洗掉，因為它們的解構式很可能沒有被呼叫，

當使用 new ，有兩件事發生：

記憶體被分配出來（通過名為 operator new 的函式）
針對此記憶體會有一個或多個建構式被呼叫

當使用 delete，也會有兩件事情：

針對此記憶體會有一個或多個解構式被呼叫
然后記憶體才被釋放（通過名為 operator delete 的函式）

delete 的最大問題在于：即將被洗掉的記憶體之內究竟有多少物件？這個答案決定了需要執行多少個解構式，

物件陣列所用的記憶體通常還包括「陣列大小」的記錄，以便 delete 知道需要呼叫多少次解構式，單一物件的記憶體則沒有這筆記錄，你可以把兩者不同的記憶體布局想象如下，其中 n 是陣列大小：

當你對著一個指標使用 delete，唯一能夠讓 delete 知道記憶體中是否存在一個「陣列大小記錄」的辦法就是：由你告訴它，如果你使用 delete 時加上中括號[]，delete 便認定指標指向一個陣列，否則它便認定指標指向一個單一物件：

std::string* strArray = new std::string[100];
std::string* strPtr = new std::strin;
... 
delete [] strArray;  // 洗掉一個物件
delete strPtr;       // 洗掉一個由物件組成的陣列

游戲規則很簡單：

如果你在 new 運算式中使用[]，必須在相應的 delete 運算式也使用[]，
如果你在 new 運算式中不使用[]，一定不要在相應的 delete 運算式使用[]，

小結 - 請記住

如果你在 new 運算式中使用[]，必須在相應的 delete 運算式也使用[]，如果你在 new 運算式中不使用[]，一定不要在相應的 delete 運算式使用[]，

細節 05：以獨立陳述句將 newed （已被 new 的）物件置入智能指標

假設我們有個以下示范的函式：

int getNum();
void fun(std::shared_ptr<A> pA, int num);

現在考慮呼叫 fun：

fun(new A(), getNum());

它不能通過編譯，因為 std::shared_ptr 建構式需要一個原始指標，而且該建構式是個 explicit 建構式，無法進行隱式轉換，如果寫成這樣就可以編譯通過：

fun(std::shared_ptr<A>(new A), getNum());

令人想不到吧，上述呼叫卻可能泄露資源，接下來我們來一步一步的分析為什么存在記憶體泄漏的可能性，

在進入 fun 函式之前，肯定會先執行各個實參，上述第二個實參只是單純的對 getNum 函式的呼叫，但第一個實參 std::shared_ptr<A>(new A) 由兩部分組成：

執行 new A 運算式
呼叫 std::shared_ptr 建構式

于是在呼叫 fun 函式之前，先必須做以下三件事：

呼叫 getNum 函式
執行 new A 運算式
呼叫 std::shared_ptr 建構式

那么他們的執行次序是一定如上述那樣的嗎？可以確定的是 new A 一定比 std::shared_ptr 建構式先被執行，但對 getNum 呼叫可以排在第一或第二或第三執行，

如果編譯器選擇以第二順位執行它：

執行 new A 運算式
呼叫 getNum 函式
呼叫 std::shared_ptr 建構式
萬一在呼叫 getNum 函式發生了例外，會發生什么事情？在此情況下 new A 回傳的指標將不會置入 std::shared_ptr 智能指標里，就存在記憶體泄漏的現象，

避免這類問題的辦法很簡單：使用分離陳述句，

分別寫出：

創建 A
將它置入一個智能指標內
然后再把智能指標傳遞給 fun 函式，

std::shared_ptr<A> pA(new A); // 先構造智能指標物件
fun(pA, getNum()); // 這個呼叫動作絕不至于造成泄漏，

以上的方式，就能避免原本由于次序導致記憶體泄漏發生，

小結 - 請記住

以獨立陳述句將 newed （已 new 過）物件存盤于智能指標內，如果不這樣做，一旦例外被拋出，有可能導致難以察覺的資源泄漏，

最后

本文部分內容參考了《Effective C++ （第3版本）》第三章節內容，前兩章節的內容可看舊文
《學過 C++ 的你，不得不知的這 10 條細節！》

關注公眾號，后臺回復「我要學習」，即可免費獲取精心整理「服務器 Linux C/C++ 」成長路程（書籍資料 + 思維導圖）

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/59728.html

標籤：C++

上一篇：C++ 常用編程--Swap函式有幾種寫法？

下一篇：C++中的public、protected和private

「C++ 」借來的資源，何如還的瀟灑？

前言

正文

細節 01 ： 以物件管理資源

std::auto_ptr

std::unique_ptr

std::shared_ptr

小結 - 請記住

細節 02：在資源管理類中小心 copying 行為

小結 - 請記住

細節 03 ：在資源類中提供對原始資源的訪問

小結 - 請記住

細節 04：成對使用 new 和 delete

小結 - 請記住

細節 05：以獨立陳述句將 newed （已被 new 的）物件置入智能指標

小結 - 請記住

最后

細節 01 ：以物件管理資源