漫談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。