1. 一個進程中可以同時包含多個線程。
   　
2. 我們通常認為線程是操作系統可識別的最小並發執行和調度單位（不要跟俺說還有 Green Thread 或者 Fiber，OS Kernel 不認識也不參與這些物件的調度）。
   
   　
3. 同一進程中的多個線程共享代碼段（代碼和常量）、數據段（靜態和全局變量）和擴展段（堆存儲），但是每個線程有自己的棧段。棧段又叫運行時棧，用來存放所有局部變量和臨時變量（參數、返回值、臨時構造的變量等）。這一條對下文中的某些概念來說是非常重要的 。但是請註意，這裏提到的各個“段”都是邏輯上的說法，在物理上某些硬件架構或者操作系統可能不使用段式存儲。不過沒關系，編譯器會保證這些邏輯概念和假設的前提條件對每個 C/C++ 程序員來說始終是成立的。
   　
4. 由於共享了除棧以外的所有內存地址段，線程不可以有自己的“靜態”或“全局”變量，為了彌補這一缺憾，操作系統通常會提供一種稱為 TLS
   （Thread Local Storage，即：“線程本地存儲”）的機制。通過該機制可以實現類似的功能。TLS 通常是線程控制塊（TCB）中的某個指針所指向的一個指針數組，數組中的每個元素稱為一個槽（Slot），每個槽中的指針由使用者定義，可以指向任意位置（但通常是指向堆存儲中的某個偏移）。

1. 傳遞參數：通常，函數的調用參數總是在這個函數棧框架的最頂端。
2. 傳遞返回地址：告訴被調用者的 return 語句應該 return 到哪裏去，通常指向該函數調用的下一條語句（代碼段中的偏移）。
3. 存放調用者的當前棧指針：便於清理被調用者的所有局部變量、並恢復調用者的現場。
4. 存放當前函數內的所有局部變量：記得嗎？剛才說過所有局部和臨時變量都是存儲在棧上的。

最後再復習一點：棧是一種“後進先出”（LIFO）的數據結構，不過實際上大部分棧的實現都支持隨機訪問。

下面我們來看個具體例子：

假設有 FuncA、FuncB 和 FuncC 三個函數，每個函數均接收兩個整形值作為其參數。在某線程上的某一時間段內，FuncA 調用了 FuncB，而 FuncB 又調用了 FuncC。則，它們的棧框架看起來應該像這樣：

圖1 函數調用棧框架示例

正如上圖所示的那樣，隨著函數被逐級調用，編譯器會為每一個函數建立自己的棧框架，棧空間逐漸消耗。隨著函數的逐級返回，該函數的棧框架也將被逐級銷毀，棧空間得以逐步釋放。順便說一句，遞歸函數的嵌套調用深度通常也是取決於運行時棧空間的剩余尺寸。

這裏順便解釋另一個術語：調用約定（calling convention）。調用約定通常指：調用者將參數壓入棧中（或放入寄存器中）的順序，以及返回時由誰（調用者還是被調用者）來清理這些參數等細節規程方面的約定。

最後再說一句，這裏所展示的函數調用乃是最“經典”的方式。實際情況是：在開啟了優化選項後，編譯器可能不會為一個內聯甚至非內聯的函數生成棧框架，編譯器可能使用很多優化技術消除這個構造。不過對於一個 C/C++ 程序員來說，達到這樣的理解程度通常就足夠了。

1. 該函數可能會直接或間接地拋出一個異常：即該函數的定義存放在一個 C++ 編譯（而不是傳統 C）單元內，並且該函數沒有使用“throw()”異常過濾器。
2. 或者該函數的定義內使用了 try 塊。

以上兩者滿足其一即可。為了能夠成功地捕獲異常和正確地完成棧回退（stack unwind），編譯器必須要引入一些額外的數據結構和相應的處理機制。我們首先來看看引入了異常處理機制的棧框架大概是什麽樣子：

圖2 C++函數調用棧框架示例

由圖2可見，在每個 C++ 函數的棧框架中都多了一些東西。仔細觀察的話，你會發現，多出來的東西正好是一個 EXP 類型的結構體。進一步分析就會發現，這是一個典型的單向鏈表式結構：

• piPrev 成員指向鏈表的上一個節點，它主要用於在函數調用棧中逐級向上尋找匹配的 catch 塊，並完成棧回退工作。

• piHandler 成員指向完成異常捕獲和棧回退所必須的數據結構（主要是兩張記載著關鍵數據的表：“try”塊表：tblTryBlocks 及“棧回退表”：tblUnwind）。

• nStep 成員用來定位 try 塊，以及在棧回退表中尋找正確的入口。

需要說明的是：編譯器會為每一個“C++ 函數”定義一個 EHDL 結構，不過只會為包含了“try”塊的函數定義 tblTryBlocks 成員。此外，異常處理器還會為每個線程維護一個指向當前異常處理框架的指針。該指針指向異常處理器鏈表的鏈尾，通常存放在某個 TLS 槽或能起到類似作用的地方。

最後，請再看一遍圖2，並至少對其中的數據結構留下一個大體印象。我們會在後面多個小節中詳細討論它們。

註意：為了簡化起見，本文中描述的數據結構內，大多省略了一些與話題無關的成員。

受益於棧回退機制的引入，以及 C++ 類所支持的“資源申請即初始化”語意，使得我們終於能夠徹底告別既不優雅也不安全的 setjmp/longjmp 調用，簡便又安全地實現遠程跳轉了。我想這也是 C++ 異常處理機制在錯誤處理以外唯一一種合理的應用方式了。

下面我們就來具體看看編譯器是如何實現棧回退機制的：

圖3 C++ 棧回退機制

圖3中的“FuncUnWind”函數內，所有真實代碼均以黑色和藍色字體標示，編譯器生成的代碼則由灰色和橙色字體標明。此時，在圖2裏給出的 nStep 變量和 tblUnwind 成員作用就十分明顯了。

nStep 變量用於跟蹤函數內局部對象的構造、析構階段。再配合編譯器為每個函數生成的 tblUnwind 表，就可以完成退棧機制。表中的 pfnDestroyer 字段記錄了對應階段應當執行的析構操作（析構函數指針）；pObj 字段則記錄了與之相對應的對象 this 指針偏移。將 pObj 所指的偏移值加上當前棧框架基址（EBP），就是要代入 pfnDestroyer 所指析構函數的 this 指針，這樣即可完成對該對象的析構工作。而 nNextIdx 字段則指向下一個需要析構對象所在的行（下標）。

在發生異常時，異常處理器首先檢查當前函數棧框架內的 nStep 值，並通過 piHandler 取得 tblUnwind[] 表。然後將 nStep 作為下標帶入表中，執行該行定義的析構操作，然後轉向由 nNextIdx 指向的下一行，直到 nNextIdx 為 -1 為止。在當前函數的棧回退工作結束後，異常處理器可沿當前函數棧框架內 piPrev 的值回溯到異常處理鏈中的上一節點重復上述操作，直到所有回退工作完成為止。

值得一提的是，nStep 的值完全在編譯時決定，運行時僅需執行若幹次簡單的整形立即數賦值（通常是直接賦值給CPU裏的某個寄存器）。此外，對於所有內部類型以及使用了默認構造、析構方法（並且它的所有成員和基類也使用了默認方法）的類型，其創建和銷毀均不影響 nStep 的值。

註意：如果在棧回退的過程中，由於析構函數的調用而再次引發了異常（異常中的異常），則被認為是一次異常處理機制的嚴重失敗。此時進程將被強行禁止。為防止出現這種情況，應在所有可能拋出異常的析構函數中使用“std::uncaught_exception()”方法判斷當前是否正在進行棧回退（即：存在一個未捕獲或未完全處理完畢的異常）。如是，則應抑制異常的再次拋出。

圖4 C++ 異常捕獲機制

在上一小節中，我們已經看到了 nStep 變量在跟蹤對象構造、析構方面的作用。實際上 nStep 除了能夠跟蹤對象創建、銷毀階段以外，還能夠標識當前執行點是否在 try 塊中，以及（如果當前函數有多個 try 塊的話）究竟在哪個 try 塊中。這是通過在每一個 try 塊的入口和出口各為 nStep 賦予一個唯一 ID 值，並確保 nStep 在對應 try 塊內的變化恰在此範圍之內來實現的。

在具體實現異常捕獲時，首先，C++ 異常處理器檢查發生異常的位置是否在當前函數的某個 try 塊之內。這項工作可以通過將當前函數的 nStep 值依次在 piHandler 指向 tblTryBlocks[] 表的條目中進行範圍為 [nBeginStep, nEndStep) 的比對來完成。

例如：若圖4 中的 FuncB 在 nStep == 2 時發生了異常，則通過比對 FuncB 的 tblTryBlocks[] 表發現 2∈[1, 3)，故該異常發生在 FuncB 內的第一個 try 塊中。

其次，如果異常發生的位置在當前函數中的某個 try 塊內，則嘗試匹配該 tblTryBlocks[] 相應條目中的 tblCatchBlocks[] 表。tblCatchBlocks[] 表中記錄了與指定 try 塊配套出現的所有 catch 塊相關信息，包括這個 catch 塊所能捕獲的異常類型及其起始地址等信息。

若找到了一個匹配的 catch 塊，則復制當前異常對象到此 catch 塊，然後跳轉到其入口地址執行塊內代碼。

否則，則說明異常發生位置不在當前函數的 try 塊內，或者這個 try 塊中沒有與當前異常相匹配的 catch 塊，此時則沿著函數棧框架中 piPrev 所指地址（即：異常處理鏈中的上一個節點）逐級重復以上過程，直至找到一個匹配的 catch 塊或到達異常處理鏈的首節點。對於後者，我們稱為發生了未捕獲的異常，對於 C++ 異常處理器而言，未捕獲的異常是一個嚴重錯誤，將導致當前進程被強制結束。

註意：雖然在圖4示例中的 tblTryBlocks[] 只有一個條目，這個條目中的 tblCatchBlocks[] 也只有一行。但是在實際情況中，這兩個表中都允許有多條記錄。意即：一個函數中可以有多個 try 塊，每個 try 塊後均可跟隨多個與之配套的 catch 塊。

註意：按照標準意義上的理解，異常時的棧回退是伴隨著異常捕獲過程沿著異常處理鏈逐層向上進行的。但是有些編譯器是在先完成異常捕獲後再一次性進行棧回退的。無論具體實現使用了哪種方式，除非正在開發一個內存嚴格受限的嵌入式應用，通常我們按照標準語意來理解都不會產生什麽問題。

備註：實際上 tblCatchBlocks 中還有一些較為關鍵但被故意省略的字段。比如指明該 catch 塊異常對象復制方式（傳值（拷貝構造）或傳址（引用或指針））的字段，以及在何處存放被復制的異常對象（相對於入口地址的偏移位置）等信息。

圖5 C++ 異常拋出

在編譯一段 C++ 代碼時，編譯器會將所有 throw 語句替換為其 C++ 運行時庫中的某一指定函數，這裏我們叫它 __CxxRTThrowExp（與本文提到的所有其它數據結構和屬性名一樣，在實際應用中它可以是任意名稱）。該函數接收一個編譯器認可的內部結構（我們叫它 EXCEPTION 結構）。這個結構中包含了待拋出異常對象的起始地址、用於銷毀它的析構函數，以及它的 type_info 信息。對於沒有啟用 RTTI 機制（編譯器禁用了 RTTI 機制或沒有在類層次結構中使用虛表）的異常類層次結構，可能還要包含其所有基類的 type_info 信息，以便與相應的 catch 塊進行匹配。

在圖5中的深灰色框圖內，我們使用 C++ 偽代碼展示了函數 FuncA 中的 “throw myExp(1);” 語句將被編譯器最終翻譯成的樣子。實際上在多數情況下，__CxxRTThrowExp 函數即我們前面曾多次提到的“異常處理器”，異常捕獲和棧回退等各項重要工作都由它來完成。

__CxxRTThrowExp 首先接收（並保存）EXCEPTION 對象；然後從 TLS：Current ExpHdl 處找到與當前函數對應的 piHandler、nStep 等異常處理相關數據；並按照前文所述的機制完成異常捕獲和棧回退。由此完成了包括“拋出”->“捕獲”->“回退”等步驟的整套異常處理機制。

• 由於可直接借助操作系統提供的機制，所以簡化了 C++ 異常處理器的實現。
• 使“catch (...)” 塊得以捕獲操作系統產生的異常（如：“內存訪問違例”等等）。
• 使操作系統的異常處理機制能夠捕獲所有 C++ 異常。

實際上，大多數 Windows 下的 C++ 編譯器的異常機制均使用這種方式實現。

可以看出，在沒有拋出異常時，C++ 的異常處理機制是十分有效的。在有異常被拋出後，可能會依當前函數調用棧的情形進行若幹次整形比較（try塊表匹配）操作，但這通常不會超過幾十次。對於大多數 15 年前的 CPU 來說，整形比較也只需 1 時鐘周期，所以異常捕獲的效率還是很高的。棧回退的效率則與 return 語句基本相當。

考慮到即使是傳統的函數調用、錯誤處理和逐級返回機制也不是沒有代價的。這些開銷在絕大多數情形下仍可以接受。空間開銷方面，每“C++ 函數”一個 EHDL 結構體的引入在某些極端情形下會明顯增加目標文件尺寸和內存開銷。但是典型情況下，它們的影響並不大，但也沒有小到可以完全忽略的程度。如果正在為一個資源嚴格受限的環境開發應用程序，你可能需要考慮關閉異常處理和 RTTI 機制以節約存儲空間。

以上討論的是一種典型的異常機制的實現方式，各具體編譯器廠商可能有自己的優化和改進方案，但總體的出入不會很大。

此外，由於長跳轉的使用既易於出錯，又難於理解和維護。在編碼過程中也應當盡量避免使用。關於異常的一般性使用說明，請參考：代碼風格與版式：異常。