計算機系統中有很多程序員習以為常但又十分神秘的存在：函數調用、系統調用、進程切換、線程切換以及中斷處理。

函數調用能讓程序員提高代碼可復用性，系統調用能讓程序員向操作系統發起請求，進程線程切換讓多任務成為可能，中斷處理能讓操作系統管理外部設備。

這些機制是計算機系統中的基石，可是你知道這些機制是如何實現的嗎？

這篇文章將告訴你答案，其背后的實現如此優雅且一致。

速度與激。。寄存器

你有沒有想過，CPU為什么需要寄存器？原因很簡單：速度。

通常CPU可以在一個時鐘周期內訪問一次寄存器，CPU訪問內存的速度大概要比訪問寄存器慢100倍左右。因此如果CPU沒有寄存器而完全依賴內存的話，那么計算速度將比現在慢的多。作為程序員來說，當我們使用高級語言編寫的程序時，其操作的數據都存放在內存中，而對于負責運算類的機器指令來說其操作的數據都存放在寄存器中。實際上寄存器和內存沒有什么本質的區別，都是用來存儲信息的。當然，除了臨時保存中間計算結果之外，還有很多有趣的寄存器。根據用途，寄存器有很多類型，但是，我們感興趣的有以下幾種寄存器。

棧寄存器：Stack Pointer函數在運行時都有一個運行時棧，對于棧來說最重要的信息就是棧頂，棧頂信息就保存在棧寄存器中，stack pointer，通過該寄存器就能跟蹤函數的調用棧。

最為程序員我們知道，函數在運行時會有一塊獨立的內存空間，用來保存函數內定義的局部變量、傳遞的參數以及返回值信息等，這塊獨立的內存空間就叫棧幀，隨著函數調用層次的加深，棧幀也隨之增加；當函數調用完成后棧幀由按照相反的順序依次減少，這些棧幀就構成了棧區。

函數的運行時棧信息是關于程序運行狀態最重要的信息之一。那么其它的之一呢？

指令地址寄存器：Program Counter這類寄存器的名稱比較多，基于歷史原因，大部分將其稱為Program Counter，PC，即我們熟悉的程序計數器；在x86下則被稱為Instruction Pointer，IP，怎么稱呼不重要，重要的是理解其作用。在本文中統一將其稱為PC寄存器。我們都知道，程序員用高級語言編寫的程序最終通過編譯器生成最終的機器指令，那么一個問題就是在茫茫的機器指令海洋中，CPU怎么知道該去執行哪條機器指令呢？

原來，奧秘就藏在指令地址寄存器中。程序在啟動時會把機器指令的首地址寫入到PC寄存器中，這樣CPU需要做的就是根據PC寄存器中的地址去內存中取出指令。通常來說，指令都是順序執行的，也就是說PC寄存器中的值不斷的+1，但對于一些涉及控制轉移的機器指令來說，這些指令會把一個新的指令地址放到PC寄存器中，這包括分支跳轉——也就是if語句、函數調用以及返回等。控制了CPU的PC寄存器就掌握了CPU的航向，機器指令自己會根據執行狀態指揮CPU接下來該去執行哪些指令，這才是真正的自動駕駛，非常amazing有沒有！

指令地址寄存器是關于程序運行時狀態另一個最重要的信息之一。

狀態寄存器：Status RegisterCPU內部除了上述兩類寄存器外，還有一類狀態寄存器，Status Register；在x86架構下被稱為FLAGS register，ARM架構下被稱為application program status register，以下統稱狀態寄存器。從名字也能看出來，該寄存器是保存狀態信息的，有什么有趣的狀態信息呢？比如對于涉及到算術運算的指令來說，其在執行過程中可能會產生進位，也可能會溢出，那么這些信息就保存在狀態寄存器中。除此之外，你肯定聽說過程序的執行一般有兩種模式：內核態和用戶態。對于大部分的程序員其編寫的應用程序運行在用戶態，在用戶態下不能執行特權指令，比如你沒辦法寫一個程序直接去控制系統中的各種硬件資源。而在內核態下，CPU可以執行任意的特權指令，內核就工作在內核態，因此內核可以掌控一切。關于用戶態內核態完整的闡述參見博主深入理解操作系統第2章，關注公眾號碼農的荒島求生并回復操作系統即可。

那么我們怎么知道當前程序運行在哪種狀態呢？答案就在CPU內部的狀態寄存器中，該寄存器中有特定的比特位來標記當前CPU正工作在哪種模式下。現在你應該知道寄存器的重要作用了吧。

上下文：Context通過這些寄存器，你可以知道程序運行到當前這一刻時最細粒度的切面，這一時刻這些寄存器中保存的所有信息就是我們通常所說的上下文，context。上下文的作用是什么呢？只要你能拿到一個程序運行時的上下文并保存起來，那么你可以隨時暫停該程序的運行，也可以隨時利用該信息恢復該程序的運行。為什么要保存和恢復上下文信息呢？原因就在于CPU的個數是有限的，這就意味一個CPU可能會執行多個進程，即這些進程要共享該CPU資源，更具體的是CPU的計算資源和這里所說的各種寄存器。這是實現函數調用、系統調用、進程切換、線程切換以及中斷處理的基本機制。

而程序在運行過程中逃不出函數調用、系統調用、進程切換、線程切換以及中斷處理這幾項操作，由此可見上下文信息的保存和恢復在計算機科學中重要的作用。那么上下文信息又該如何保存呢？保存到哪里呢？又該怎么恢復呢？函數調用、系統調用、進程切換、線程切換以及中斷處理又是怎樣實現的呢？

游戲與棧經常玩游戲的同學應該都知道，游戲里有主線，有時在主線任務中還要去完成一些支線任務，也就是說任務A依賴任務B，任務B依賴任務C，那么任務的依賴關系是這樣的：

A -》 B -》 C

那么很顯然只有完成任務C你才能繼續任務B，完成任務B才能繼續任務A，因此任務完成順序是這樣的：

C-》 B -》 A

我們可以看到任務完成順序和任務依賴順序是相反的：先來的反而后完成。這天然適合棧來表示。

這里特別值得注意的是，棧是一種機制，和其本身是怎么實現的沒有關系，你可以用軟件來實現棧，也可以用硬件來實現棧。棧是一種如此簡單的結構，卻又如此強大。棧是實現計算機系統的一種極為重要的基礎機制，接下來的講解就能讓你意識到棧的重要作用。

函數調用與運行時棧函數是編程語言中最重要的概念之一，函數讓代碼復用成為可能，你知道函數調用是如何實現的嗎？函數調用的難點在于CPU不能在平鋪直敘的往前依次順序的執行機器指令，而是要跳轉到被調函數的第一條機器指令，執行完該函數后還要跳轉回來。當你從A函數跳轉到B函數時，A函數被暫停運行，當被調函數執行完后A函數繼續運行。因此這里就涉及到A函數的狀態保存與狀態恢復。函數的運行時狀態有什么呢？主要有返回地址以及使用的寄存器信息，這就是在本文開頭講解的寄存器，我們將其稱為函數運行時上下文，簡稱為context。這些context保存在哪里呢？我想你已經猜到了，沒錯，就是棧中，我們為每個函數分配一塊空間，當A函數調用B函數時，我們在這塊空間中保存該函數的context，當B函數執行結束后，我們再用該context恢復A函數的運行。如果是A函數調用B函數，B函數調用C函數的話，那么：

這塊用來保存context的空間就是棧幀，當然這里不止保存上下文信息，還保存有函數參數，局部變量等信息。從這里我們可以看到，棧+上下文讓我們實現了函數調用。當然限于篇幅，這里關于函數運行時棧的講解非常簡略，關于這一部分更加詳細的講解關注公眾號碼農的荒島求生并回復關鍵詞運行時棧即可。

系統調用與內核棧當我們讀寫磁盤文件或者創建新的線程時，你有沒有想過到底是誰幫你讀寫的文件，是誰幫你創建的線程呢？答案是操作系統。是的，當你調用類似open這樣的函數時，其實是操作系統在幫你完成文件打開操作，用戶程序向操作系統請求服務就是通過系統調用實現的。好奇的同學可能會繼續問，既然是操作系統來完成這些請求，那么操作系統內部肯定也是調用一系列函數來完成請求處理，有函數調用就需要運行時棧，那么操作系統完成系統調用所需要的運行時棧在哪里呢？答案就在內核棧中，Kernel Stack。原來，每一個用戶態線程在內核態都有一個對應的內核棧：

當用戶線程需要請求操作系統服務時利用系統調用切換到內核模式，這時內核開始代表該用戶態線程執行，內核的執行過程需要的運行時棧就放在了上圖中的內核棧中。讓我們來看一下系統調用的過程。開始時，程序運行在用戶態，此時內核棧還是空的，假設用戶態執行到functionD時需要請求操作系統服務，假設functionD需要調用open函數，該函數內部包含就系統調用，被編譯器翻譯后會生成一條int指令，此時CPU執行到該指令：

該指令的執行將觸發CPU的狀態切換，此時CPU從用戶態切換為內核態，并找到該用戶態線程對應的內核線程，注意重點來了，此時用戶態線程的執行上下文信息（寄存器信息）被保存在內核棧中：

此后CPU開始在內核中執行open相關的操作，后續內核棧會像用戶態運行時棧一樣隨著函數的調用和返回增長以及減少：

當系統調用執行完成后，根據內核棧中保存的用戶態程序上下文信息恢復CPU狀態，并從內核態切換回用戶態，這樣用戶態線程就可以繼續運行了：

現在你應該明白這個過程了吧。那么操作系統為什么要這么麻煩的費心維護用戶態以及內核態呢？用戶態程序為什么要利用系統調用來請求操作系統服務呢？不能直接像普通函數一樣調用操作系統的代碼嗎？關于這些問題的答案，你可以參考博主的深入理解操作系統第2章，關注公眾號碼農的荒島求生并回復操作系統這幾個字即可。

中斷與中斷函數棧現在我們已經講解了兩種涉及CPU上下文切換的場景，包括函數調用以及系統調用，接下來我們再看一種，中斷處理。你的計算機之所以能接受鍵盤按鍵、鼠標指針、網絡數據等，都是通過中斷機制來完成的。中斷本質上就是打斷當前CPU的執行流，跳轉到具體的中斷處理函數中，當中斷處理函數執行完成后再跳轉回來。既然中斷處理函數也是函數，那么必然和普通函數一樣需要運行時棧，那么中斷處理函數的運行時棧又在哪里呢？這分為兩種情況：

中斷處理函數是沒有自己特定的棧的，中斷處理函數依賴內核棧來完成中斷處理。

中斷處理函數有自己特定的棧，被稱之為ISR棧，ISR是interrupt service routine的簡寫，即中斷處理函數棧。由于處理中斷的是CPU，因此在這種方案下每個CPU都有一個自己的中斷處理棧。

為了簡單起見，我們以中斷處理函數共享內核棧為例來講解。實際上你會發現中斷處理函數和系統調用比較類似，不同的是系統調用是用戶態程序主動發起的，而中斷處理是外部設備發起的，也就是說CPU在執行完用戶態的任何一條指令后都可能因為中斷產生而暫停當前程序的執行轉而去執行中斷處理函數，如圖所示：

此后的故事和系統調用類似，CPU從用戶態切換為內核態，并找到該用戶態線程對應的內核線程，并將用戶態線程的執行上下文信息保存在內核棧中：

此后CPU跳轉到中斷處理函數起始地址，中斷處理函數在運行過程中內核棧會像用戶態運行時棧一樣隨著函數的調用和返回增長以及減少：

當中斷處理函數執行完成后，根據內核棧中保存的用戶態程序上下文信息恢復CPU狀態，并從內核態切換回用戶態，這樣用戶態線程就可以繼續運行了。每一次你敲擊鍵盤、滑動鼠標、下載文件等都會有一次上述過程。關于中斷處理更加完整的闡述參見博主深入理解操作系統第3章，關注公眾號碼農的荒島求生并回復操作系統即可。既然你已經知道了中斷是如何實現的，接下來讓我們看下最有意思的線程切換是如何實現的。

線程切換與內核棧現在我們知道了每個線程除了用戶態的函數運行時棧之外還有一個我們看不見的內核棧，系統調用陷入內核后，開始將用戶態上下文信息保存在相應的內核棧上，此后內核代表該線程在內核中執行相應的操作，執行結束后根據內核棧上保存的上下文信息恢復用戶態線程。

那么線程切換是如何實現的呢？線程切換是如何給CPU實施換顱術的呢？本文剩余部分已收錄至小風哥的深入理解操作系統第五章第四節，關注公眾號碼農的荒島求生并回復操作系統即可。

總結程序的運行狀態說到底就是CPU內部的一些寄存器信息，比如指向運行時棧頂的棧寄存器、指向下一條要執行指令的PC寄存器等，這些被稱為上下文信息，能得到這些信息你就能給暫停或者回復程序的運行。

上下文信息的保存與恢復通常通過棧這種機制來實現，棧FILO的特性天然適合應對該場景，這也使得棧成為計算機系統中最為重要的數據結構之一。上下文信息+棧的組合使得函數調用、系統調用、進程切換、線程切換以及中斷處理成為可能。

責任編輯：haq