二.  程序狀態說明

2.1  R (task_running) : 可執行狀態

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

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

2.2  S (task_interruptible): 可中斷的睡眠狀態

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

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

2.3  D (task_uninterruptible): 不可中斷的睡眠狀態

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

       絕大多數情況下，程序處在睡眠狀態時，總是應該能夠響應非同步訊號的。但是uninterruptible sleep 狀態的程序不接受外來的任何訊號，因此無法用kill殺掉這些處於D狀態的程序，無論是”kill”, “kill -9″還是”kill -15″，這種情況下，一個可選的方法就是reboot。

       處於uninterruptible sleep狀態的程序通常是在等待IO，比如磁碟IO，網路IO，其他外設IO，如果程序正在等待的IO在較長的時間內都沒有響應，那麼就被ps看到了，同時也就意味著很有可能有IO出了問題，可能是外設本身出了故障，也可能是比如掛載的遠端檔案系統已經不可訪問了.

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

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

       我們通過vmstat 命令中procs下的b 可以來檢視是否有處於uninterruptible 狀態的程序。 該命令只能顯示數量。

   In computer operating systems terminology, a sleeping process can either be interruptible (woken via signals) or uninterruptible (woken explicitly). An uninterruptible sleep state is a sleep state that cannot handle a signal (such as waiting for disk or network IO (input/output)).

     When the process is sleeping uninterruptibly, the signal will be noticed when the process returns from the system call or trap.

     -- 這句是關鍵。 當處於uninterruptibly sleep 狀態時，只有當程序從system 呼叫返回時，才通知signal。

     A process which ends up in “D” state for any measurable length of time is trapped in the midst of a system call (usually an I/O operation on a device — thus the initial in the ps output).

      Such a process cannot be killed — it would risk leaving the kernel in an inconsistent state, leading to a panic. In general you can consider this to be a bug in the device driver that the process is accessing.

2.4  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狀態。

2.5 Z (task_dead - exit_zombie)：退出狀態，程序成為殭屍程序

       在Linux程序的狀態中，殭屍程序是非常特殊的一種，它是已經結束了的程序，但是沒有從程序表中刪除。太多了會導致程序表裡麵條目滿了，進而導致系統崩潰，倒是不佔用其他系統資源。    

       它已經放棄了幾乎所有記憶體空間，沒有任何可執行程式碼，也不能被排程，僅僅在程序列表中保留一個位置，記載該程序的退出狀態等資訊供其他程序收集，除此之外，殭屍程序不再佔有任何記憶體空間。      

       程序在退出的過程中，處於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系統呼叫建立子程序時，可以設定這個訊號。

       如果他的父程序沒安裝SIGCHLD訊號處理函式呼叫wait或waitpid()等待子程序結束，又沒有顯式忽略該訊號，那麼它就一直保持殭屍狀態，子程序的屍體（task_struct）也就無法釋放掉。

       如果這時父程序結束了，那麼init程序自動會接手這個子程序，為它收屍，它還是能被清除的。但是如果如果父程序是一個迴圈，不會結束，那麼子程序就會一直保持殭屍狀態，這就是為什麼系統中有時會有很多的殭屍程序。

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

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

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

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

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

Unix/Linux 處理殭屍程序的方法：

       找出父程序號，然後kill 父程序，之後子程序（殭屍程序）會被託管到其他程序，如init程序，然後由init程序將子程序的屍體（task_struct）釋放掉。

除了通過ps 的狀態來檢視Zombi程序，還可以用如下命令檢視：

[[email protected] ~]$ ps -ef|grep defun

oracle   13526 12825  0 16:48 pts/1    00:00:00 grep defun

oracle   28330 28275  0 May18 ?        00:00:00 [Xsession] <defunct>

殭屍程序解決辦法：

（1）改寫父程序，在子程序死後要為它收屍。

       具體做法是接管SIGCHLD訊號。子程序死後，會發送SIGCHLD訊號給父程序，父程序收到此訊號後，執行 waitpid()函式為子程序收屍。這是基於這樣的原理：就算父程序沒有呼叫wait，核心也會向它傳送SIGCHLD訊息，儘管對的預設處理是忽略，如果想響應這個訊息，可以設定一個處理函式。

（2）把父程序殺掉。

       父程序死後，殭屍程序成為"孤兒程序"，過繼給1號程序init，init始終會負責清理殭屍程序．它產生的所有殭屍程序也跟著消失。如：

       kill -9 `ps -ef | grep "Process Name" | awk '{ print $3 }'`

       其中，“Process Name”為處於zombie狀態的程序名。

（3）殺父程序不行的話，就嘗試用skill -t TTY關閉相應終端，TTY是程序相應的tty號(終端號)。但是，ps可能會查不到特定程序的tty號，這時就需要自己判斷了。

（4）重啟系統，這也是最常用到方法之一。

2.6 X (task_dead - exit_dead)：退出狀態，程序即將被銷燬

       程序在退出過程中也可能不會保留它的task_struct。比如這個程序是多執行緒程式中被detach過的程序。或者父程序通過設定sigchld訊號的handler為sig_ign，顯式的忽略了sigchld訊號。（這是posix的規定，儘管子程序的退出訊號可以被設定為sigchld以外的其他訊號。）

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

三. 程序狀態變化說明

3.1 程序的初始狀態

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

       那麼既然呼叫程序處於task_running狀態（否則，它若不是正在執行，又怎麼進行呼叫？），則子程序預設也處於task_running狀態。

       另外，在系統呼叫呼叫clone和核心函式kernel_thread也接受clone_stopped選項，從而將子程序的初始狀態置為 task_stopped。

3.2 程序狀態變遷

       程序自建立以後，狀態可能發生一系列的變化，直到程序退出。而儘管程序狀態有好幾種，但是程序狀態的變遷卻只有兩個方向——從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上執行的情況下。