漫談C++記憶體配置失敗

沒錯，是“漫談”，而且“漫”得有點亂。然而，拋磚尚可引玉，想到的事情，縱然脈絡不是很暢，寫下來也不是壞事。開卷有益，動筆也有益。

 

一切緣自一位C語言開發經驗非常豐富的的朋友問我的一個問題。朋友問：“C++中的new在分配記憶體失敗時會拋出異常（std::bad_alloc）而不返回0（一些老的編譯器可能還在返回0，但這樣的編譯器實在“太老了”），這跟C程式員的做法很不一樣。而且，許多C++程式在使用new建立對象時也根本不檢查這種異常。這是一種什麼哲學呢？”他還提到：“一般C程式員總會判斷一下malloc失敗的情況，就連Linux核心中都是如此。”

 

對於他的疑惑，我首先想到的是：一般用C++實現的應用程式層程式，記憶體管理方面自不能與核心程式相提並論。OS核心直接管理實體記憶體，所有應用程式的地址空間均由它映射而來，然後靠它建立機制進行翻譯。核心如果在記憶體管理方面不保險，應用程式層還怎麼過日子？核心中的記憶體配置還須考慮許多其它問題，比如不同地區的不同特性（像某些DMA使用的buffer要物理連續且位於特定位置）。同樣重要的：對一個成熟的OS核心來說，即使在應用程式出現嚴重問題的時候也不能泄露實體記憶體及其它資源，且不能影響其它程式。

應用程式層程式則不同，它們一般擁有彼此獨立的、flat的虛擬記憶體空間，數量上通常遠大於實體記憶體。因此，一個應用程式如果能耗盡虛擬記憶體，那要麼是對資料的規模估計不足，要麼就是一個必需專門解決的嚴重bug。
耗盡虛擬記憶體跟其它許多嚴重的bug（再比如緩衝區溢位導致的堆棧破壞）一樣，多數情況下即使能檢測到也常常無計可施，如果“有計可施”，那何不早施此計？何苦等它發生再亡羊補牢呢？反過來想，該失敗的時候痛痛快快的快速失敗，這不算壞事。至少，比帶著問題繼續運行半小時，然後在某個完全不相干的地方發生莫名其妙又難以重現的bug要好得多。
這是我當時給朋友的回答，朋友勉強同意了，至少不再糾結C++程式員因何不在new的時候檢查std::bad_alloc了。然而，順著這個問題，我覺得可以聯想到好多相關的話題。

 

（1）首先想到的是Java語言的做法。Java中的變數都是引用（基本類型的除外），而被引用的對象是用new在堆（heap）上建立的。在Java中new一個對象時，理論上也有可能引發java.lang.OutOfMemoryError。當然，這是個Error，不是從java.lang.Exception派生的“異常”，因此語言並沒強制我們catch它。然而，語言是否要求並不重要，語言為什麼不要求才是重要的。顯然，如果問題足夠嚴重，即使語言不要求，Java程式員也會在每一處new的周圍包上try/catch。可Java程式員沒有這麼做。為什嗎？我想關鍵的原因跟上面是一樣的：一個應用程式耗盡虛擬記憶體，要麼是對資料的規模估計不足（是否應通過java命令的-Xm系列參數設定更大的heap呢？），要麼就是一個必須專門解決的bug。
同時，相對C++來說，Java程式中採用這一決策還有更充分的理由：因為有GC機制，Java程式中因為粗心造成的記憶體泄露較少（可能會有因不良設計造成的記憶體偽泄露）。

 

（2）C++中的“new”還不只是分配記憶體那麼簡單。對於使用者自訂的類型來說，“new T;”相當於operator new再加上對T的建構函式的調用。由於類的建構函式完全可能引發異常，於是，就算記憶體配置一切順利，一條new語句還是可能產生異常。看來，需要catch的不止std::bad_alloc。

 

（3）暫不考慮“哲學”因素，如果有人仍然覺得應該像C程式那樣嚴格檢查記憶體配置，可不可以呢？當然可以，畢竟它還能拋出異常麼，它能拋出我們就能捕捉。於是人們自然會想：C++或Java程式員用駝鳥策略對付記憶體配置的失敗，異常在使用上比較麻煩的事實會不會是原因之一呢？表面看是顯然的：每分配一次記憶體都要包上一層try/catch，跟C中的針對傳回值的if/else風格比起來淩亂多了。
實際上，那不是使用異常的正確方法。如果異常只是if/else的簡單文法替代物，那它根本就沒有存在的必要。異常的好處之一（真的只是“之一”）是：一個異常只需一個地方處理就足夠了。比如下面這樣：

void f1() {try {// ...f2();} catch (const some_exception& e) {// ...}}void f2() {// ...f3();}void f3() {// ...f4();}void f4() {// ...throw some_exception();}

f4惹禍，f1收場，中間f2和f3隻是一臉無辜地把異常“透過去”了（在Java中可能要聲明一下）——原因很可能是它們不具備足夠的上下文來處理這個異常。於是，我們不用像使用傳回值那樣，從發生問題的地方開始，到處理問題的地方“之下”，中間每一層都要判斷一下，從而寫下一層又一層的諸如：

x = f();if(x < 0)return x;

之類的語句。你不覺得這樣可以使大多數函數更加乾淨嗎？在異常或錯誤處理的問題上，這也使得不同邏輯層次的責任更加清晰。
值得一提的是，在異常復原的過程中，棧上已經構造好的對象都會正常析構。當然，這要求程式員在設計類的時候要考慮“異常安全”的因素。
關於異常處理的思想和異常的使用，完全可以講一本書。更有興趣的朋友不妨看看Herb Sutter寫的“Exceptional三卷本”：《Exceptional C++》、《More Exceptinal C++》和《Exceptional C++ Style》。

 

（4）事實上，C++中並非只有拋出異常的new，也有不拋異常的new，即通常所說的“nothrow new”。可以這樣使用它：

#include <new>// ...T* p = new (std::nothrow) T(/* ... */);

其中，nothrow是標頭檔<new>中定義的一個類型為std::nothrow_t的常量，我們可以直接使用它。這時，如果記憶體配置失敗，p的值將為空白（0），且不會有異常拋出，跟C的malloc很像了。
nothrow new實際是標準庫中實現的operator new和operator new[]的重載。我們也可以根據自己的需要重載operator new/operator new[]，可以有全域的，也可以針對某個類重載。但實踐中用的不多。
注意，使用nothrow new建立對象時，只能保證不會因為operator new或operator new[]的失敗而拋出std::bad_alloc，但難保對象的建構函式不會拋出其它異常，甚至就拋出std::bad_alloc。

 

（5）說到C++的記憶體配置，還有必要提一下set_new_handler。它允許你設定一個在operator new和operator new[]分配記憶體失敗時可以回調的函數。如果你覺得在std::bad_alloc發生時還有什麼辦法能改善一下記憶體使用量的情況，這個回呼函數也算得一根救命稻草，詳細的用法和說明可以看這裡：http://new.cplusplus.com/reference/std/new/set_new_handler/

 

（6）雖然當std::bad_alloc發生時我們常常已無計可施，但並非所有的異常都如此，有些異常是可以處理從而挽回損失的。因此，在主函數最後，或者在多線程程式，尤其是所謂的worker thread的線程函數退出之前，用“catch(...)”捕捉一下所有異常還是有好處的。即使不指望恢複什麼，至少不要因為一個線程而掛掉整個程式，同時盡量確保資料的完整性。

但別指望catch(...)能捕獲一切“問題”或“bug”，沒有那麼好的事情。它只能捕獲C++的異常，其它的問題，比如前面提到的堆棧破壞，再比如野指標訪問，哪有那麼容易檢測得到。（話說我最近被野指標搞得煩死了，不是我寫的。）

通常一個線程crash會導致整個進程crash，有人因為這個原因而更傾向於使用多進程，尤其是在類Unix的環境中。我個人對此雖不反對也不是特別贊同，因為欠債總是要還的，這也包括“技術債務”：有bug遲早還是要找到根源並真正解決，哪怕“真正繞開”也行。

不過，使用多進程還有別的好處，因為進程間共用資料比同一個進程的線程之間要麻煩得多，這會迫使開發人員做出減少共用，從而既能減少並發問題又能提高並發效率的設計。步入多核時代之後，讓並發實體儘可能地獨立，從而充分發揮硬體的並行效能，比什麼都重要。

 

（7）我的另一個好朋友兼同事（新浪微博 @不許說話）認為：程式crash沒有那麼可怕。它可能是多數客戶最難以忍受的bug，但那隻是源於社會心理，不見得是真正最嚴重的bug。