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

CPU 上下文（CPU Context）

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

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

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

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

這些保存的上下文存儲在系統內核中，并在重新安排任務執行時再次加載。這確保了任務的原始狀態不受影響，并且任務似乎在持續運行。

CPU 上下文切換的類型

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

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

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

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

• 進程上下文切換
• 線程上下文切換
• 中斷上下文切換

讓我們一一來看看。

進程上下文切換

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

• 內核空間（Ring 0）擁有最高權限，可以直接訪問所有資源
• 用戶空間（Ring 3）只能訪問受限資源，不能直接訪問內存等硬件設備。它必須通過系統調用被陷入（trapped）內核中才能訪問這些特權資源。

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

從用戶態到內核態的轉換需要通過系統調用來完成。例如，當我們查看一個文件的內容時，我們需要以下系統調用：

• open()：打開文件
• read()：讀取文件的內容
• write()：將文件的內容寫入到輸出文件（包括標準輸出）
• close()：關閉文件

那么在上述系統調用過程中是否會發生 CPU 上下文切換呢？當然是的。

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

那么系統調用結束后，CPU 寄存器需要恢復原來保存的用戶狀態，然后切換到用戶空間繼續運行進程。

因此，在一次系統調用的過程中，實際上有兩次 CPU 上下文切換。

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

系統調用過程通常被稱為特權模式切換，而不是上下文切換。但實際上，在系統調用過程中，CPU 的上下文切換也是不可避免的。

進程上下文切換 vs 系統調用

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

所以進程上下文切換比系統調用要多出一步：

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

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

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

• 當一個進程的 CPU 時間片用完時，它會被系統掛起，并切換到其他等待 CPU 運行的進程。
• 當系統資源不足（如內存不足）時，直到資源充足之前，進程無法運行。此時進程也會被掛起，系統會調度其他進程運行。
• 當一個進程通過 sleep 函數自動掛起自己時，自然會被重新調度。
• 當優先級較高的進程運行時，為了保證高優先級進程的運行，當前進程會被高優先級進程掛起運行。
• 當發生硬件中斷時，CPU 上的進程會被中斷掛起，轉而執行內核中的中斷服務程序。

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

線程上下文切換

線程和進程最大的區別在于，線程是任務調度的基本單位，而進程是資源獲取的基本單位。

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

• 當一個進程只有一個線程時，可以認為一個進程等于一個線程
• 當一個進程有多個線程時，這些線程共享相同的資源，例如虛擬內存和全局變量。
• 此外，線程也有自己的私有數據，比如棧和寄存器，在上下文切換時也需要保存。

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

• 首先，前后兩個線程屬于不同的進程。此時，由于資源不共享，切換過程與進程上下文切換相同。
• 其次，前后兩個線程屬于同一個進程。此時，由于虛擬內存是共享的，所以切換時虛擬內存的資源保持不變，只需要切換線程的私有數據、寄存器等未共享的數據。

顯然，同一個進程內的線程切換比切換多個進程消耗的資源要少。這也是多線程替代多進程的優勢。

中斷上下文切換

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

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

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

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

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

結論

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

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

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