Item 19: 使用std::weak_ptr替換會造成指針懸掛的類std::shared_ptr指針

本文翻譯自modern effective C++，由於水平有限，故無法保證翻譯完全正確，歡迎指出錯誤。謝謝！

矛盾的是，我們很容易就能創造出一個和std::shared_ptr類似的智能指針，但是，它們不參加被指向資源的共用所有權管理。換句話說，這是一個行為像std::shared_ptr，但卻不影響對象引用計數的指針。這樣的智能指針需要與一個對std::shared_ptr來說不存在的問題做鬥爭：它指向的東西可能已經被銷毀了。一個真正的智能指針需要通過追蹤資源的懸掛（也就是說，被指向的對象不存在時）來解決這個問題。std::weak_ptr正好就是這種智能指針。

你可能會奇怪std::weak_ptr有什麼用。當你檢查std::weak_ptr的API時，你可能會更奇怪。它看起來一點也不智能。std::weak_ptr不能解引用，不能檢查指針是否為空。這是因為std::weak_ptr不是獨立的智能指針。它是std::shared_ptr的附加物。

它們的聯繫從出生起就存在了。std::weak_ptr常常創造自std::shared_ptr。std::shared_ptr初始化它們時，它們指向和std::shard_ptr指向的相同的位置，但是它們不影響它們所指向對象的引用計數：

auto spw = std::make_shared<Widget>();          //spw被構造之後，被指向的Widget
                                                //的引用計數是1（關於std::make_shared
                                                //的信息，看Item 21）

...

std::weak_ptr<Widget> wpw(spw);                 //wpw和spw指向相同的Widget，引用
                                                //計數還是1

...

spw = nullptr;                                  //引用計數變成0，並且Widget被銷毀
                                                //wpw現在是懸掛的

懸掛的std::weak_ptr被稱為失效的（expired）。你能直接檢查它：

if(wpw.expired())...                            //如果wpw不指向一個對象

但是為了訪問std::weak_ptr指向的對象，你常常需要檢查看這個std::weak_ptr是否已經失效了或者還沒有失效（也就是，它沒有懸掛）。想法總是比做起來簡單，因為std::weak_ptr沒有解引用操作，所以沒辦法寫出相應的代碼。即使能寫出來，把解引用和檢查分離開來會造成競爭條件：在調用expired和解引用操作中間，另外一個線程可能重新賦值或者銷毀std::shared_ptr之前指向的對象，因此，會造成你想解引用的對象被銷毀。這樣的話，你的解引用操作將產生未定義行為。

你需要的是一個原子操作，它能檢查看std::weak_ptr是否失效了，並讓你能訪問它指向的對象。從一個std::weak_ptr來創造std::shared_ptr就能達到這樣的目的。你擁有的std::shared_ptr是什麼樣的，依賴於在你用std::weak_ptr來創建std::shared_ptr時是否已經失效了。操作有兩種形式，一種是std::weak_ptr::lock，它返回一個std::shared_ptr。如果std::weak_ptr已經失效了，std::shared_ptr會是null:

std::shared_ptr<Widget> spw1 = wpw.lock();      //如果wpw已經失效了，spw1是null

auto spw2 = wpw.lock();                         //和上面一樣，不過用的是auto

另一種形式是參數為std::weak_ptr的std::shared_ptr的構造函數。這樣情況下，如果std::weak_ptr已經失效了，會有一個異常拋出：

std::shared_ptr<Widget> spw3(wpw);          //如果wpw已經失效了，拋出一個
                                            //std::bad_weak_ptr異常

但是你可能還是對std::weak_ptr的用途感到奇怪。考慮一個工廠函數，這個函數根據唯一的ID，產生一個指向只讀對象的智能指針。與Item 18的建議相符合，考慮工廠函數的返回類型，它返回一個std::unique_ptr：

std::unique_ptr<const Widget> loadWidget(WidgetId id);

如果loadWidget是一個昂貴的調用（比如，它執行文件操作或者I/O操作）並且對ID的反覆使用是允許的，我們可以做一個合理的優化：寫一個函數，這個函數做loadWidget做的事，但是它也緩存下它返回的結果。但是把所有請求的Widget都緩存下來會造成效率問題，所以另一個合理的優化是：當Widget不再使用時，銷毀它的緩存。

對於這個緩存工廠函數，一個std::unique_ptr的返回類型是不夠合適的。調用者應該收到一個指向緩存對象的智能指針，但是緩存也需要一個指針來指向對象。緩存的指針需要在他懸掛的時候能夠察覺到，因為當工廠的客戶把工廠返回的指針用完之後，對象將會被銷毀，然後在緩存中相應的指針將會懸掛。因此緩存指針應該是一個std::weak_ptr（當指針懸掛的之後能夠有所察覺）。這意味著工廠的返回值類型應該是一個std::shared_ptr，因為std::weak_ptr只有在對象的生命周期被std::shared_ptr管理的時候，才能檢查自己是否懸掛。

這裡給出一個緩存版本的loadWidget的快速實現：

std::shared_ptr<const Widget> fastLoadWidget(WidgetID id)
{
    static std::unordered_map<WidgetID, 
                              std::weak_ptr<const Widget> cache;

    auto objPtr = cache[id].lock();     //objPtr是一個std::shared_ptr 
                                        /它指向緩存的對象（或者，當
                                        //對象不在緩存中時為null）

    if(!objPtr){                        //吐過不在緩存中
        objPtr = loadWidget(id);        //載入它
        cache[id] = objPtr;             //緩存它
    }
    return objPtr;
}

這個實現使用了C++11的一種哈希容器（std::unordered_map），儘管它沒有顯示WidgetID的哈希函數以及比較函數，但他們還是會被實現出來的。

fastLoadWidget的實現忽略了一個事實，那就是緩存可能積累一些失效了的std::weak_ptr（對應的Widget已經不再被使用（因此這些Widget已經銷毀了））。實現能被進一步優化，但是比起花費時間在這個問題（對std::weak_ptr的理解沒有額外的提升）上，讓我們考慮第二個使用場景：觀察者設計模式。這個設計模式最重要的組件就是目標（subject，目標的狀態可能會發生改變）和觀察者（observer，當目標的狀態發生改變時，觀察者會被通知）。大多數實現中，每個目標包含一個數據成員，這個成員持有指向觀察者的指針。這使得目標在狀態發生改變的時候，通知起來更容易。目標對於控制他們的觀察者的生命周期沒有興趣（也就是，當他們銷毀時），但是它們對它們的觀察者是否已經銷毀了很有興趣，這樣它們就不會嘗試去訪問觀察者了。一個合理的設計是：讓每個目標持有一個容器，這個容器中裝了指向它觀察者的std::weak_ptr，因此，這讓目標在使用一個指針前能確定它是否懸掛的。

最後一個std::weak_ptr的使用例子是：考慮一個關於A，B，C的數據結構，A和C共用B的所有權，因此都持有std::shared_ptr指向B：

假設從B指向A的指針同樣有用，這個指針應該是什麼類型的呢？

這裡有三種選擇：

• 一個原始指針。用這種方法，如果A銷毀了，但是C仍然指向B，B將持有指向A的懸掛指針。B不會發現，所以B可能無意識地解引用這個懸掛指針。這將產生未定義的行為。

• 一個std::shared_ptr。在這種設計下，A和B互相持有指向對方的std::shared_ptr。這產生了std::shared_ptr的迴圈引用（A指向B，B指向A），這會阻止A和B被銷毀。即使A和B無法從其他數據結構獲得（比如，C不再指向B），A和B的引用計數都還是1.如果這發生了，A和B將被泄露，實際上：程式將不再能訪問它們，這些資源也將不能被回收。

• 一個std::weak_ptr。這避免了上面的兩個問題。如果A被銷毀了，B中，指向A的指針將懸掛，但是B能察覺到。此外，儘管A和B會互相指向對方，B的指針也不會影響A的引用計數，因此A不再被指向時，B也不會阻止A被銷毀。

使用std::weak_ptr是三個選擇中最好的一個。但是，使用std::weak_ptr來預防std::shared_ptr的不常見的迴圈引用是不值得的。在嚴格分層的數據結構中，比如樹，子節點通常只被它們的父節點擁有。當一個父節點被銷毀時，它的子節點也應該被銷毀。因此從父節點到子節點的連接通常被表示為std::unique_ptr。從子節點到父節點的鏈接能被安全地實現為原始指針，因為一個子節點的生命周期不應該比它們的父節點長。因此這裡沒有子節點對懸掛的父指針進行解引用的風險。

當然，不是所有基於指針的數據結構都是嚴格分層的，當這種情況發生時，就像上面的緩存和觀察者鏈表的實現一樣，我們知道std::weak_ptr已經躍躍欲試了。

從效率的觀點來看，std::weak_ptr和std::shared_ptr在本質上是相同的。std::weak_ptr對象和std::shared_ptr一樣大，它們和std::shared_ptr使用相同的控制塊（看Item 19），並且構造，析構，賦值等操作也涉及到引用計數的原子操作。這可能會讓你感到奇怪，因為我在這個Item的一開始就寫了std::weak_ptr不參與引用計數的計算。我寫的其實不是那個意思，我寫的是，std::weak_ptr不參與共用對象的所有權，因此不會影響被指向對象的引用計數。控制塊中其實還有第二個引用計數，這第二個引用計數是std::weak_ptr所維護的。細節部分，請繼續看Item 21。

　　　　　　　　　　　　你要記住的事

• 使用std::weak_ptr替換那些會造成懸掛的類std::shared_ptr指針。
• 使用std::weak_ptr的潛在情況包括緩存，觀察者鏈表，以及防止std::shared_ptr的迴圈引用。