Behman: 處理內核層面的停滯問題與處理應用軟件層面的停滯是有著很大不同的。

　　如果你問的是關于應用軟件層面。當沖突問題發生時，有著一種稱為“信號處理”的特殊功能來調用處理各種各樣的信息，例如內存中的信息，堆棧的跟蹤反饋等。所以一般情況下，遇到沖突問題時，首要的問題就是收集、整理、分析這些數據。

　　而在停滯問題發生時，這種數據不會自動的收集，而這往往是一種人工的操作過程。收集停滯狀態數據的兩個關鍵點在于追蹤輸出結果以及堆棧的跟蹤反饋。這種追蹤輸出結果的方式能夠得出該進程作用情況的信息，因為它在一直的監視該進程;這些信息例如，該進程是否仍然在作用等等。而堆棧的跟蹤反饋可以給出目前進程作用的源代碼部分。這對于開發人員是非常重要的，這樣以來他們就可以研究該進程停滯問題產生的原因。

　　對于沖突及停滯問題，其最主要的原因是什么呢?

　　Wilding: 對于沖突問題而言，我們可以把它的主要原因分為兩種，一種是預防型的，另一種是錯誤處理型的。預防型沖突是內核或應用軟件由于遇到了嚴峻的形勢而產生沖突問題的情況。而軟件意識到這種問題，并產生一種“自殺式”的方法以阻止錯誤的進一步發生，從而避免更加嚴重的問題出現。而對于錯誤處理型的沖突，它意味著內存中有著某些不合法的內容進入，幾乎都是一些程序的錯誤。在這種情況下，硬件探測到這種應用軟件，然后發送信號去阻止該軟件的進程。

　　對于停滯問題而言，也一般存在著兩種原因狀況。一種是進程或線程等待資源的情況，這不一定能否解決。而其他的進程或線程約束著該資源(例如，上鎖)，這樣該進程或線程在等待時，其還占據著資源，從而其他進程或線程也只能等待。一個例子就是某個進程對占據的重要資源上鎖，而其自身在漫無目的接收因特網的信息。第二中比較常見的原因就是一種“依賴回路式”的等待，在此兩個或者多個進程在互相等待它方的資源，從而陷入“死鎖”。這種情況的解決方法可以是釋放一個鎖，或者在某個空間中共享內存等。

　　在這些沖突以及停滯的情形之下，管理者們有哪些基本的調查研究規則可以應用呢?

　　Wilding: 一個最好的基本準則就是有組織的參加工作。很重要的一點就是把收集的數據有規則的放在一個明確的地點，這樣將來能夠很容易的找到。這對于那些同時遇到多個問題的情況尤為有用。

　　Behman: 另一個基本的準則就是要定量的收集數據，而不是定性的收集數據。例如，“昨天晚上6點，系統內存利用較低”，這是定性的觀測。這在問題處理中的作用不大。關于該例子的定量的版本應該要收集并保存那些所有的輸出的數據命令，以及其他一些相關的診斷命令。目的就是在于收集足夠的數據，這樣就可以盡可能的避免問題的再次發生;這就是“一次到位式”的方法，而不需要問題重復出現后，多次收集才能夠得到比較完整的數據。