借來的資源,如何還的瀟灑?
掃描二維碼
隨時(shí)隨地手機(jī)看文章
每日一句英語學(xué)習(xí),每天進(jìn)步一點(diǎn)點(diǎn):
前言
本文的內(nèi)容將專門對(duì)付內(nèi)存管理,培養(yǎng)起有借有還的好習(xí)慣,方可消除資源管理的問題。
正文
所謂的資源就是,一旦用了它,將來必須還給系統(tǒng)。如果不是這樣,糟糕的事情就會(huì)發(fā)生。
C++ 程序內(nèi)常見的資源:
動(dòng)態(tài)分配內(nèi)存
文件描述符
互斥鎖
圖形頁面中的字型和筆刷
數(shù)據(jù)庫(kù)連接
網(wǎng)絡(luò) sockets
無論哪一種資源,重要的是,當(dāng)你不再使用它時(shí),必須將它還給系統(tǒng),有借有還是個(gè)好習(xí)慣。
細(xì)節(jié) 01 :以對(duì)象管理資源
把資源放在析構(gòu)函數(shù),交給析構(gòu)函數(shù)釋放資源
假設(shè)某個(gè) class 含有個(gè)工廠函數(shù),該函數(shù)獲取了對(duì)象的指針:
A* createA(); // 返回指針,指向的是動(dòng)態(tài)分配對(duì)象。
// 調(diào)用者有責(zé)任刪除它。
如上述注釋所言,createA 的調(diào)用端使用了函數(shù)返回的對(duì)象后,有責(zé)任刪除它?,F(xiàn)在考慮有個(gè)f
函數(shù)履行了這個(gè)責(zé)任:
void f()
{
A *pa = createA(); // 調(diào)用工廠函數(shù)
... // 其他代碼
delete pa; // 釋放資源
}
這看起來穩(wěn)妥,但存在若干情況f
函數(shù)可能無法執(zhí)行到delete pa
語句,也就會(huì)造成資源泄漏,例如如下情況:
或許因?yàn)椤浮箙^(qū)域內(nèi)的一個(gè)過早的 return 語句;
或許因?yàn)椤浮箙^(qū)域內(nèi)的一個(gè)循環(huán)語句過早的continue 或 goto 語句退出;
或許因?yàn)椤浮箙^(qū)域內(nèi)的語句拋出異常,無法執(zhí)行到 delete。
當(dāng)然可以通過謹(jǐn)慎地編寫程序可以防止這一類錯(cuò)誤,但你必須想想,代碼可能會(huì)在時(shí)間漸漸過去后被修改,如果是一個(gè)新手沒有注意這一類情況,那必然又會(huì)再次有內(nèi)存泄漏的可能性。
為確保 A 返回的資源都是被回收,我們需要將資源放進(jìn)對(duì)象內(nèi),當(dāng)對(duì)象離開作用域時(shí),該對(duì)象的析構(gòu)函數(shù)會(huì)自動(dòng)釋放資源。
「智能指針」是個(gè)好幫手,交給它去管理指針對(duì)象。
對(duì)于是由動(dòng)態(tài)分配(new)于堆內(nèi)存的對(duì)象,指針對(duì)象離開了作用域并不會(huì)自動(dòng)調(diào)用析構(gòu)函數(shù)(需手動(dòng)delete),為了讓指針對(duì)象能像普通對(duì)象一樣,離開作用域自動(dòng)調(diào)用析構(gòu)函數(shù)回收資源,我們需要借助「智能指針」的特性。
常用的「智能指針」有如下三個(gè):
std::auto_ptr( C++ 98 提供、C++ 11 建議摒棄不用 )
std::unique_ptr( C++ 11 提供 )
std::shared_ptr( C++ 11 提供 )
std::auto_ptr
下面示范如何使用 std::auto_ptr 以避免 f
函數(shù)潛在的資源泄漏可能性:
void f()
{
std::auto_ptr<A> pa (createA()); // 調(diào)用工廠函數(shù)
... // 一如既往的使用pa
} // 離開作用域后,經(jīng)由 auto_ptr 的析構(gòu)函數(shù)自動(dòng)刪除pa;
這個(gè)簡(jiǎn)單的例子示范「以對(duì)象管理資源」的兩個(gè)關(guān)鍵想法:
獲得資源后立刻放進(jìn)管理對(duì)象內(nèi)。以上代碼中 createA 返回的資源被當(dāng)做其管理者 auto_ptr 的初值,也就立刻被放進(jìn)了管理對(duì)象中。
管理對(duì)象運(yùn)用析構(gòu)函數(shù)確保資源釋放。不論控制流如何離開區(qū)塊,一旦對(duì)象被銷毀(例如當(dāng)對(duì)象離開作用域)其析構(gòu)函數(shù)自然會(huì)被自動(dòng)調(diào)用,于是資源被釋放。
為什么在 C++11 建議棄用 auto_ptr 嗎?當(dāng)然是 auto_ptr 存在缺陷,所以后續(xù)不被建議使用。
auto_ptr 有一個(gè)不尋常的特質(zhì):若通過「復(fù)制構(gòu)造函數(shù)或賦值操作符函數(shù)」 copy 它們,它們會(huì)變成 null ,而復(fù)制所得的指針將獲取資源的唯一擁有權(quán)!
見如下例子說明:
std::auto_ptr<A> pa1(createA()); // pa1 指向 createA 返回物
std::auto_ptr<A> pa2(pa1); // 現(xiàn)在 pa2 指向?qū)ο?,pa1將被設(shè)置為 null
pa1 = pa2; // 現(xiàn)在 pa1 指向?qū)ο?,pa2 將被設(shè)置為 null
這一詭異的復(fù)制行為,如果再次使用指向?yàn)?null 的指針,那必然會(huì)導(dǎo)致程序奔潰。
意味著 auto_ptr 并非管理動(dòng)態(tài)分配資源的神兵利器。
std::unique_ptr
unique_ptr 也采用所有權(quán)模型,但是在使用時(shí),是直接禁止通過復(fù)制構(gòu)造函數(shù)或賦值操作符函數(shù) copy 指針對(duì)象,如下例子在編譯時(shí),會(huì)出錯(cuò):
std::unique_ptr<A> pa1(createA()); // pa1 指向 createA 返回物
std::unique_ptr<A> pa2(pa1); // 編譯出錯(cuò)!
pa1 = pa2; // 編譯出錯(cuò)!
std::shared_ptr
shared_ptr 在使用復(fù)制構(gòu)造函數(shù)或賦值操作符函數(shù)后,引用計(jì)數(shù)會(huì)累加并且兩個(gè)指針對(duì)象指向的都是同一個(gè)塊內(nèi)存,這就與 unique_ptr、auto_ptr 不同之處。
void f()
{
std::shared_ptr<A> pa1(createA()); // pa1 指向 createA 返回物
std::shared_ptr<A> pa2(pa1); // 引用計(jì)數(shù)+1,pa2和pa1指向同一個(gè)內(nèi)存
pa1 = pa2; // 引用計(jì)數(shù)+1,pa2和pa1指向同一個(gè)內(nèi)存
}
當(dāng)一個(gè)對(duì)象離開作用域,shared_ptr 會(huì)把引用計(jì)數(shù)值 -1 ,直到引用計(jì)數(shù)值為 0 時(shí),才會(huì)進(jìn)行刪除對(duì)象。
由于 shared_ptr 釋放空間時(shí)會(huì)事先要判斷引用計(jì)數(shù)值的大小,因此不會(huì)出現(xiàn)多次刪除一個(gè)對(duì)象的錯(cuò)誤。
小結(jié) - 請(qǐng)記住
為防止資源泄漏,請(qǐng)使用 RAII(Resource Acquisition Is Initaliaztion - 資源取得時(shí)機(jī)便是初始化時(shí)機(jī)) 對(duì)象,它們?cè)跇?gòu)造函數(shù)中獲取資源,并在析構(gòu)函數(shù)中是釋放資源
兩個(gè)建議使用的 RAII classes 分別是 std::unique_ptr 和 std::shared_ptr。前者不允許 copy 動(dòng)作,后者允許 copy 動(dòng)作。但是不建議用 std::auto_ptr,若選 auto_ptr,復(fù)制動(dòng)作會(huì)使它(被復(fù)制物)指向 null 。
細(xì)節(jié) 02:在資源管理類中小心 copying 行為
假設(shè),我們使用 C 語音的 API 函數(shù)處理類型為 Mutex 的互斥對(duì)象,共有 lock 和 unlock 兩函數(shù)可用:
void locak(Mutex *pm); // 鎖定 pm 所指的互斥器
void unlock(Mutex* pm); // 將互斥器解除鎖定
為確保絕不會(huì)忘記一個(gè)被鎖住的 Mutex 解鎖,我們可能會(huì)希望創(chuàng)立一個(gè) class 來管理鎖資源。這樣的 class 要遵守 RAII 守則,也就是「資源在構(gòu)造期間獲得,在析構(gòu)釋放期間釋放」:
class Lock
{
public:
explicit Lock(Mutex *pm) // 構(gòu)造函數(shù)
: pMutex(pm)
{
lock(pMutex);
}
~Lock() // 析構(gòu)函數(shù)
{
unlock(pMutex);
}
private:
Mutex* pMutex;
};
這樣定義的 Lock,用法符合 RAII 方式:
Mutex m; //定義你需要的互斥鎖
...
{ // 建立一個(gè)局部區(qū)塊作用域
Lock m1(&m); // 鎖定互斥器
...
} // 在離開區(qū)塊作用域,自動(dòng)解除互斥器鎖定
這很好,但如果 Lock 對(duì)象被復(fù)制,會(huì)發(fā)生什么事情?
Lock m1(&m); // 鎖定m
Lock m2(&m1); // 將 m1 復(fù)制到 m2身上,這會(huì)發(fā)生什么?
這是我們需要思考和面對(duì)的:「當(dāng)一個(gè) RAII 對(duì)象被復(fù)制,會(huì)發(fā)生什么事情?」大多數(shù)時(shí)候你會(huì)選擇以下兩種可能:
禁止復(fù)制。如果 RAII 不允許被復(fù)制,那我們需要將 class 的復(fù)制構(gòu)造函數(shù)和賦值操作符函數(shù)聲明在 private。
使用引用計(jì)數(shù)法。有時(shí)候我們希望保有資源,直到它的最后一個(gè)對(duì)象被消耗。這種情況下復(fù)制 RAII 對(duì)象時(shí),應(yīng)該將資源的「被引用數(shù)」遞增。std::shared_ptr 便是如此。
如果前述的 Lock 打算使用使用引用計(jì)數(shù)法,它可以使用 std::shared_ptr 來管理 pMutex 指針,然后很不幸 std::shared_ptr 的默認(rèn)行為是「當(dāng)引用次數(shù)為 0 時(shí)刪除其所指物」那不是我們想要的行為,因?yàn)橐獙?duì)Mutex釋放動(dòng)作是解鎖而非刪除。
幸運(yùn)的是 std::shared_ptr 允許指定自定義的刪除方式,那是一個(gè)函數(shù)或函數(shù)對(duì)象。如下:
class Lock
{
public:
explicit Lock(Mutex *pm)
: pMutex(pm, unlock) // 以某個(gè) Mutex 初始化 shared_ptr,
// 并以 unlock 函數(shù)為刪除器。
{
lock(pMutex.get()); // get 獲取指針地址
}
private:
std::shared_ptr<Mutex> pMutex; // 使用 shared_ptr
};
請(qǐng)注意,本例的 Lock class 不再聲明析構(gòu)函數(shù)。因?yàn)榫幾g器會(huì)自動(dòng)創(chuàng)立默認(rèn)的析構(gòu)函數(shù),來自動(dòng)調(diào)用其 non-static 成員變量(本例為 pMutex )的析構(gòu)函數(shù)。
而 pMutex 的析構(gòu)函數(shù)會(huì)在互斥器的引用次數(shù)為 0 時(shí),自動(dòng)調(diào)用 std::shared_ptr 的刪除器(本例為 unlock )。
小結(jié) - 請(qǐng)記住
復(fù)制 RAII 對(duì)象必須一并復(fù)制它的所管理的資源(深拷貝),所以資源的 copying 行為決定 RAII 對(duì)象的 copying 行為。
普通而常見的 RAII class copying 行為是:禁止 copying、執(zhí)行引用計(jì)數(shù)法。
細(xì)節(jié) 03 :在資源類中提供對(duì)原始資源的訪問
智能指針「顯式」轉(zhuǎn)換,也就是通過 get 成員函數(shù)的方式轉(zhuǎn)換為原始指針對(duì)象。
上面提到的「智能指針」分別是:std::auto_ptr、std::unique_ptr、std::shared_ptr。它們都有訪問原始資源的辦法,都提供了一個(gè) get 成員函數(shù),用來執(zhí)行顯式轉(zhuǎn)換,也就是它會(huì)返回智能指針內(nèi)部的原始指針(的復(fù)件)。
舉個(gè)例子,使用智能指針如 std::shared_ptr 保存 createA() 返回的指針對(duì)象 :
std::shared_ptr<A> pA(createA());
假設(shè)你希望以某個(gè)函數(shù)處理 A 對(duì)象,像這樣:
int getInfo(const A* pA);
你想這么調(diào)用它:
std::shared_ptr<A> pA(createA());
getInfo(pA); // 錯(cuò)誤?。?/span>
會(huì)編譯錯(cuò)誤,因?yàn)?getInfo 需要的是 A
指針對(duì)象,而不是類型為 std::shared_ptr<A>
的對(duì)象。
這時(shí)候就需要用 std::shared_ptr 智能指針提供的 get
成員函數(shù)訪問原始的資源:
std::shared_ptr<A> pA(createA());
getInfo(pA.get()); // 很好,將 pA 內(nèi)的原始指針傳遞給 getInfo
智能指針「隱式」轉(zhuǎn)換的方式,是通過指針取值操作符。
智能指針都重載了指針取值操作符(operator->和operator*),它們?cè)试S隱式轉(zhuǎn)換至底部原始指針:
class A
{
public:
bool isExist() const;
...
};
A* createA(); // 工廠函數(shù),創(chuàng)建指針對(duì)象
std::shared_ptr<A> pA(createA()); // 令 shared_ptr 管理對(duì)象資源
bool exist = pA->isExist(); // 經(jīng)由 operator-> 訪問資源
bool exist2 = (*pA).isExist(); // 經(jīng)由 operator* 訪問資源
多數(shù)設(shè)計(jì)良好的 classes 一樣,它隱藏了程序員不需要看到的部分,但是有程序員需要的所有東西。
所以對(duì)于自身設(shè)計(jì) RAII classes 我們也要提供一個(gè)「取得其所管理的資源」的辦法。
小結(jié) - 請(qǐng)記住
APIs 往往要求訪問原始資源,所以每一個(gè) RAII class 應(yīng)該提供一個(gè)「取得其所管理的資源」的辦法。
對(duì)原始資源的訪問可能經(jīng)由顯式轉(zhuǎn)換或隱式轉(zhuǎn)換。一般而言顯式轉(zhuǎn)換比較安全,但隱式轉(zhuǎn)換比較方便。
細(xì)節(jié) 04:成對(duì)使用 new 和 delete
以下動(dòng)作有什么錯(cuò)?
std::string* strArray = new std::string[100];
...
delete strArray;
每件事情看起來都井然有序。使用了 new,也搭配了對(duì)應(yīng)的 delete。但還是有某樣?xùn)|西完全錯(cuò)誤。strArray 所含的 100 個(gè) string 對(duì)象中的 99 個(gè)不太可能被適當(dāng)刪除,因?yàn)樗鼈兊奈鰳?gòu)函數(shù)很可能沒有被調(diào)用。
當(dāng)使用 new ,有兩件事發(fā)生:
內(nèi)存被分配出來(通過名為 operator new 的函數(shù))
針對(duì)此內(nèi)存會(huì)有一個(gè)或多個(gè)構(gòu)造函數(shù)被調(diào)用
當(dāng)使用 delete,也會(huì)有兩件事情:
針對(duì)此內(nèi)存會(huì)有一個(gè)或多個(gè)析構(gòu)函數(shù)被調(diào)用
然后內(nèi)存才被釋放(通過名為 operator delete 的函數(shù))
delete 的最大問題在于:即將被刪除的內(nèi)存之內(nèi)究竟有多少對(duì)象?這個(gè)答案決定了需要執(zhí)行多少個(gè)析構(gòu)函數(shù)。
對(duì)象數(shù)組所用的內(nèi)存通常還包括「數(shù)組大小」的記錄,以便 delete 知道需要調(diào)用多少次析構(gòu)函數(shù)。單一對(duì)象的內(nèi)存則沒有這筆記錄。你可以把兩者不同的內(nèi)存布局想象如下,其中 n 是數(shù)組大?。?/p>
當(dāng)你對(duì)著一個(gè)指針使用 delete,唯一能夠讓 delete 知道內(nèi)存中是否存在一個(gè)「數(shù)組大小記錄」的辦法就是:由你告訴它。如果你使用 delete 時(shí)加上中括號(hào)[],delete 便認(rèn)定指針指向一個(gè)數(shù)組,否則它便認(rèn)定指針指向一個(gè)單一對(duì)象:
std::string* strArray = new std::string[100];
std::string* strPtr = new std::strin;
...
delete [] strArray; // 刪除一個(gè)對(duì)象數(shù)組
delete strPtr; // 刪除一個(gè)對(duì)象
游戲規(guī)則很簡(jiǎn)單:
如果你在 new 表達(dá)式中使用[],必須在相應(yīng)的 delete 表達(dá)式也使用[]。
如果你在 new 表達(dá)式中不使用[],一定不要在相應(yīng)的 delete 表達(dá)式使用[]。
小結(jié) - 請(qǐng)記住
如果你在 new 表達(dá)式中使用[],必須在相應(yīng)的 delete 表達(dá)式也使用[]。如果你在 new 表達(dá)式中不使用[],一定不要在相應(yīng)的 delete 表達(dá)式使用[]。
細(xì)節(jié) 05:以獨(dú)立語句將 newed 對(duì)象置入智能指針
假設(shè)我們有個(gè)以下示范的函數(shù):
int getNum();
void fun(std::shared_ptr<A> pA, int num);
現(xiàn)在考慮調(diào)用 fun:
fun(new A(), getNum());
它不能通過編譯,因?yàn)?std::shared_ptr
構(gòu)造函數(shù)需要一個(gè)原始指針,而且該構(gòu)造函數(shù)是個(gè) explicit
構(gòu)造函數(shù),無法進(jìn)行隱式轉(zhuǎn)換。如果寫成這樣就可以編譯通過:
fun(std::shared_ptr<A>(new A), getNum());
令人想不到吧,上述調(diào)用卻可能泄露資源。接下來我們來一步一步的分析為什么存在內(nèi)存泄漏的可能性。
在進(jìn)入 fun
函數(shù)之前,肯定會(huì)先執(zhí)行各個(gè)實(shí)參。上述第二個(gè)實(shí)參只是單純的對(duì) getNum
函數(shù)的調(diào)用,但第一個(gè)實(shí)參 std::shared_ptr<A>(new A)
由兩部分組成:
執(zhí)行
new A
表達(dá)式調(diào)用
std::shared_ptr
構(gòu)造函數(shù)
于是在調(diào)用 fun
函數(shù)之前,先必須做以下三件事:
調(diào)用
getNum
函數(shù)執(zhí)行
new A
表達(dá)式調(diào)用
std::shared_ptr
構(gòu)造函數(shù)
那么他們的執(zhí)行次序是一定如上述那樣的嗎?可以確定的是 new A
一定比 std::shared_ptr
構(gòu)造函數(shù)先被執(zhí)行。但對(duì) getNum 調(diào)用可以排在第一或第二或第三執(zhí)行。
如果編譯器選擇以第二順位執(zhí)行它:
執(zhí)行
new A
表達(dá)式調(diào)用
getNum
函數(shù)調(diào)用
std::shared_ptr
構(gòu)造函數(shù)
萬一在調(diào)用getNum
函數(shù)發(fā)生了異常,會(huì)發(fā)生什么事情?在此情況下new A
返回的指針將不會(huì)置入std::shared_ptr
智能指針里,就存在內(nèi)存泄漏的現(xiàn)象。
避免這類問題的辦法很簡(jiǎn)單:使用分離語句。
分別寫出:
創(chuàng)建 A
將它置入一個(gè)智能指針內(nèi)
然后再把智能指針傳遞給
fun
函數(shù)。
std::shared_ptr<A> pA(new A); // 先構(gòu)造智能指針對(duì)象
fun(pA, getNum()); // 這個(gè)調(diào)用動(dòng)作絕不至于造成泄漏。
以上的方式,就能避免原本由于次序?qū)е聝?nèi)存泄漏發(fā)生。
小結(jié) - 請(qǐng)記住
以獨(dú)立語句將 newed (已 new 過) 對(duì)象存儲(chǔ)于智能指針內(nèi)。如果不這樣做,一旦異常被拋出,有可能導(dǎo)致難以察覺的資源泄漏。
最后
本文部分內(nèi)容參考了《Effective C++ (第3版本)》第三章節(jié)內(nèi)容,前兩章節(jié)的總結(jié)內(nèi)容可看舊文「學(xué)過 C++ 的你,不得不知的這 10 條細(xì)節(jié)!」
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺(tái)立場(chǎng),如有問題,請(qǐng)聯(lián)系我們,謝謝!