說到 C/C++ 的資源管理，人人都會頭痛半天。自從 C++0x （就是 C++09 了）標(biāo)準(zhǔn)漏出風(fēng)聲之后， C++ 標(biāo)準(zhǔn)是否會引入自動垃圾回收機(jī)制就成為了眾多 C++ 愛好者談?wù)摰脑掝}。但是實際上，在 C++ 標(biāo)準(zhǔn)的探索上，垃圾回收一直處在一個十分低下的地位。造成其這一處境的原因很多，也很復(fù)雜。我們來看看站在 C++ 程序員的角度上看，資源管理機(jī)制現(xiàn)在所面臨的局勢。

從系統(tǒng)結(jié)構(gòu)上來講， C/C++ 支持 3 種內(nèi)存管理方式，基于棧的自動管理，基于堆的動態(tài)管理，和基于全局區(qū)的靜態(tài)管理。由于 RAII 的理念，對于 C++ 來說，內(nèi)存管理和其他資源管理本質(zhì)上沒有區(qū)別。因此對于資源而言，也就自然的擁有這樣 3 種管理方式。

首先簡要的介紹一下 RAII 。 RAII 的全稱是 Resource Acquisition Is initialization 。這個思想的基本手法是對于一種想要使用的資源，為其書寫一個 guard 類，在該類的構(gòu)造函數(shù)里進(jìn)行資源的請求，在析構(gòu)函數(shù)里進(jìn)行資源的釋放。例如假設(shè)我們想管理一個互斥鎖，可能的方式是：

struct  lock_guard
{
        lock_guard() { lock ();}
         ~ lock_guard() {unlock();}
} ;

     此后，對這個對象使用什么內(nèi)存管理方式，也就等價于對這個互斥鎖使用什么內(nèi)存管理方式。

         借助于 RAII ，以后我們可以只討論內(nèi)存資源的管理方式，其它資源的管理方式可以使用 RAII 來同樣的實現(xiàn)。現(xiàn)在我們已經(jīng)很自然的獲得了資源管理的 3 種方式：基于堆的動態(tài)方式、基于棧的自動方式和全局。值得一提的是，這 3 種方式中比較不容易出錯的后兩種實際上可以解決大部分的資源管理需求。因為絕大部分資源，都屬于獲取 - 使用 - 釋放型的，例如很多同步對象，文件鎖， WinGDI 里的許多 GDI 對象。我們?nèi)狈芾淼模挥心切┮淮潍@得，多個環(huán)境擁有，并且只能有一次釋放的少數(shù)資源。

         回到內(nèi)存模型來看，有一點讓我們無法將內(nèi)存與其它資源等同（反過來，把其它資源和內(nèi)存等同卻是可以的），那就是循環(huán)引用。 A 內(nèi)存可以持有指向 B 內(nèi)存的引用， B 內(nèi)存也可以反過來持有 A 內(nèi)存的引用。循環(huán)引用導(dǎo)致內(nèi)存管理不可以用“是否有指向該內(nèi)存的引用”來區(qū)分一塊內(nèi)存是否可以回收。從而喪失了一個絕佳的管理手段。但是在沒有循環(huán)引用的場合下，我們還是有非常簡潔高效的管理方法的。那就是引用計數(shù)。

         引用計數(shù)是在沒有循環(huán)引用場合下進(jìn)行內(nèi)存管理的絕佳手段，它具有輕量、高效、即時、可控的優(yōu)點。而且在 C++ 里，引用計數(shù)已經(jīng)非常成熟，只需要使用 boost.shared_ptr 或者其它非官方的引用計數(shù)指針庫就可以了，而且據(jù)悉 C++09 很可能把 boost.shared_ptr 納入標(biāo)準(zhǔn)庫。引用計數(shù)的原則是，如果一個對象沒有別的指針或引用來指向它，那么這個對象就是可以釋放的。具體的手法有大把大把的資料可以查閱，這里就不詳細(xì)說明了。引用計數(shù)通常可以處理哪些場合的資源管理問題呢？首先，對于單方向的資源管理，也就是多個 A 的實體擁有 1 個 B ，然而 B 并不會反過來依賴于 A （例如多個對象共享一個日志），引用計數(shù)是非常合適的。其次，對于擁有 - 反作用的場合，也就是 1 個或多個 A 的實體擁有 1 個或多個 B ，而 B 也擁有這些 A 的實體的引用，但是 B 的生存期仍然決定于 A 的生存期（例如父窗口擁有若干子窗口，子窗口也具有 parent 指針指向父窗口，但是子窗口的生存期決定于父窗口的生存期），這個時候 A 可以對 B 使用引用計數(shù)指針，而 B 可以對 A 使用原生的普通指針，同樣的可以很好的解決問題。

         現(xiàn)在所剩下的，就只有生存期的循環(huán)依賴了。如果 AB 互相持有對方的引用，而且 AB 互相的存在都依賴于對方，這樣引用計數(shù)就無法解決了。但是如果仔細(xì)想一下就會發(fā)現(xiàn)，這種情況在 C++ 里幾乎不可能存在。生存期循環(huán)依賴只有 2 種后果，要么 A 和 B 的析構(gòu)函數(shù)里互相析構(gòu)（當(dāng)然就掛了），要么互相都不析構(gòu)（當(dāng)然就泄露了）。而這兩種都是在正常編程中不會出現(xiàn)的情況。所以如果即使僅僅使用引用計數(shù)，我們也可以解決幾乎所有的資源管理問題。

現(xiàn)在還剩下那么一丁點極少出現(xiàn)的不能處理的情況，我們可以使用更加復(fù)雜的 gc 來實現(xiàn)。可惜的是，實現(xiàn)一個 gc 所要耗費的精力實在太大，而且?guī)缀醪豢杀苊獾囊蔀榍秩胧降膸臁Ｋ杂悬c得不償失。而且 gc 通常會產(chǎn)生更多的毛病：

1．               你無法卻知對象析構(gòu)的具體時間，從而無法真正知道影響程序性能的瓶頸在什么地方。

2．               gc 都傾向于大量的使用內(nèi)存，直到內(nèi)存不夠的時候再進(jìn)行清理，這樣會導(dǎo)致程序的內(nèi)存用量嚴(yán)重顛簸，并且產(chǎn)生大量的換頁。

3．               過度的依賴于 gc 會使程序員大量的把可以由之前提到的各種方法來處理的資源交給 gc 來處理，無故的加重了 gc 的負(fù)擔(dān)。

4．               gc 的管理方法和 C++ 的析構(gòu)函數(shù)有可能產(chǎn)生語義上的沖突。

這就是為什么 C++ 標(biāo)準(zhǔn)對垃圾回收的態(tài)度如此惡劣的原因。

我們現(xiàn)在回過頭來看 Java/C# 這樣的內(nèi)置 gc 的語言。這樣的語言由于使用了 gc ，就不可避免的放棄了析構(gòu)函數(shù)。為什么 gc 會和析構(gòu)函數(shù)產(chǎn)生沖突呢？一個 gc 一般會希望在進(jìn)行垃圾回收的時候，整個過程是一個原子的，但析構(gòu)函數(shù)會破壞這一點，在釋放內(nèi)存的時候如果還要執(zhí)行代碼，那么難免會對整個 gc 環(huán)境產(chǎn)生破壞性的影響。由于沒有析構(gòu)函數(shù)，這些語言就不可能做到 RAII ，也就是說，它們的 gc 所能夠管理的，也就僅僅只有內(nèi)存而已了。對于其他資源， Java 等就必須手動釋放。雖然 C# 提供了 with 關(guān)鍵字來緩解這一問題，但仍然無法徹底的解決。

還有什么麻煩呢？之前說的那 4 點全部都有。雖然 JVM 的速度在不斷的提高，但是內(nèi)存使用這一點卻完全沒有發(fā)展，不能不說是 gc 說導(dǎo)致。它所帶來了什么好處呢？是內(nèi)存管理的自動化，而不是資源管理的自動化。

所以說 C++ 并不是世人所想象的那樣需要 gc ， C++ 本身就已經(jīng)提供了足夠強(qiáng)大的資源管理能力。基于棧的自動管理，或者使用引用計數(shù)，幾乎可以達(dá)到和 gc 同樣的覆蓋面，而且沒有 gc 的那些問題， RAII 使得 C++ 在管理非內(nèi)存資源的時候還更加有優(yōu)勢，為什么不使用呢？

ps. 設(shè)計一個非官方的 gc 庫還是可以的。但是畢竟不會成為主流了。