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