問題描述

在基于C++的大型系統(tǒng)的設(shè)計(jì)實(shí)現(xiàn)中，由于缺乏語言級別的GC支持，資源生存周期往往是一個(gè)棘手的問題。系統(tǒng)地解決這個(gè)問題的方法無非兩種：

• 使用GC庫
• 使用引用計(jì)數(shù)

嚴(yán)格地說，引用計(jì)數(shù)其實(shí)也是一種最樸素的GC。相對于現(xiàn)代的GC技術(shù)，引用計(jì)數(shù)的實(shí)現(xiàn)簡單，但相應(yīng)地，它也存在著循環(huán)引用和線程同步開銷等問題。

關(guān)于這二者孰優(yōu)孰劣，已經(jīng)有過很多討論，在此就不攪這股混水了。我一直也沒有使用過C++的GC庫，在實(shí)際項(xiàng)目中總是采用引用計(jì)數(shù)的方案。而作為Boost的擁躉，首選的自然是shared_ptr。一直以來我也對shared_ptr百般推崇，然而最近的一些項(xiàng)目開發(fā)經(jīng)驗(yàn)卻讓我在shared_ptr上栽了坑，對C++引用計(jì)數(shù)也有了一些新的的認(rèn)識(shí)，遂記錄在此。

本文主要針對基于boost::shared_ptr的C++引用計(jì)數(shù)實(shí)現(xiàn)方案進(jìn)行一些討論。C++引用計(jì)數(shù)方案往往伴隨著用于自動(dòng)管理引用計(jì)數(shù)的智能指針。按是否要求資源對象自己維護(hù)引用計(jì)數(shù)，C++引用計(jì)數(shù)方案可以分為兩類：

• 侵入式：侵入式的引用計(jì)數(shù)管理要求資源對象本身維護(hù)引用計(jì)數(shù)，同時(shí)提供增減引用計(jì)數(shù)的管理接口。通常侵入式方案會(huì)提供配套的侵入式引用計(jì)數(shù)智能指針。該智能指針通過調(diào)用資源對象的引用計(jì)數(shù)管理接口來自動(dòng)增減引用計(jì)數(shù)。COM對象與CComPtr便是侵入式引用計(jì)數(shù)的一個(gè)典型實(shí)例。
• 非侵入式：非侵入式的引用計(jì)數(shù)管理對資源對象本身沒有任何要求，而是完全借助非侵入式引用計(jì)數(shù)智能指針在資源對象外部維護(hù)獨(dú)立的引用計(jì)數(shù)。shared_ptr便是基于這個(gè)思路。

第一宗罪

初看起來，非侵入式方案由于對資源對象的實(shí)現(xiàn)沒有任何要求，相較于侵入式方案更具吸引力。然而事實(shí)卻并非如此。下面就來分析一下基于shared_ptr的非侵入式引用計(jì)數(shù)。在使用shared_ptr的引用計(jì)數(shù)解決方案中，引用計(jì)數(shù)完全由shared_ptr控制，資源對象對與自己對應(yīng)的引用計(jì)數(shù)一無所知。

而引用計(jì)數(shù)與資源對象的生存期息息相關(guān)，這就意味著資源對象喪失了對生存期的控制權(quán)，將自己的生殺大權(quán)拱手讓給了shared_ptr。這種情況下，資源對象就不得不依靠至少一個(gè)shared_ptr實(shí)例來保障自己的生存。換言之，資源對象一旦“沾染”了shared_ptr，就一輩子都無法擺脫！考察以下的簡單用例：

用例一：

Resource*p=newCResource;
{
shared_ptrq(p);
}
p->Use()//CRASH

單純?yōu)榱私鉀Q上述的崩潰，可以自定義一個(gè)什么也不做的deleter：

structnoop_deleter{
voidoperator()(void*){
//NO-OP
}
};

然后將上述用例的第三行改為：

shared_ptrq(p,noop_deleter());

但是這樣一來，shared_ptr就喪失了借助RAII自動(dòng)釋放資源的能力，違背了我們利用智能指針自動(dòng)管理資源生存期的初衷（話說回來，這倒并不是說noop_deleter這種手法毫無用處，Boost.Asio中就巧妙地利用shared_ptr、weak_ptr和noop_deleter來實(shí)現(xiàn)異步I/O事件的取消）。

從這個(gè)簡單的用例可以看出，shared_ptr就像是毒品一樣，一旦沾染就難以戒除。更甚者，染毒者連換用其他“毒品”的權(quán)力都沒有：shared_ptr的引用計(jì)數(shù)管理接口是私有的，無法從shared_ptr之外操控，也就無法從shared_ptr遷移到其他類型的引用計(jì)數(shù)智能指針。

不僅如此，資源對象沾染上shared_ptr之后，就只能使用最初的那個(gè)shared_ptr實(shí)例的拷貝來維系自己的生存期。考察以下用例：用例二：

{
shared_ptrp1(newCResource);
shared_ptrp2(p1);//OK
CResource*p3=p1.get();
shared_ptrp4(p3);//ERROR
//CRASH
}

該用例的執(zhí)行過程如下：

1. p1在構(gòu)造的同時(shí)為資源對象創(chuàng)建了一份外部引用計(jì)數(shù)，并將之置為1
2. p2拷貝自p1，與p1共享同一個(gè)引用計(jì)數(shù)，將之增加為2
3. p4并非p1的拷貝，因此在構(gòu)造的同時(shí)又為資源對象創(chuàng)建了另外一個(gè)外部引用計(jì)數(shù)，并將之置為1
4. 在作用域結(jié)束時(shí)，p4析構(gòu)，由其維護(hù)的額外的引用計(jì)數(shù)降為0，導(dǎo)致資源對象被析構(gòu)
5. 然后p2析構(gòu)，對應(yīng)的引用計(jì)數(shù)降為1
6. 接著p1析構(gòu)，對應(yīng)的引用計(jì)數(shù)也歸零，于是p1在臨死之前再次釋放資源對象 最后，由于資源對象被二次釋放，程序崩潰

至此，我們已經(jīng)認(rèn)識(shí)到了shared_ptr的第一宗罪——傳播毒品：

• 毒性一：一旦開始對資源對象使用shared_ptr，就必須一直使用
• 毒性二：無法換用其他類型的引用計(jì)數(shù)之智能指針來管理資源對象生存期
• 毒性三：必須使用最初的shared_ptr實(shí)例拷貝來維系資源對象生存期

第二宗罪

乘勝追擊，再揭露一下shared_ptr的第二宗罪——散布病毒。有點(diǎn)聳人聽聞了？其實(shí)道理很簡單：由于使用了shared_ptr的資源對象必須仰仗shared_ptr的存在才能維系生存期，這就意味著使用資源的客戶對象也必須使用shared_ptr來持有資源對象的引用——于是shared_ptr的勢力范圍成功地從資源對象本身擴(kuò)散到了資源使用者，侵入了資源客戶對象的實(shí)現(xiàn)。

同時(shí)，資源的使用者往往是通過某種形式的資源分配器來獲取資源。自然地，為了向客戶轉(zhuǎn)交資源對象的所有權(quán)，資源分配器也不得不在接口中傳遞shared_ptr，于是shared_ptr也會(huì)侵入資源分配器的接口。

有一種情況可以暫時(shí)擺脫shared_ptr，例如：

shared_ptrAllocateResource(){
shared_ptrpResource(newCResource);
InitResource(pResource.get());
returnpResource;
}
voidInitResource(IResource*r){
//Doresourceinitialization...
}

以上用例中，在InitResource的執(zhí)行期間，由于AllocateResource的堆棧仍然存在，pResource不會(huì)析構(gòu)，因此可以放心的在InitResource的參數(shù)中使用裸指針傳遞資源對象。這種基于調(diào)用棧的引用計(jì)數(shù)優(yōu)化，也是一種常用的手段。但在InitResource返回后，資源對象終究還是會(huì)落入shared_ptr的魔掌。

由此可以看出，shared_ptr打著“非侵入式”的幌子，雖然沒有侵入資源對象的實(shí)現(xiàn)，卻侵入了資源分配接口以及資源客戶對象的實(shí)現(xiàn)。而沾染上shared_ptr就擺脫不掉，如此傳播下去，簡直就是侵入了除資源對象實(shí)現(xiàn)以外的其他各個(gè)地方！這不是病毒是什么？

然而，基于shared_ptr的引用計(jì)數(shù)解決方案真的不會(huì)侵入資源對象的實(shí)現(xiàn)嗎？

第三宗罪

在一些用例中，資源對象的成員方法（不包括構(gòu)造函數(shù)）需要獲取指向?qū)ο笞陨?，即包含了this指針的shared_ptr。Boost.Asio的chat示例便展示了這樣一個(gè)用例：chat_session對象會(huì)在其成員函數(shù)中發(fā)起異步I/O操作，并在異步I/O操作回調(diào)中保存一個(gè)指向自己的shared_ptr以保證回調(diào)執(zhí)行時(shí)自身的生存期尚未結(jié)束。

這種手法在Boost.Asio中非常常見，在不考慮shared_ptr帶來的麻煩時(shí)，這實(shí)際上也是一種相當(dāng)優(yōu)雅的異步流程資源生存期處理方法。但現(xiàn)在讓我們把注意力集中在shared_ptr上。

通常，使用shared_ptr的資源對象必須動(dòng)態(tài)分配，最常見的就是直接從堆上new出一個(gè)實(shí)例并交付給一個(gè)shared_ptr，或者也可以從某個(gè)資源池中分配再借助自定義的deleter在引用計(jì)數(shù)歸零時(shí)將資源放回池中。無論是那種用法，該資源對象的實(shí)例在創(chuàng)建出來后，都總是立即交付給一個(gè)shared_ptr（記為p）。

有鑒于之前提到的毒性三，如果資源對象的成員方法需要獲取一個(gè)指向自己的shared_ptr，那么這個(gè)shared_ptr也必須是p的一個(gè)拷貝——或者更本質(zhì)的說，必須與p共享同一個(gè)外部引用計(jì)數(shù)。然而對于資源對象而言，p維護(hù)的引用計(jì)數(shù)是外部的陌生事物，資源對象如何得到這個(gè)引用計(jì)數(shù)并由此構(gòu)造出一個(gè)合法的shared_ptr呢？這是一個(gè)比較tricky的過程。為了解決這個(gè)問題，Boost提供了一個(gè)類模板e(cuò)nable_shared_from_this：

所有需要在成員方法中獲取指向this的shared_ptr的類型，都必須以CRTP手法繼承自enable_shared_from_this。即：

classCResource:
publicboost::enable_shared_from_this
{
//...
};

接著，資源對象的成員方法就可以使用enable_shared_from_this::shared_from_this()方法來獲取所需的指向?qū)ο笞陨淼膕hared_ptr了。問題似乎解決了。但是，等等！這樣的繼承體系不就對資源對象的實(shí)現(xiàn)有要求了嗎？換言之，這不正是對資源對象實(shí)現(xiàn)的赤裸裸的侵入嗎？這正是shared_ptr的第三宗罪——欺世盜名。

第四宗罪

最后一宗罪，是鋪張浪費(fèi)。對了，說的就是性能。

基于引用計(jì)數(shù)的資源生存期管理，打一出生起就被扣著線程同步開銷大的帽子。早期的Boost版本中，shared_ptr是借助Boost.Thread的mutex對象來保護(hù)引用計(jì)數(shù)。在后期的版本中采用了lock-free的原子整數(shù)操作一定程度上降低了線程同步開銷。然而即使是lock-free，本質(zhì)上也仍然是串行化訪問，線程同步的開銷多少都會(huì)存在。

也許有人會(huì)說這點(diǎn)開銷與引用計(jì)數(shù)帶來的便利相比算不得什么。然而在我們項(xiàng)目的異步服務(wù)器框架的壓力測試中，大量引用計(jì)數(shù)的增減操作，一舉吃掉了5%的CPU。換言之，1/20的計(jì)算能力被浪費(fèi)在了與業(yè)務(wù)邏輯完全無關(guān)的引用計(jì)數(shù)的維護(hù)上！而且，由于是異步流程的特殊性，也無法應(yīng)用上面提及的基于調(diào)用棧的引用計(jì)數(shù)優(yōu)化。

那么針對這個(gè)問題就真的沒有辦法了嗎？其實(shí)仔細(xì)檢視一下整個(gè)異步流程，有些資源雖然會(huì)先后被不同的對象所引用，但在其整個(gè)生存周期內(nèi)，每一時(shí)刻都只有一個(gè)對象持有該資源的引用。用于數(shù)據(jù)收發(fā)的緩沖區(qū)對象就是一個(gè)典型。它們總是被從某個(gè)源頭產(chǎn)生，然后便一直從一處被傳遞到另一處，最終在某個(gè)時(shí)刻被回收。

對于這樣的對象，實(shí)際上沒有必要針對流程中的每一次所有權(quán)轉(zhuǎn)移都進(jìn)行引用計(jì)數(shù)操作，只要簡單地在分配時(shí)將引用計(jì)數(shù)置1，在需要釋放時(shí)再將引用計(jì)數(shù)歸零便可以了。

對于侵入式引用計(jì)數(shù)方案，由于資源對象自身持有引用計(jì)數(shù)并提供了引用計(jì)數(shù)的操作接口，可以很容易地實(shí)現(xiàn)這樣的優(yōu)化。但shared_ptr則不然。shared_ptr把引用計(jì)數(shù)牢牢地攥在手中，不讓外界碰觸；外界只有通過shared_ptr的構(gòu)造函數(shù)、析夠函數(shù)以及reset()方法才能夠間接地對引用計(jì)數(shù)進(jìn)行操作。

而由于shared_ptr的毒品特性，資源對象無法脫離shared_ptr而存在，因此在轉(zhuǎn)移資源對象的所有權(quán)時(shí)，也必須通過拷貝shared_ptr的方式進(jìn)行。一次拷貝就對應(yīng)一對引用計(jì)數(shù)的原子增減操作。

對于上述的可優(yōu)化資源對象，如果在一個(gè)流程中被傳遞3次，除去分配和釋放時(shí)的2次，還會(huì)導(dǎo)致6次無謂的原子整數(shù)操作。整整浪費(fèi)了300%！

事實(shí)證明，在將基于shared_ptr的非侵入式引用計(jì)數(shù)方案更改為侵入式引用計(jì)數(shù)方案并施行上述優(yōu)化后，我們的異步服務(wù)器框架的性能有了明顯的提升。

結(jié)語

最后總結(jié)一下shared_ptr的四宗罪：

• 傳播毒品一旦對資源對象染上了shared_ptr，在其生存期內(nèi)便無法擺脫。
• 散布病毒在應(yīng)用了shared_ptr的資源對象的所有權(quán)變換的整個(gè)過程中的所有接口都會(huì)受到shared_ptr的污染。
• 欺世盜名在enable_shared_from_this用例下，基于shared_ptr的解決方案并非是非侵入式的。
• 鋪張浪費(fèi)由于shared_ptr隱藏了引用計(jì)數(shù)的操作接口，只能通過拷貝shared_ptr的方式間接操縱引用計(jì)數(shù)，使得用戶難以規(guī)避不必要的引用計(jì)數(shù)操作，造成無謂的性能損失。

探明這四宗罪算是最近一段時(shí)間的項(xiàng)目設(shè)計(jì)開發(fā)過程的一大收獲。寫這篇文章的目的不是為了將shared_ptr一棒子打死，只是為了總結(jié)基于shared_ptr的C++非侵入式引用計(jì)數(shù)解決方案的缺陷，也讓自己不再盲目迷信shared_ptr。