我們都知道 Linux 是一個多任務操作系統(tǒng)，它支持的任務同時運行的數(shù)量遠遠大于 CPU 的數(shù)量。當然，這些任務實際上并不是同時運行的（Single CPU），而是因為系統(tǒng)在短時間內(nèi)將 CPU 輪流分配給任務，造成了多個任務同時運行的假象。

CPU 上下文（CPU Context）

在每個任務運行之前，CPU 需要知道在哪里加載和啟動任務。這意味著系統(tǒng)需要提前幫助設置 CPU 寄存器和程序計數(shù)器。

CPU 寄存器是內(nèi)置于 CPU 中的小型但速度極快的內(nèi)存。程序計數(shù)器用于存儲 CPU 正在執(zhí)行的或下一條要執(zhí)行指令的位置。

它們都是 CPU 在運行任何任務之前必須依賴的依賴環(huán)境，因此也被稱為 “CPU 上下文”。如下圖所示：

知道了 CPU 上下文是什么，我想你理解CPU 上下文切換就很容易了。“CPU上下文切換”指的是先保存上一個任務的 CPU 上下文（CPU寄存器和程序計數(shù)器），然后將新任務的上下文加載到這些寄存器和程序計數(shù)器中，最后跳轉(zhuǎn)到程序計數(shù)器。

這些保存的上下文存儲在系統(tǒng)內(nèi)核中，并在重新安排任務執(zhí)行時再次加載。這確保了任務的原始狀態(tài)不受影響，并且任務似乎在持續(xù)運行。

CPU 上下文切換的類型

你可能會說 CPU 上下文切換無非就是更新 CPU 寄存器和程序計數(shù)器值，而這些寄存器是為了快速運行任務而設計的，那為什么會影響 CPU 性能呢？

在回答這個問題之前，請問，你有沒有想過這些“任務”是什么？你可能會說一個任務就是一個進程或者一個線程。是的，進程和線程正是最常見的任務，但除此之外，還有其他類型的任務。

別忘了硬件中斷也是一個常見的任務，硬件觸發(fā)信號，會引起中斷處理程序的調(diào)用。

因此，CPU 上下文切換至少有三種不同的類型：

進程上下文切換

線程上下文切換

中斷上下文切換

讓我們一一來看看。

進程上下文切換

Linux 按照特權(quán)級別將進程的運行空間劃分為內(nèi)核空間和用戶空間，分別對應下圖中 Ring 0 和 Ring 3 的 CPU 特權(quán)級別的 。

內(nèi)核空間（Ring 0）擁有最高權(quán)限，可以直接訪問所有資源

用戶空間（Ring 3）只能訪問受限資源，不能直接訪問內(nèi)存等硬件設備。它必須通過系統(tǒng)調(diào)用被陷入（trapped）內(nèi)核中才能訪問這些特權(quán)資源。

從另一個角度看，一個進程既可以在用戶空間也可以在內(nèi)核空間運行。當一個進程在用戶空間運行時，稱為該進程的用戶態(tài)，當它落入內(nèi)核空間時，稱為該進程的內(nèi)核態(tài)。

從用戶態(tài)到內(nèi)核態(tài)的轉(zhuǎn)換需要通過系統(tǒng)調(diào)用來完成。例如，當我們查看一個文件的內(nèi)容時，我們需要以下系統(tǒng)調(diào)用：

open()：打開文件

read()：讀取文件的內(nèi)容

write()：將文件的內(nèi)容寫入到輸出文件（包括標準輸出）

close()：關(guān)閉文件

那么在上述系統(tǒng)調(diào)用過程中是否會發(fā)生 CPU 上下文切換呢？當然是的。

這需要先保存 CPU 寄存器中原來的用戶態(tài)指令的位置。接下來，為了執(zhí)行內(nèi)核態(tài)的代碼，需要將 CPU 寄存器更新到內(nèi)核態(tài)指令的新位置。最后是跳轉(zhuǎn)到內(nèi)核態(tài)運行內(nèi)核任務。

那么系統(tǒng)調(diào)用結(jié)束后，CPU 寄存器需要恢復原來保存的用戶狀態(tài)，然后切換到用戶空間繼續(xù)運行進程。

因此，在一次系統(tǒng)調(diào)用的過程中，實際上有兩次 CPU 上下文切換。

但需要指出的是，系統(tǒng)調(diào)用進程不會涉及進程切換，也不會涉及虛擬內(nèi)存等系統(tǒng)資源切換。這與我們通常所說的“進程上下文切換”不同。進程上下文切換是指從一個進程切換到另一個進程，而系統(tǒng)調(diào)用期間始終運行同一個進程

系統(tǒng)調(diào)用過程通常被稱為特權(quán)模式切換，而不是上下文切換。但實際上，在系統(tǒng)調(diào)用過程中，CPU 的上下文切換也是不可避免的。

進程上下文切換 vs 系統(tǒng)調(diào)用

那么進程上下文切換和系統(tǒng)調(diào)用有什么區(qū)別呢？首先，進程是由內(nèi)核管理的，進程切換只能發(fā)生在內(nèi)核態(tài)。因此，進程上下文不僅包括虛擬內(nèi)存、棧和全局變量等用戶空間資源，還包括內(nèi)核棧和寄存器等內(nèi)核空間的狀態(tài)。

所以進程上下文切換比系統(tǒng)調(diào)用要多出一步：

在保存當前進程的內(nèi)核狀態(tài)和 CPU 寄存器之前，需要保存進程的虛擬內(nèi)存、棧等；并加載下一個進程的內(nèi)核狀態(tài)。

根據(jù) Tsuna 的測試報告，每次上下文切換需要幾十納秒至微秒的 CPU 時間。這個時間是相當可觀的，尤其是在大量進程上下文切換的情況下，很容易導致 CPU 花費大量時間來保存和恢復寄存器、內(nèi)核棧、虛擬內(nèi)存等資源。這正是我們在上一篇文章中談到的，一個導致平均負載上升的重要因素。

那么，該進程何時會被調(diào)度/切換到在 CPU 上運行？其實有很多場景，下面我為大家總結(jié)一下：

當一個進程的 CPU 時間片用完時，它會被系統(tǒng)掛起，并切換到其他等待 CPU 運行的進程。

當系統(tǒng)資源不足（如內(nèi)存不足）時，直到資源充足之前，進程無法運行。此時進程也會被掛起，系統(tǒng)會調(diào)度其他進程運行。

當一個進程通過 sleep 函數(shù)自動掛起自己時，自然會被重新調(diào)度。

當優(yōu)先級較高的進程運行時，為了保證高優(yōu)先級進程的運行，當前進程會被高優(yōu)先級進程掛起運行。

當發(fā)生硬件中斷時，CPU 上的進程會被中斷掛起，轉(zhuǎn)而執(zhí)行內(nèi)核中的中斷服務程序。

了解這些場景是非常有必要的，因為一旦上下文切換出現(xiàn)性能問題，它們就是幕后殺手。

線程上下文切換

線程和進程最大的區(qū)別在于，線程是任務調(diào)度的基本單位，而進程是資源獲取的基本單位。

說白了，內(nèi)核中所謂的任務調(diào)度，實際的調(diào)度對象是線程；而進程只為線程提供虛擬內(nèi)存和全局變量等資源。所以，對于線程和進程，我們可以這樣理解：

當一個進程只有一個線程時，可以認為一個進程等于一個線程

當一個進程有多個線程時，這些線程共享相同的資源，例如虛擬內(nèi)存和全局變量。

此外，線程也有自己的私有數(shù)據(jù)，比如棧和寄存器，在上下文切換時也需要保存。

這樣，線程的上下文切換其實可以分為兩種情況：

首先，前后兩個線程屬于不同的進程。此時，由于資源不共享，切換過程與進程上下文切換相同。

其次，前后兩個線程屬于同一個進程。此時，由于虛擬內(nèi)存是共享的，所以切換時虛擬內(nèi)存的資源保持不變，只需要切換線程的私有數(shù)據(jù)、寄存器等未共享的數(shù)據(jù)。

顯然，同一個進程內(nèi)的線程切換比切換多個進程消耗的資源要少。這也是多線程替代多進程的優(yōu)勢。

中斷上下文切換

除了前面兩種上下文切換之外，還有另外一種場景也輸出 CPU 上下文切換的，那就是中斷。

為了快速響應事件，硬件中斷會中斷正常的調(diào)度和執(zhí)行過程，進而調(diào)用中斷處理程序。

在中斷其他進程時，需要保存進程的當前狀態(tài)，以便中斷后進程仍能從原始狀態(tài)恢復。

與進程上下文不同，中斷上下文切換不涉及進程的用戶態(tài)。因此，即使中斷進程中斷了處于用戶態(tài)的進程，也不需要保存和恢復進程的虛擬內(nèi)存、全局變量等用戶態(tài)資源。

另外，和進程上下文切換一樣，中斷上下文切換也會消耗 CPU。過多的切換次數(shù)會消耗大量的 CPU 資源，甚至嚴重降低系統(tǒng)的整體性能。因此，當您發(fā)現(xiàn)中斷過多時，需要注意排查它是否會對您的系統(tǒng)造成嚴重的性能問題。

結(jié)論

綜上所述，無論哪種場景導致上下文切換，你都應該知道：

CPU 上下文切換是保證 Linux 系統(tǒng)正常運行的核心功能之一，一般不需要我們特別關(guān)注。

但是過多的上下文切換會消耗 CPU 的時間來保存和恢復寄存器、內(nèi)核棧、虛擬內(nèi)存等數(shù)據(jù)，從而縮短進程的實際運行時間，導致系統(tǒng)整體性能顯著下降。

作者：郭主任講網(wǎng)絡

審核編輯 ：李倩