智能指針使用上的問題

智能指針的使用太普遍了，它讓程序員擺脫了內(nèi)存管理的惡夢，但實際上智能指針本身也可能引入另一個惡夢。主要包括兩個問題點:

性能問題。因為需要引入一些變量(bookkeeping)，甚至在多線程下的一些互斥操作，它所帶來的性能開銷往往比想像的要高。比如以智能指針作為函數(shù)參數(shù)以及返回值時。對象釋放的時機不明確。比如std::auto_ptr，總讓人感覺不明不白。而有時一些循環(huán)引用，又會導(dǎo)致內(nèi)存泄露。

所以即便有了智能指針，程序員還是要認真考慮使用它們的時機。

智能指針的本質(zhì)是所有權(quán)管理

所有權(quán)(Ownership)是一個用來管理動態(tài)分配內(nèi)存的記錄(bookkeeping)技術(shù)。動態(tài)分配內(nèi)存的所有者需要負責(zé)在所分配內(nèi)存不再需要時釋放它。共享所有權(quán)時，最后一個owner負責(zé)清理。即使不是共享，也可以在代碼間傳遞Ownership。

運用智能指針的核心是保持所有權(quán)(Ownership)的明確、清晰。一般情況下是保證所有權(quán)的單一，無論是使用WeakPtr, Scoped Pointer都可以保持所有權(quán)的單一，這時所有權(quán)可以在不同的對象/代碼段轉(zhuǎn)移。另一種情況就是需要共享所有權(quán)，比較常用的引用指數(shù)智能指針，就是幫助完成共享所有權(quán)的。

概括起來三個要點：

1.局部化?
推薦保持單一、固定的所有權(quán)。當所有權(quán)需要在不同代碼段間傳遞時，就要使用智能指針。?
2.明確的清理時機。?
使用引用計數(shù)，和std::auto_ptr都會引發(fā)對釋放時機的疑問。有可能引入一些隱晦的Bug。當需要共享所有權(quán)時，一定要先思考這個設(shè)計的必要性，以及內(nèi)存釋放的時機是否明確、清晰。?
3.最好的方式不要使用指針?？梢允褂靡脕泶嬷羔?。見后面WebKit的故事。

大型項目中的應(yīng)用Google Coding Style的約定

如果需要動態(tài)分配內(nèi)存，盡量由分配的代碼來持有所有權(quán)。?
如果另一段代碼需要訪問對象，先考慮傳遞對象拷貝，指針或者引用，而不是傳遞所有權(quán)。如果確有需要時，建議使用std::unique_ptr來顯示的傳遞所有權(quán)（使用std::move()）。?
除非有好的理由，否則不要共享所有權(quán)。比如為了避免復(fù)制。這時需要確定有明顯的性能收益，而且所持有的對象最好是只讀的, 同時建議使用std::shared_ptr:

std::shared_ptr;

1

新代碼里不要再使用scoped_ptr，更不要使用std::auto_ptr, 而是使用std::unique_ptr來代替。

WebKit的故事

WebKit文檔記錄了他們使用引用計數(shù)指針的故事，詳情見:RefPtr Basics。大意為:?
早在2005年時為了解決內(nèi)存泄露問題，開始使用基于引用計數(shù)的智能指針，但是它有性能問題，特別是當作函數(shù)參數(shù)和返回值傳遞時。后來使用C++11提供move語義（即轉(zhuǎn)移所有權(quán)的方式）來解決了這個問題。(另外shared_ptr const & 的形式也可以避免不必要的引用計數(shù)操作。)

而到了2013年，WebKit的開發(fā)者發(fā)現(xiàn)泛濫的判空和有效性檢查，于是開始傾向于盡可能地使用引用（注意：不是引用計數(shù)指針）, 而不是指針。

小結(jié)

解決內(nèi)存問題的最佳的途徑仍然是由程序員管理好對象的生命周期。使用智能指針也是有成本的，同時也會引入一些新問題，所以需要遵循一些約定來使用。Google Chromium/Webkit都有相應(yīng)用的定義:

Chromium: Smart Pointer GuidelineWebKit: RefPtr Basics

另外明確約定一個函數(shù)是否會返回空指針,特別是對于API來說，也會幫助使用者避免一些不必要的判空處理和一些隱晦的Bug。

進一步學(xué)習(xí):

unique_ptr使用簡介Reference counting smart pointers are for retards.