linux進程狀態淺析

      眾所周知，現在的分時作業系統能夠在一個CPU上運行多個程式，讓這些程式表面上看起來是在同時啟動並執行。linux就是這樣的一個作業系統。

　　在linux系統中，每個被啟動並執行程式執行個體對應一個或多個進程。linux核心需要對這些進程進行管理，以使它們在系統中“同時”運行。 linux核心對進程的這種管理分兩個方面：進程狀態管理，和進程調度。本文主要介紹進程狀態管理，進程調度見《linux進程調度淺析》。

　　進程狀態

　　在linux下，通過ps命令我們能夠查看到系統中存在的進程，以及它們的狀態：

　　R (TASK_RUNNING)，可執行狀態。

　　只有在該狀態的進程才可能在CPU上運行。而同一時刻可能有多個進程處於可執行狀態，這些進程的task_struct結構（進程式控制制塊）被放 入對應 CPU的可執行隊列中（一個進程最多隻能出現在一個CPU的可執行隊列中）。進程調度器的任務就是從各個CPU的可執行隊列中分別選擇一個進程在該CPU 上運行。

　　只要可執行隊列不為空白，其對應的CPU就不能偷懶，就要執行其中某個進程。一般稱此時的CPU“忙碌”。對應的，CPU“空閑”就是指其對應的 可執行隊列為空白，以致於CPU無事可做。

　　有人問，為什麼死迴圈程式會導致CPU佔用高呢？因為死迴圈程式基本上總是處於TASK_RUNNING狀態（進程處於可執行隊列中）。除非一 些非常極端情況（比如系統記憶體嚴重緊缺，導致進程的某些需要使用的頁面被換出，並且在頁面需要換入時又無法分配到記憶體……），否則這個進程不會睡眠。所以 CPU的可執行隊列總是不為空白（至少有這麼個進程存在），CPU也就不會“空閑”。

　　很多作業系統教科書將正在CPU上執行的進程定義為RUNNING狀態、而將可執行但是尚未被調度執行的進程定義為READY狀態，這兩種狀態 在linux下統一為 TASK_RUNNING狀態。

　　S (TASK_INTERRUPTIBLE)，可中斷的睡眠狀態。

　　處於這個狀態的進程因為等待某某事件的發生（比如等待socket串連、等待訊號量），而被掛起。這些進程的task_struct結構被放入 對應事件的等待隊列中。當這些事件發生時（由外部中斷觸發、或由其他進程觸發），對應的等待隊列中的一個或多個進程將被喚醒。

　　通過ps命令我們會看到，一般情況下，進程列表中的絕大多數進程都處於TASK_INTERRUPTIBLE狀態（除非機器的負載很高）。畢竟 CPU就這麼一兩個，進程動輒幾十上百個，如果不是絕大多數進程都在睡眠，CPU又怎麼響應得過來。

　　D (TASK_UNINTERRUPTIBLE)，不可中斷的睡眠狀態。

　　與TASK_INTERRUPTIBLE狀態類似，進程處於睡眠狀態，但是此刻進程是不可中斷的。不可中斷，指的並不是CPU不響應外部硬體的 中斷，而是指進程不響應非同步訊號。

　　絕大多數情況下，進程處在睡眠狀態時，總是應該能夠響應非同步訊號的。否則你將驚奇的發現，kill -9竟然殺不死一個正在睡眠的進程了！於是我們也很好理解，為什麼ps命令看到的進程幾乎不會出現TASK_UNINTERRUPTIBLE狀態，而總是 TASK_INTERRUPTIBLE狀態。

　　而TASK_UNINTERRUPTIBLE狀態存在的意義就在於，核心的某些處理流程是不能被打斷的。如果響應非同步訊號，程式的執行流程中就 會被插入一段用於處理非同步訊號的流程（這個插入的流程可能只存在於核心態，也可能延伸到使用者態），於是原有的流程就被中斷了。（參見《linux核心非同步 中斷淺析》）

　　在進程對某些硬體進行操作時（比如進程調用read系統調用對某個裝置檔案進行讀操作，而read系統調用最終執行到對應裝置驅動的代碼，並與 對應的物理裝置進行互動），可能需要使用TASK_UNINTERRUPTIBLE狀態對進程進行保護，以避免進程與裝置互動的過程被打斷，造成裝置陷入 不可控的狀態。這種情況下的TASK_UNINTERRUPTIBLE狀態總是非常短暫的，通過ps命令基本上不可能捕捉到。

　　linux系統中也存在容易捕捉的TASK_UNINTERRUPTIBLE狀態。執行vfork系統調用後，父進程將進入 TASK_UNINTERRUPTIBLE狀態，直到子進程調用exit或exec（參見《神奇的vfork》）。

　　通過下面的代碼就能得到處於TASK_UNINTERRUPTIBLE狀態的進程：

　　#include <unistd.h>

　　void main() {

　　if (!vfork()) sleep(100);

　　}

　　編譯運行，然後ps一下：

　　kouu@kouu-one:~/test$ ps -ax | grep a\.out

　　4371 pts/0    D+     0:00 ./a.out

　　4372 pts/0    S+     0:00 ./a.out

　　4374 pts/1    S+     0:00 grep a.out

　　然後我們可以實驗一下TASK_UNINTERRUPTIBLE狀態的威力。不管kill還是kill -9，這個TASK_UNINTERRUPTIBLE狀態的父進程依然屹立不倒。

　　T (TASK_STOPPED or TASK_TRACED)，暫停狀態或跟蹤狀態。

　　向進程發送一個SIGSTOP訊號，它就會因響應該訊號而進入TASK_STOPPED狀態（除非該進程本身處於 TASK_UNINTERRUPTIBLE狀態而不響應訊號）。（SIGSTOP與SIGKILL訊號一樣，是非常強制的。不允許使用者進程通過 signal系列的系統調用重新設定對應的訊號處理函數。）

　　向進程發送一個SIGCONT訊號，可以讓其從TASK_STOPPED狀態恢複到TASK_RUNNING狀態。

　　當進程正在被跟蹤時，它處於TASK_TRACED這個特殊的狀態。“正在被跟蹤”指的是進程暫停下來，等待跟蹤它的進程對它進行操作。比如在 gdb中對被跟蹤的進程下一個斷點，進程在斷點處停下來的時候就處於TASK_TRACED狀態。而在其他時候，被跟蹤的進程還是處於前面提到的那些狀 態。

 

對於進程本身來說，TASK_STOPPED和TASK_TRACED狀態很類似，都是表示進程暫停下來。

　　而TASK_TRACED狀態相當於在TASK_STOPPED之上多了一層保護，處於TASK_TRACED狀態的進程不能響應 SIGCONT訊號而被喚醒。只能等到調試進程通過ptrace系統調用執行PTRACE_CONT、PTRACE_DETACH等操作（通過 ptrace系統調用的參數指定操作），或調試進程退出，被調試的進程才能恢複TASK_RUNNING狀態。

　　Z (TASK_DEAD - EXIT_ZOMBIE)，退出狀態，進程成為殭屍進程。

　　進程在退出的過程中，處於TASK_DEAD狀態。

　　在這個退出過程中，進程佔有的所有資源將被回收，除了task_struct結構（以及少數資源）以外。於是進程就只剩下 task_struct這麼個空殼，故稱為殭屍。

　　之所以保留task_struct，是因為task_struct裡面儲存了進程的退出碼、以及一些統計資訊。而其父進程很可能會關心這些信 息。比如在shell中，$?變數就儲存了最後一個退出的前台進程的退出碼，而這個退出碼往往被作為if語句的判斷條件。

　　當然，核心也可以將這些資訊儲存在別的地方，而將task_struct結構釋放掉，以節省一些空間。但是使用task_struct結構更為 方便，因為在核心中已經建立了從pid到task_struct尋找關係，還有進程間的父子關係。釋放掉task_struct，則需要建立一些新的資料 結構，以便讓父進程找到它的子進程的退出資訊。

　　父進程可以通過wait系列的系統調用（如wait4、waitid）來等待某個或某些子進程的退出，並擷取它的退出資訊。然後wait系列的 系統調用會順便將子進程的屍體（task_struct）也釋放掉。

　　子進程在退出的過程中，核心會給其父進程發送一個訊號，通知父進程來“收屍”。這個訊號預設是SIGCHLD，但是在通過clone系統調用創 建子進程時，可以設定這個訊號。

　　通過下面的代碼能夠製造一個EXIT_ZOMBIE狀態的進程：

　　#include <unistd.h>

　　void main() {

　　if (fork())

　　while(1) sleep(100);

　　}

　　編譯運行，然後ps一下：

　　kouu@kouu-one:~/test$ ps -ax | grep a\.out

　　10410 pts/0    S+     0:00 ./a.out

　　10411 pts/0    Z+     0:00 [a.out] <defunct>

　　10413 pts/1    S+     0:00 grep a.out

　　只要父進程不退出，這個殭屍狀態的子進程就一直存在。那麼如果父進程退出了呢，誰又來給子進程“收屍”？

　　當進程退出的時候，會將它的所有子進程都託管給別的進程（使之成為別的進程的子進程）。託管給誰呢？可能是退出進程所在進程組的下一個進程（如 果存在的話），或者是1號進程。所以每個進程、每時每刻都有父進程存在。除非它是1號進程。

　　1號進程，pid為1的進程，又稱init進程。

　　linux系統啟動後，第一個被建立的使用者態進程就是init進程。它有兩項使命：

　　1、執行系統初始化指令碼，建立一系列的進程（它們都是init進程的子孫）；

　　2、在一個死迴圈中等待其子進程的退出事件，並調用waitid系統調用來完成“收屍”工作；

　　init進程不會被暫停、也不會被殺死（這是由核心來保證的）。它在等待子進程退出的過程中處於TASK_INTERRUPTIBLE狀態， “收屍”過程中則處於TASK_RUNNING狀態。

　　X (TASK_DEAD - EXIT_DEAD)，退出狀態，進程即將被銷毀。

　　而進程在退出過程中也可能不會保留它的task_struct。比如這個進程是多線程程式中被detach過的進程（進程？線程？參見 《linux線程淺析》）。或者父進程通過設定SIGCHLD訊號的handler為SIG_IGN，顯式的忽略了SIGCHLD訊號。（這是posix 的規定，儘管子進程的退出訊號可以被設定為SIGCHLD以外的其他訊號。）

　　此時，進程將被置於EXIT_DEAD退出狀態，這意味著接下來的代碼立即就會將該進程徹底釋放。所以EXIT_DEAD狀態是非常短暫的，幾 乎不可能通過ps命令捕捉到。

　　進程的初始狀態

　　進程是通過fork系列的系統調用（fork、clone、vfork）來建立的，核心（或核心模組）也可以通過kernel_thread函 數建立核心進程。這些建立子進程的函數本質上都完成了相同的功能——將調用進程複製一份，得到子進程。（可以通過選項參數來決定各種資源是共用、還是私 有。）

　　那麼既然調用進程處於TASK_RUNNING狀態（否則，它若不是正在運行，又怎麼進行調用？），則子進程預設也處於 TASK_RUNNING狀態。

　　另外，在系統調用調用clone和核心功能kernel_thread也接受CLONE_STOPPED選項，從而將子進程的初始狀態置為 TASK_STOPPED。

　　進程狀態變遷

　　進程自建立以後，狀態可能發生一系列的變化，直到進程退出。而儘管進程狀態有好幾種，但是進程狀態的變遷卻只有兩個方向——從 TASK_RUNNING狀態變為非TASK_RUNNING狀態、或者從非TASK_RUNNING狀態變為TASK_RUNNING狀態。

　　也就是說，如果給一個TASK_INTERRUPTIBLE狀態的進程發送SIGKILL訊號，這個進程將先被喚醒（進入 TASK_RUNNING狀態），然後再響應SIGKILL訊號而退出（變為TASK_DEAD狀態）。並不會從TASK_INTERRUPTIBLE狀 態直接退出。

　　進程從非TASK_RUNNING狀態變為TASK_RUNNING狀態，是由別的進程（也可能是中斷處理常式）執行喚醒操作來實現的。執行喚 醒的進程設定被喚醒進程的狀態為TASK_RUNNING，然後將其task_struct結構加入到某個CPU的可執行隊列中。於是被喚醒的進程將有機 會被調度執行。

　　而進程從TASK_RUNNING狀態變為非TASK_RUNNING狀態，則有兩種途徑：

　　1、響應訊號而進入TASK_STOPED狀態、或TASK_DEAD狀態；

　　2、執行系統調用主動進入TASK_INTERRUPTIBLE狀態（如nanosleep系統調用）、或TASK_DEAD狀態（如exit 系統調用）；或由於執行系統調用需要的資源得不到滿足，而進入TASK_INTERRUPTIBLE狀態或TASK_UNINTERRUPTIBLE狀態 （如 select系統調用）。

　　顯然，這兩種情況都只能發生在進程正在CPU上執行的情況下。