我在《Linux 多線程服務(wù)端編程：使用 muduo C++ 網(wǎng)絡(luò)庫》第 1.9 節(jié)“再論 shared_ptr 的線程安全”中寫道：

（shared_ptr）的引用計(jì)數(shù)本身是安全且無鎖的，但對象的讀寫則不是，因?yàn)?shared_ptr 有兩個(gè)數(shù)據(jù)成員，讀寫操作不能原子化。根據(jù)文檔（http://www.boost.org/doc/libs/release/libs/smart_ptr/shared_ptr.htm#ThreadSafety）， shared_ptr 的線程安全級別和內(nèi)建類型、標(biāo)準(zhǔn)庫容器、std::string 一樣，即：

• 一個(gè) shared_ptr 對象實(shí)體可被多個(gè)線程同時(shí)讀?。ㄎ臋n例1）；

• 兩個(gè) shared_ptr 對象實(shí)體可以被兩個(gè)線程同時(shí)寫入（例2），“析構(gòu)”算寫操作；

• 如果要從多個(gè)線程讀寫同一個(gè) shared_ptr 對象，那么需要加鎖（例3~5）。

請注意，以上是 shared_ptr 對象本身的線程安全級別，不是它管理的對象的線程安全級別。

后文（p.18）則介紹如何高效地加鎖解鎖。本文則具體分析一下為什么“因?yàn)?shared_ptr 有兩個(gè)數(shù)據(jù)成員，讀寫操作不能原子化”使得多線程讀寫同一個(gè) shared_ptr 對象需要加鎖。這個(gè)在我看來顯而易見的結(jié)論似乎也有人抱有疑問，那將導(dǎo)致災(zāi)難性的后果，值得我寫這篇文章。本文以 boost::shared_ptr 為例，與 std::shared_ptr 可能略有區(qū)別。

shared_ptr 的數(shù)據(jù)結(jié)構(gòu)

shared_ptr 是引用計(jì)數(shù)型（reference counting）智能指針，幾乎所有的實(shí)現(xiàn)都采用在堆（heap）上放個(gè)計(jì)數(shù)值（count）的辦法（除此之外理論上還有用循環(huán)鏈表的辦法，不過沒有實(shí)例）。具體來說，shared_ptr<Foo> 包含兩個(gè)成員，一個(gè)是指向 Foo 的指針 ptr，另一個(gè)是 ref_count 指針（其類型不一定是原始指針，有可能是 class 類型，但不影響這里的討論），指向堆上的 ref_count 對象。ref_count 對象有多個(gè)成員，具體的數(shù)據(jù)結(jié)構(gòu)如圖 1 所示，其中 deleter 和 allocator 是可選的。

圖 1：shared_ptr 的數(shù)據(jù)結(jié)構(gòu)。

為了簡化并突出重點(diǎn)，后文只畫出 use_count 的值：

以上是 shared_ptr<Foo> x(new Foo); 對應(yīng)的內(nèi)存數(shù)據(jù)結(jié)構(gòu)。

如果再執(zhí)行 shared_ptr<Foo> y = x; 那么對應(yīng)的數(shù)據(jù)結(jié)構(gòu)如下。

但是 y=x 涉及兩個(gè)成員的復(fù)制，這兩步拷貝不會(huì)同時(shí)（原子）發(fā)生。

中間步驟 1，復(fù)制 ptr 指針：

中間步驟 2，復(fù)制 ref_count 指針，導(dǎo)致引用計(jì)數(shù)加 1：

步驟1和步驟2的先后順序跟實(shí)現(xiàn)相關(guān)（因此步驟 2 里沒有畫出 y.ptr 的指向），我見過的都是先1后2。

既然 y=x 有兩個(gè)步驟，如果沒有 mutex 保護(hù)，那么在多線程里就有 race condition。

多線程無保護(hù)讀寫 shared_ptr 可能出現(xiàn)的 race condition

考慮一個(gè)簡單的場景，有 3 個(gè) shared_ptr<Foo> 對象 x、g、n：

shared_ptr<Foo> g(new Foo); // 線程之間共享的 shared_ptrshared_ptr<Foo> x; // 線程 A 的局部變量shared_ptr<Foo> n(new Foo); // 線程 B 的局部變量

一開始，各安其事。

線程 A 執(zhí)行 x = g; （即 read g），以下完成了步驟 1，還沒來及執(zhí)行步驟 2。這時(shí)切換到了 B 線程。

同時(shí)編程 B 執(zhí)行 g = n; （即 write g），兩個(gè)步驟一起完成了。

先是步驟 1：

再是步驟 2：

這是 Foo1 對象已經(jīng)銷毀，x.ptr 成了空懸指針！

最后回到線程 A，完成步驟 2：

多線程無保護(hù)地讀寫 g，造成了“x 是空懸指針”的后果。這正是多線程讀寫同一個(gè) shared_ptr 必須加鎖的原因。

當(dāng)然，race condition 遠(yuǎn)不止這一種，其他線程交織（interweaving）有可能會(huì)造成其他錯(cuò)誤。

思考，假如 shared_ptr 的 operator= 實(shí)現(xiàn)是先復(fù)制 ref_count（步驟 2）再復(fù)制 ptr（步驟 1），會(huì)有哪些 race condition？

雜項(xiàng)shared_ptr 作為 unordered_map 的 key

如果把 boost::shared_ptr 放到 unordered_set 中，或者用于 unordered_map 的 key，那么要小心 hash table 退化為鏈表。http://stackoverflow.com/questions/6404765/c-shared-ptr-as-unordered-sets-key/12122314#12122314

直到 Boost 1.47.0 發(fā)布之前，unordered_set<std::shared_ptr<T> > 雖然可以編譯通過，但是其 hash_value 是 shared_ptr 隱式轉(zhuǎn)換為 bool 的結(jié)果。也就是說，如果不自定義hash函數(shù)，那么 unordered_{set/map} 會(huì)退化為鏈表。https://svn.boost.org/trac/boost/ticket/5216

Boost 1.51 在 boost/functional/hash/extensions.hpp 中增加了有關(guān)重載，現(xiàn)在只要包含這個(gè)頭文件就能安全高效地使用 unordered_set<std::shared_ptr> 了。

這也是 muduo 的 examples/idleconnection 示例要自己定義 hash_value(const boost::shared_ptr<T>& x) 函數(shù)的原因（書第 7.10.2 節(jié)，p.255）。因?yàn)?Debian 6 Squeeze、Ubuntu 10.04 LTS 里的 boost 版本都有這個(gè) bug。

為什么圖 1 中的 ref_count 也有指向 Foo 的指針？

shared_ptr<Foo> sp(new Foo) 在構(gòu)造 sp 的時(shí)候捕獲了 Foo 的析構(gòu)行為。實(shí)際上 shared_ptr.ptr 和 ref_count.ptr 可以是不同的類型（只要它們之間存在隱式轉(zhuǎn)換），這是 shared_ptr 的一大功能。分 3 點(diǎn)來說：

1. 無需虛析構(gòu)；假設(shè) Bar 是 Foo 的基類，但是 Bar 和 Foo 都沒有虛析構(gòu)。

shared_ptr<Foo> sp1(new Foo); // ref_count.ptr 的類型是 Foo*

shared_ptr<Bar> sp2 = sp1; // 可以賦值，自動(dòng)向上轉(zhuǎn)型（up-cast）

sp1.reset(); // 這時(shí) Foo 對象的引用計(jì)數(shù)降為 1

此后 sp2 仍然能安全地管理 Foo 對象的生命期，并安全完整地釋放 Foo，因?yàn)槠?ref_count 記住了 Foo 的實(shí)際類型。

2. shared_ptr<void> 可以指向并安全地管理（析構(gòu)或防止析構(gòu)）任何對象；muduo::net::Channel class 的 tie() 函數(shù)就使用了這一特性，防止對象過早析構(gòu)，見書 7.15.3 節(jié)。

shared_ptr<Foo> sp1(new Foo); // ref_count.ptr 的類型是 Foo*

shared_ptr<void> sp2 = sp1; // 可以賦值，F(xiàn)oo* 向 void* 自動(dòng)轉(zhuǎn)型

sp1.reset(); // 這時(shí) Foo 對象的引用計(jì)數(shù)降為 1

此后 sp2 仍然能安全地管理 Foo 對象的生命期，并安全完整地釋放 Foo，不會(huì)出現(xiàn) delete void* 的情況，因?yàn)?delete 的是 ref_count.ptr，不是 sp2.ptr。

3. 多繼承。假設(shè) Bar 是 Foo 的多個(gè)基類之一，那么：

shared_ptr<Foo> sp1(new Foo);

shared_ptr<Bar> sp2 = sp1; // 這時(shí) sp1.ptr 和 sp2.ptr 可能指向不同的地址，因?yàn)?Bar subobject 在 Foo object 中的 offset 可能不為0。

sp1.reset(); // 此時(shí) Foo 對象的引用計(jì)數(shù)降為 1

但是 sp2 仍然能安全地管理 Foo 對象的生命期，并安全完整地釋放 Foo，因?yàn)?delete 的不是 Bar*，而是原來的 Foo*。換句話說，sp2.ptr 和 ref_count.ptr 可能具有不同的值（當(dāng)然它們的類型也不同）。

為什么要盡量使用 make_shared()？

為了節(jié)省一次內(nèi)存分配，原來 shared_ptr<Foo> x(new Foo); 需要為 Foo 和 ref_count 各分配一次內(nèi)存，現(xiàn)在用 make_shared() 的話，可以一次分配一塊足夠大的內(nèi)存，供 Foo 和 ref_count 對象容身。數(shù)據(jù)結(jié)構(gòu)是：

不過 Foo 的構(gòu)造函數(shù)參數(shù)要傳給 make_shared()，后者再傳給 Foo::Foo()，這只有在 C++11 里通過 perfect forwarding 才能完美解決。

最新評論