2012年軟件水平輔導(dǎo)：漫談C++內(nèi)存分配失敗
沒(méi)錯(cuò)，是“漫談”，而且“漫”得有點(diǎn)亂。然而，拋磚尚可引玉，想到的事情，縱然脈絡(luò)不那么順，寫下來(lái)也不是壞事。開卷有益，動(dòng)筆也有益。
一切緣自一位C語(yǔ)言開發(fā)經(jīng)驗(yàn)豐富的的朋友問(wèn)我的一個(gè)問(wèn)題。朋友問(wèn)：“C++中的new在分配內(nèi)存失敗時(shí)會(huì)拋出異常（std：：bad_alloc）而不返回0（一些老的編譯器可能還在返回0，但這樣的編譯器實(shí)在”太老了“），這跟C程序員的做法很不一樣。而且，許多C++程序在使用new創(chuàng)建對(duì)象時(shí)也根本不檢查這種異常。這是一種什么哲學(xué)呢？”他還提到：“一般C程序員總會(huì)判斷一下malloc失敗的情況，就連Linux內(nèi)核中都是如此。”
當(dāng)時(shí)，我首先想到的是：一般用C++實(shí)現(xiàn)的應(yīng)用層程序，內(nèi)存管理方面自不能與內(nèi)核程序相提并論。OS內(nèi)核需直接管理物理內(nèi)存，所有應(yīng)用程序的地址空間都由它映射而來(lái)，然后依靠它建立的機(jī)制進(jìn)行翻譯。內(nèi)核如果在內(nèi)存管理方面不保險(xiǎn)，應(yīng)用層還怎么過(guò)日子？另外，內(nèi)核中的內(nèi)存分配尚須考慮許多其它問(wèn)題，比如不同區(qū)域的不同特性（像某些DMA使用的buffer要物理連續(xù)且位于特定位置）。應(yīng)用層程序則不一樣，它們一般擁有flat的虛擬內(nèi)存空間，且數(shù)量上通常遠(yuǎn)大于物理內(nèi)存。因此，一個(gè)應(yīng)用程序如果能耗盡虛擬內(nèi)存，那要么是對(duì)數(shù)據(jù)的規(guī)模估計(jì)不足，要么就是一個(gè)必需專門解決的嚴(yán)重bug.耗盡虛擬內(nèi)存跟其它許多嚴(yán)重的bug（再如緩沖區(qū)溢出導(dǎo)致的堆棧破壞）一樣，即使能檢測(cè)到也常常無(wú)計(jì)可施，如果“有計(jì)可施”，那何不早施此計(jì)？何苦等它發(fā)生再亡羊補(bǔ)牢呢？反過(guò)來(lái)想，該失敗的時(shí)候痛痛快快的快速失敗，這不算壞事。至少，比帶著問(wèn)題繼續(xù)運(yùn)行半小時(shí)，然后在某個(gè)完全不相干的地方發(fā)生莫名其妙又難以重現(xiàn)的bug要好得多。
這是我當(dāng)時(shí)給朋友的回答，朋友勉強(qiáng)同意了，至少不再糾結(jié)C++程序員因何不在new的時(shí)候檢查std：：bad_alloc了。然而，順著這個(gè)問(wèn)題，我自己又聯(lián)想到好多東西。
（1）首先想到的是Java語(yǔ)言的做法。Java中的變量都是引用（基本類型的除外），而被引用的對(duì)象是用new在堆（heap）上創(chuàng)建的。在Java中new一個(gè)對(duì)象的時(shí)候，理論上也有可能引發(fā)java.lang.OutOfMemoryError.當(dāng)然，這是個(gè)Error，不是從java.lang.Exception派生的“異?！保虼苏Z(yǔ)言并沒(méi)強(qiáng)制我們catch它。然而，語(yǔ)言是否要求并不重要，語(yǔ)言為什么不要求才是重要的。顯然，如果問(wèn)題真的很嚴(yán)重，即使語(yǔ)言不要求，Java程序員也會(huì)在每一處new的周圍包上try/catch.可Java程序員沒(méi)有這么做。為什么？我想關(guān)鍵的原因跟上面是一樣的：一個(gè)應(yīng)用程序耗盡虛擬內(nèi)存，要么是對(duì)數(shù)據(jù)的規(guī)模估計(jì)不足（是否應(yīng)通過(guò)java命令的-Xm系列參數(shù)設(shè)置更大的heap呢？），要么就是一個(gè)必須專門解決的bug.同時(shí)，相對(duì)C++來(lái)說(shuō)，Java程序中采用這一決策還有更充分的理由：因?yàn)橛蠫C機(jī)制，Java程序中不太會(huì)有因?yàn)榇中脑斐傻膬?nèi)存泄露（頂多有因不良設(shè)計(jì)造成的內(nèi)存?zhèn)涡孤叮?BR> （2）C++中的“new”還不只是分配內(nèi)存那么簡(jiǎn)單。對(duì)于用戶自定義的類型來(lái)說(shuō)，“new T；”相當(dāng)于operator new再加上對(duì)T的構(gòu)造函數(shù)的調(diào)用。由于類的構(gòu)造函數(shù)完全可能引發(fā)異常，于是，就算內(nèi)存分配一切順利，一條new語(yǔ)句還是可能產(chǎn)生異常?？磥?lái)，需要catch的不止std：：bad_alloc.
（3）暫不考慮“哲學(xué)”因素，如果有人仍然覺(jué)得應(yīng)該像C程序那樣嚴(yán)格檢查內(nèi)存分配，可不可以呢？當(dāng)然可以，畢竟它還能拋出異常么，它能拋出我們就能捕捉。于是人們自然會(huì)想：C++或Java程序員用駝鳥策略對(duì)付內(nèi)存分配的失敗，異常在使用上比較麻煩會(huì)不會(huì)是原因之一呢？表面看是顯然的：每分配內(nèi)存都要包上一層try/catch，跟C中的針對(duì)返回值的if/else風(fēng)格比起來(lái)凌亂多了。
實(shí)際上，那不是使用異常的正確方法。如果異常只是if/else的簡(jiǎn)單語(yǔ)法替代物，那它根本就沒(méi)有存在的必要。異常的好處之一（真的只是“之一”）是：一個(gè)異常只需一個(gè)地方處理就足夠了。比如下面這樣：view plain void f1（） { try { // ……
f2（）；} catch （const some_exception& e） { // ……
}
void f2（） { // ……
f3（）；}
void f3（） { // ……
f4（）；}
void f4（） { // ……
throw some_exception（）；} f4惹禍，f1收?qǐng)觯虚gf2和f3只是一臉無(wú)辜地把異?！巴高^(guò)去”了（在Java中尚需聲明一下）--原因很可能是它們不具備足夠的上下文來(lái)處理這個(gè)異常。于是，我們不用像使用返回值那樣，從發(fā)生問(wèn)題的地方開始，到處理問(wèn)題的地方“之下”，中間每一層都要判斷一下，從而寫下一層層諸如：view plain x = f（）；if（x 《 0）
return x；之類的語(yǔ)句。這也有利于邏輯分層。
值得一提的是，在異?；貪L的過(guò)程中，棧上已經(jīng)構(gòu)造好的對(duì)象都會(huì)正常析構(gòu)。當(dāng)然，這要求程序員在設(shè)計(jì)類的時(shí)候要考慮“異常安全”的因素。
關(guān)于異常處理的思想和異常的使用，完全可以講一本書。更有興趣的朋友可以去找些相關(guān)書籍看看。
（4）事實(shí)上，C++中并非只有拋出異常的new，也有不拋異常的new，即通常所說(shuō)的“nothrow new”?？梢赃@樣使用它：view plain #include 《new》 // ……
T* p = new （std：：nothrow） T（/* …… */）；其中，nothrow是頭文件《new》中定義的一個(gè)類型為std：：nothrow_t的常量，我們可以直接使用它。這時(shí)，如果內(nèi)存分配失敗，p的值將為空（0），且不會(huì)有異常拋出，跟C的malloc很像了。
nothrow new實(shí)際是標(biāo)準(zhǔn)庫(kù)中實(shí)現(xiàn)的operator new和operator new［］的重載。我們也可以根據(jù)需要自己重載operator new/operator new［］，可以有全局的，也可以針對(duì)某個(gè)類重載。但實(shí)踐中用的不多。
注意，使用nothrow new創(chuàng)建對(duì)象時(shí)，只能保證不會(huì)因?yàn)閛perator new或operator new［］的失敗而拋出std：：bad_alloc，但難保對(duì)象的構(gòu)造函數(shù)不會(huì)拋出其它異常，甚至就拋出std：：bad_alloc.
（5）說(shuō)到C++的內(nèi)存分配，還有必要提一下set_new_handler.它允許你設(shè)置一個(gè)可以在operator new和operator new［］分配內(nèi)存失敗時(shí)可以回調(diào)的函數(shù)。如果你覺(jué)得還有什么辦法能釋放一些內(nèi)存的話，這個(gè)回調(diào)函數(shù)就是后的救命稻草了。
（6）話說(shuō)回來(lái)，多線程程序中，尤其是所謂的worker thread中，在線程函數(shù)退出之前使用“catch（……）”捕捉一下所有異常（不止std：：bad_alloc）也不是完全沒(méi)用。別指望能恢復(fù)什么，只求不要因?yàn)橐粋€(gè)線程而掛掉整個(gè)程序，同時(shí)盡量保證一下數(shù)據(jù)一致性就好。另外，也別指望catch（……）能捕獲一切“問(wèn)題”或“bug”，沒(méi)有那么好的事情。它只能捕獲C++的異常，其它的問(wèn)題，比如前面提到的堆棧破壞，再比如野指針訪問(wèn)，哪有那么容易檢測(cè)得到。
通常一個(gè)線程crash會(huì)導(dǎo)致整個(gè)進(jìn)程crash，有人因?yàn)檫@個(gè)原因而更傾向于使用多進(jìn)程，尤其是在類Unix的環(huán)境中。我個(gè)人對(duì)此雖不反對(duì)也不是特別贊同，因?yàn)榍穫偸且€的，這也包括“技術(shù)債務(wù)”：有bug遲早還是要解決。不過(guò)，使用多進(jìn)程還有別的好處，因?yàn)檫M(jìn)程間共享數(shù)據(jù)比同一個(gè)進(jìn)程的線程之間要麻煩得多，這會(huì)“迫使”開發(fā)者做出減少共享，從而既能減少并發(fā)問(wèn)題又能提高并發(fā)效率的設(shè)計(jì)。
（7）后，我的另一個(gè)好朋友兼同事認(rèn)為：程序crash沒(méi)有那么可怕。它可能是多數(shù)客戶難以忍受的bug，但那只是源于社會(huì)心理，不見得是真正嚴(yán)重的bug.
沒(méi)錯(cuò)，是“漫談”，而且“漫”得有點(diǎn)亂。然而，拋磚尚可引玉，想到的事情，縱然脈絡(luò)不那么順，寫下來(lái)也不是壞事。開卷有益，動(dòng)筆也有益。
一切緣自一位C語(yǔ)言開發(fā)經(jīng)驗(yàn)豐富的的朋友問(wèn)我的一個(gè)問(wèn)題。朋友問(wèn)：“C++中的new在分配內(nèi)存失敗時(shí)會(huì)拋出異常（std：：bad_alloc）而不返回0（一些老的編譯器可能還在返回0，但這樣的編譯器實(shí)在”太老了“），這跟C程序員的做法很不一樣。而且，許多C++程序在使用new創(chuàng)建對(duì)象時(shí)也根本不檢查這種異常。這是一種什么哲學(xué)呢？”他還提到：“一般C程序員總會(huì)判斷一下malloc失敗的情況，就連Linux內(nèi)核中都是如此。”
當(dāng)時(shí)，我首先想到的是：一般用C++實(shí)現(xiàn)的應(yīng)用層程序，內(nèi)存管理方面自不能與內(nèi)核程序相提并論。OS內(nèi)核需直接管理物理內(nèi)存，所有應(yīng)用程序的地址空間都由它映射而來(lái)，然后依靠它建立的機(jī)制進(jìn)行翻譯。內(nèi)核如果在內(nèi)存管理方面不保險(xiǎn)，應(yīng)用層還怎么過(guò)日子？另外，內(nèi)核中的內(nèi)存分配尚須考慮許多其它問(wèn)題，比如不同區(qū)域的不同特性（像某些DMA使用的buffer要物理連續(xù)且位于特定位置）。應(yīng)用層程序則不一樣，它們一般擁有flat的虛擬內(nèi)存空間，且數(shù)量上通常遠(yuǎn)大于物理內(nèi)存。因此，一個(gè)應(yīng)用程序如果能耗盡虛擬內(nèi)存，那要么是對(duì)數(shù)據(jù)的規(guī)模估計(jì)不足，要么就是一個(gè)必需專門解決的嚴(yán)重bug.耗盡虛擬內(nèi)存跟其它許多嚴(yán)重的bug（再如緩沖區(qū)溢出導(dǎo)致的堆棧破壞）一樣，即使能檢測(cè)到也常常無(wú)計(jì)可施，如果“有計(jì)可施”，那何不早施此計(jì)？何苦等它發(fā)生再亡羊補(bǔ)牢呢？反過(guò)來(lái)想，該失敗的時(shí)候痛痛快快的快速失敗，這不算壞事。至少，比帶著問(wèn)題繼續(xù)運(yùn)行半小時(shí)，然后在某個(gè)完全不相干的地方發(fā)生莫名其妙又難以重現(xiàn)的bug要好得多。
這是我當(dāng)時(shí)給朋友的回答，朋友勉強(qiáng)同意了，至少不再糾結(jié)C++程序員因何不在new的時(shí)候檢查std：：bad_alloc了。然而，順著這個(gè)問(wèn)題，我自己又聯(lián)想到好多東西。
（1）首先想到的是Java語(yǔ)言的做法。Java中的變量都是引用（基本類型的除外），而被引用的對(duì)象是用new在堆（heap）上創(chuàng)建的。在Java中new一個(gè)對(duì)象的時(shí)候，理論上也有可能引發(fā)java.lang.OutOfMemoryError.當(dāng)然，這是個(gè)Error，不是從java.lang.Exception派生的“異?！保虼苏Z(yǔ)言并沒(méi)強(qiáng)制我們catch它。然而，語(yǔ)言是否要求并不重要，語(yǔ)言為什么不要求才是重要的。顯然，如果問(wèn)題真的很嚴(yán)重，即使語(yǔ)言不要求，Java程序員也會(huì)在每一處new的周圍包上try/catch.可Java程序員沒(méi)有這么做。為什么？我想關(guān)鍵的原因跟上面是一樣的：一個(gè)應(yīng)用程序耗盡虛擬內(nèi)存，要么是對(duì)數(shù)據(jù)的規(guī)模估計(jì)不足（是否應(yīng)通過(guò)java命令的-Xm系列參數(shù)設(shè)置更大的heap呢？），要么就是一個(gè)必須專門解決的bug.同時(shí)，相對(duì)C++來(lái)說(shuō)，Java程序中采用這一決策還有更充分的理由：因?yàn)橛蠫C機(jī)制，Java程序中不太會(huì)有因?yàn)榇中脑斐傻膬?nèi)存泄露（頂多有因不良設(shè)計(jì)造成的內(nèi)存?zhèn)涡孤叮?BR> （2）C++中的“new”還不只是分配內(nèi)存那么簡(jiǎn)單。對(duì)于用戶自定義的類型來(lái)說(shuō)，“new T；”相當(dāng)于operator new再加上對(duì)T的構(gòu)造函數(shù)的調(diào)用。由于類的構(gòu)造函數(shù)完全可能引發(fā)異常，于是，就算內(nèi)存分配一切順利，一條new語(yǔ)句還是可能產(chǎn)生異常?？磥?lái)，需要catch的不止std：：bad_alloc.
（3）暫不考慮“哲學(xué)”因素，如果有人仍然覺(jué)得應(yīng)該像C程序那樣嚴(yán)格檢查內(nèi)存分配，可不可以呢？當(dāng)然可以，畢竟它還能拋出異常么，它能拋出我們就能捕捉。于是人們自然會(huì)想：C++或Java程序員用駝鳥策略對(duì)付內(nèi)存分配的失敗，異常在使用上比較麻煩會(huì)不會(huì)是原因之一呢？表面看是顯然的：每分配內(nèi)存都要包上一層try/catch，跟C中的針對(duì)返回值的if/else風(fēng)格比起來(lái)凌亂多了。
實(shí)際上，那不是使用異常的正確方法。如果異常只是if/else的簡(jiǎn)單語(yǔ)法替代物，那它根本就沒(méi)有存在的必要。異常的好處之一（真的只是“之一”）是：一個(gè)異常只需一個(gè)地方處理就足夠了。比如下面這樣：view plain void f1（） { try { // ……
f2（）；} catch （const some_exception& e） { // ……
}
void f2（） { // ……
f3（）；}
void f3（） { // ……
f4（）；}
void f4（） { // ……
throw some_exception（）；} f4惹禍，f1收?qǐng)觯虚gf2和f3只是一臉無(wú)辜地把異?！巴高^(guò)去”了（在Java中尚需聲明一下）--原因很可能是它們不具備足夠的上下文來(lái)處理這個(gè)異常。于是，我們不用像使用返回值那樣，從發(fā)生問(wèn)題的地方開始，到處理問(wèn)題的地方“之下”，中間每一層都要判斷一下，從而寫下一層層諸如：view plain x = f（）；if（x 《 0）
return x；之類的語(yǔ)句。這也有利于邏輯分層。
值得一提的是，在異?；貪L的過(guò)程中，棧上已經(jīng)構(gòu)造好的對(duì)象都會(huì)正常析構(gòu)。當(dāng)然，這要求程序員在設(shè)計(jì)類的時(shí)候要考慮“異常安全”的因素。
關(guān)于異常處理的思想和異常的使用，完全可以講一本書。更有興趣的朋友可以去找些相關(guān)書籍看看。
（4）事實(shí)上，C++中并非只有拋出異常的new，也有不拋異常的new，即通常所說(shuō)的“nothrow new”?？梢赃@樣使用它：view plain #include 《new》 // ……
T* p = new （std：：nothrow） T（/* …… */）；其中，nothrow是頭文件《new》中定義的一個(gè)類型為std：：nothrow_t的常量，我們可以直接使用它。這時(shí)，如果內(nèi)存分配失敗，p的值將為空（0），且不會(huì)有異常拋出，跟C的malloc很像了。
nothrow new實(shí)際是標(biāo)準(zhǔn)庫(kù)中實(shí)現(xiàn)的operator new和operator new［］的重載。我們也可以根據(jù)需要自己重載operator new/operator new［］，可以有全局的，也可以針對(duì)某個(gè)類重載。但實(shí)踐中用的不多。
注意，使用nothrow new創(chuàng)建對(duì)象時(shí)，只能保證不會(huì)因?yàn)閛perator new或operator new［］的失敗而拋出std：：bad_alloc，但難保對(duì)象的構(gòu)造函數(shù)不會(huì)拋出其它異常，甚至就拋出std：：bad_alloc.
（5）說(shuō)到C++的內(nèi)存分配，還有必要提一下set_new_handler.它允許你設(shè)置一個(gè)可以在operator new和operator new［］分配內(nèi)存失敗時(shí)可以回調(diào)的函數(shù)。如果你覺(jué)得還有什么辦法能釋放一些內(nèi)存的話，這個(gè)回調(diào)函數(shù)就是后的救命稻草了。
（6）話說(shuō)回來(lái)，多線程程序中，尤其是所謂的worker thread中，在線程函數(shù)退出之前使用“catch（……）”捕捉一下所有異常（不止std：：bad_alloc）也不是完全沒(méi)用。別指望能恢復(fù)什么，只求不要因?yàn)橐粋€(gè)線程而掛掉整個(gè)程序，同時(shí)盡量保證一下數(shù)據(jù)一致性就好。另外，也別指望catch（……）能捕獲一切“問(wèn)題”或“bug”，沒(méi)有那么好的事情。它只能捕獲C++的異常，其它的問(wèn)題，比如前面提到的堆棧破壞，再比如野指針訪問(wèn)，哪有那么容易檢測(cè)得到。
通常一個(gè)線程crash會(huì)導(dǎo)致整個(gè)進(jìn)程crash，有人因?yàn)檫@個(gè)原因而更傾向于使用多進(jìn)程，尤其是在類Unix的環(huán)境中。我個(gè)人對(duì)此雖不反對(duì)也不是特別贊同，因?yàn)榍穫偸且€的，這也包括“技術(shù)債務(wù)”：有bug遲早還是要解決。不過(guò)，使用多進(jìn)程還有別的好處，因?yàn)檫M(jìn)程間共享數(shù)據(jù)比同一個(gè)進(jìn)程的線程之間要麻煩得多，這會(huì)“迫使”開發(fā)者做出減少共享，從而既能減少并發(fā)問(wèn)題又能提高并發(fā)效率的設(shè)計(jì)。
（7）后，我的另一個(gè)好朋友兼同事認(rèn)為：程序crash沒(méi)有那么可怕。它可能是多數(shù)客戶難以忍受的bug，但那只是源于社會(huì)心理，不見得是真正嚴(yán)重的bug.