一文讓你明白CPU上下文切換

咱們都知道，Linux 是一個多任務操做系統，它支持遠大於 CPU 數量的任務同時運行。固然，這些任務實際上並非真的在同時運行，而是由於系統在很短的時間內，將 CPU 輪流分配給它們，形成多任務同時運行的錯覺。

而在每一個任務運行前，CPU 都須要知道任務從哪裏加載、又從哪裏開始運行，也就是說，須要系統事先幫它設置好CPU 寄存器和程序計數器

什麼是 CPU 上下文

CPU 寄存器和程序計數器就是 CPU 上下文，由於它們都是 CPU 在運行任何任務前，必須的依賴環境。

• CPU 寄存器是 CPU 內置的容量小、但速度極快的內存。
• 程序計數器則是用來存儲 CPU 正在執行的指令位置、或者即將執行的下一條指令位置。

什麼是 CPU 上下文切換

就是先把前一個任務的 CPU 上下文（也就是 CPU 寄存器和程序計數器）保存起來，而後加載新任務的上下文到這些寄存器和程序計數器，最後再跳轉到程序計數器所指的新位置，運行新任務。

而這些保存下來的上下文，會存儲在系統內核中，並在任務從新調度執行時再次加載進來。這樣就能保證任務原來的狀態不受影響，讓任務看起來仍是連續運行。

CPU 上下文切換的類型

根據任務的不一樣，能夠分爲如下三種類型

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

進程上下文切換

Linux 按照特權等級，把進程的運行空間分爲內核空間和用戶空間，分別對應着下圖中， CPU 特權等級的 Ring 0 和 Ring 3。

• 內核空間（Ring 0）具備最高權限，能夠直接訪問全部資源；
• 用戶空間（Ring 3）只能訪問受限資源，不能直接訪問內存等硬件設備，必須經過系統調用陷入到內核中，才能訪問這些特權資源。

進程既能夠在用戶空間運行，又能夠在內核空間中運行。進程在用戶空間運行時，被稱爲進程的用戶態，而陷入內核空間的時候，被稱爲進程的內核態。

系統調用

從用戶態到內核態的轉變，須要經過系統調用來完成。好比，當咱們查看文件內容時，就須要屢次系統調用來完成：首先調用 open() 打開文件，而後調用 read() 讀取文件內容，並調用 write() 將內容寫到標準輸出，最後再調用 close() 關閉文件。

在這個過程當中就發生了 CPU 上下文切換，整個過程是這樣的：
一、保存 CPU 寄存器裏原來用戶態的指令位
二、爲了執行內核態代碼，CPU 寄存器須要更新爲內核態指令的新位置。
三、跳轉到內核態運行內核任務。
四、當系統調用結束後，CPU 寄存器須要恢復原來保存的用戶態，而後再切換到用戶空間，繼續運行進程。

因此，一次系統調用的過程，實際上是發生了兩次 CPU 上下文切換。（用戶態-內核態-用戶態）

不過，須要注意的是，系統調用過程當中，並不會涉及到虛擬內存等進程用戶態的資源，也不會切換進程。這跟咱們一般所說的進程上下文切換是不同的：進程上下文切換，是指從一個進程切換到另外一個進程運行；而系統調用過程當中一直是同一個進程在運行。

因此，系統調用過程一般稱爲特權模式切換，而不是上下文切換。系統調用屬於同進程內的 CPU 上下文切換。但實際上，系統調用過程當中，CPU 的上下文切換仍是沒法避免的。

進程上下文切換跟系統調用又有什麼區別呢

首先，進程是由內核來管理和調度的，進程的切換隻能發生在內核態。因此，進程的上下文不只包括了虛擬內存、棧、全局變量等用戶空間的資源，還包括了內核堆棧、寄存器等內核空間的狀態。

所以，進程的上下文切換就比系統調用時多了一步：在保存內核態資源（當前進程的內核狀態和 CPU 寄存器）以前，須要先把該進程的用戶態資源（虛擬內存、棧等）保存下來；而加載了下一進程的內核態後，還須要刷新進程的虛擬內存和用戶棧。

以下圖所示，保存上下文和恢復上下文的過程並非「免費」的，須要內核在 CPU 上運行才能完成。

進程上下文切換潛在的性能問題

根據 Tsuna 的測試報告，每次上下文切換都須要幾十納秒到數微秒的 CPU 時間。這個時間仍是至關可觀的，特別是在進程上下文切換次數較多的狀況下，很容易致使 CPU 將大量時間耗費在寄存器、內核棧以及虛擬內存等資源的保存和恢復上，進而大大縮短了真正運行進程的時間。這也正是致使平均負載升高的一個重要因素。

另外，咱們知道， Linux 經過 TLB（Translation Lookaside Buffer）來管理虛擬內存到物理內存的映射關係。當虛擬內存更新後，TLB 也須要刷新，內存的訪問也會隨之變慢。特別是在多處理器系統上，緩存是被多個處理器共享的，刷新緩存不只會影響當前處理器的進程，還會影響共享緩存的其餘處理器的進程。

發生進程上下文切換的場景

1. 爲了保證全部進程能夠獲得公平調度，CPU 時間被劃分爲一段段的時間片，這些時間片再被輪流分配給各個進程。這樣，當某個進程的時間片耗盡了，就會被系統掛起，切換到其它正在等待 CPU 的進程運行。
2. 進程在系統資源不足（好比內存不足）時，要等到資源知足後才能夠運行，這個時候進程也會被掛起，並由系統調度其餘進程運行。
3. 當進程經過睡眠函數 sleep 這樣的方法將本身主動掛起時，天然也會從新調度。
4. 當有優先級更高的進程運行時，爲了保證高優先級進程的運行，當前進程會被掛起，由高優先級進程來運行
5. 發生硬件中斷時，CPU 上的進程會被中斷掛起，轉而執行內核中的中斷服務程序。

線程上下文切換

線程與進程最大的區別在於：線程是調度的基本單位，而進程則是資源擁有的基本單位。說白了，所謂內核中的任務調度，實際上的調度對象是線程；而進程只是給線程提供了虛擬內存、全局變量等資源。

因此，對於線程和進程，咱們能夠這麼理解：

• 當進程只有一個線程時，能夠認爲進程就等於線程。
• 當進程擁有多個線程時，這些線程會共享相同的虛擬內存和全局變量等資源。這些資源在上下文切換時是不須要修改的。
• 另外，線程也有本身的私有數據，好比棧和寄存器等，這些在上下文切換時也是須要保存的。

發生線程上下文切換的場景

1. 先後兩個線程屬於不一樣進程。此時，由於資源不共享，因此切換過程就跟進程上下文切換是同樣。
2. 先後兩個線程屬於同一個進程。此時，由於虛擬內存是共享的，因此在切換時，虛擬內存這些資源就保持不動，只須要切換線程的私有數據、寄存器等不共享的數據

中斷上下文切換

爲了快速響應硬件的事件，中斷處理會打斷進程的正常調度和執行，轉而調用中斷處理程序，響應設備事件。而在打斷其餘進程時，就須要將進程當前的狀態保存下來，這樣在中斷結束後，進程仍然能夠從原來的狀態恢復運行。

跟進程上下文不一樣，中斷上下文切換並不涉及到進程的用戶態。因此，即使中斷過程打斷了一個正處在用戶態的進程，也不須要保存和恢復這個進程的虛擬內存、全局變量等用戶態資源。中斷上下文，其實只包括內核態中斷服務程序執行所必需的狀態，包括 CPU 寄存器、內核堆棧、硬件中斷參數等。

對同一個 CPU 來講，中斷處理比進程擁有更高的優先級，因此中斷上下文切換並不會與進程上下文切換同時發生。一樣道理，因爲中斷會打斷正常進程的調度和執行，因此大部分中斷處理程序都短小精悍，以便儘量快的執行結束。

另外，跟進程上下文切換同樣，中斷上下文切換也須要消耗 CPU，切換次數過多也會耗費大量的 CPU，甚至嚴重下降系統的總體性能。因此，當你發現中斷次數過多時，就須要注意去排查它是否會給你的系統帶來嚴重的性能問題。

本文整理自極客時間：《Linux性能優化實戰》

PS：本文原創發佈於微信公衆號「不僅Java」，後臺回覆如下關鍵字獲取經典必讀書籍： Java、MySQL、Redis、Linux、mq、數據結構、設計模式、編程思想、架構。

公衆號專一分享 Java 乾貨、讀書筆記、成長思考。