我們都知道 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時間消耗在寄存器，內核棧以及虛擬內存等數據的保存和恢復上，從而縮短進程真正運行的時間，導致系統的整體性能大幅下降。
• 自愿上下文切換變多了，說明進程都在等待資源，有可能發生了 I/O 等其他問題
• 非自愿上下文切換變多了，說明進程都在被強制調度，也就是都在爭搶 CPU，說明 CPU 的確成了瓶頸
• 中斷次數變多了，說明 CPU 被中斷處理程序占用，還需要通過查看 /proc/interrupts 文件來分析具體的中斷類型。

參考

https://medium.com/geekculture/linux-cpu-context-switch-deep-dive-764bfdae4f01