ｌｉｎｕｘ系統(tǒng)的穩(wěn)定性記錄成為很多評(píng)論家們反對(duì)沖突不斷的ｗｉｎｄｏｗｓ系統(tǒng)的一個(gè)很好的武器。然而，ｌｉｎｕｘ系統(tǒng)的沖突問題雖然比較少，但是一旦在意想不到的情況下出現(xiàn)，也很容易使人們陷入困境。學(xué)習(xí)一些常用手段來預(yù)防這些這些沖突問題的發(fā)生是十分重要的，它可以幫助ｌｉｎｕｘ的系統(tǒng)管理員們避免那些困境情況的出現(xiàn)?！　∫话阏J(rèn)為，ｌｉｎｕｘ服務(wù)器系統(tǒng)是不存在沖突的，然而些許時(shí)候該系統(tǒng)的沖突、停滯問題的確存在。對(duì)于應(yīng)用軟件層面的沖突或者停滯問題，與內(nèi)核層面有何不同呢？　?。恚幔颍搿。鳎椋欤洌椋睿纾骸?yīng)用軟件層面的沖突或者停滯問題只是限制于一個(gè)特定的線程或者進(jìn)程。這種沖突或者停滯問題不會(huì)導(dǎo)致在該相同系統(tǒng)上運(yùn)行的其他線程或者進(jìn)程的沖突或者停滯。然而，如果是在內(nèi)核層面上發(fā)生，那么它將影響到該系統(tǒng)中運(yùn)行的所有進(jìn)程?！　∠到y(tǒng)的沖突和停滯，這二者有什么區(qū)別呢？　　ｄａｎ?。猓澹瑁恚幔睿骸≡谌魏我粋€(gè)層面，沖突和停滯這二者的屬性基本上是相同的。停滯發(fā)生在進(jìn)程或線程受阻的時(shí)候，此時(shí)是由于某種鎖定或者某些硬件資源的繁忙，從而該進(jìn)程或線程不得不等待。等待某些鎖定或資源的情況是經(jīng)常發(fā)生的，但是只有當(dāng)這種鎖定或者資源最終無法實(shí)現(xiàn)的時(shí)候，才會(huì)引起系統(tǒng)停滯?！　∵€有很重要的一點(diǎn)需要注意的是，停滯問題有時(shí)候可以提早的診斷出來。我的意思是，例如，某種資源的某個(gè)特定的時(shí)刻非常的繁忙，這是需要這種資源的進(jìn)程或線程就需要等待非常長(zhǎng)的一段時(shí)間，直至該資源空閑下來。用戶經(jīng)常不了解資源的這種繁忙狀況，而只看到該進(jìn)程在等待，所以他就認(rèn)為系統(tǒng)發(fā)生了停滯，但實(shí)際上此時(shí)系統(tǒng)仍然在按照既定的工作流程進(jìn)行，只是速度比較慢?！　《到y(tǒng)的沖突問題與上述的停滯是不同的，它主要是由于某種不可知的硬件或軟件錯(cuò)誤而導(dǎo)致的。當(dāng)這種錯(cuò)誤發(fā)生時(shí)，特殊的錯(cuò)誤處理程序?qū)⒑芸赡軙?huì)調(diào)用那些診斷信息及報(bào)告，從而有希望能夠追蹤到這種錯(cuò)誤的原因?！　_突問題可以看作是某種致命的問題，它需要完結(jié)后才能夠進(jìn)行分析。而停滯問題可以看作是實(shí)時(shí)的問題，它可以即時(shí)的進(jìn)行分析、解決?！　∥抑溃欤椋睿酰幸粋€(gè)最大的優(yōu)勢(shì)就是在于它的源代碼的開放性；除此之外，還有別的原因致使ｌｉｎｕｘ比其他操作系統(tǒng)的沖突問題容易解決嗎？　?。猓澹瑁恚幔睿骸“殡S著這種源代碼的開放性，在ｌｉｎｕｘ系統(tǒng)的每一個(gè)層面都有著相當(dāng)多的參閱文件。同時(shí)，既然源代碼是開放的，那么它的開發(fā)團(tuán)隊(duì)也同樣是開放的。這樣以來，你就可以把所遇到的問題向ｌｉｎｕｘ內(nèi)核的開發(fā)者求助，當(dāng)然包括最初的那些開發(fā)人員，甚至ｌｉｎｕｓ　ｔｏｒｖａｌｄｓ本人，而這所有的求助程序也僅僅是發(fā)送一封電子郵件就可以了。而據(jù)我所知，ｌｉｎｕｘ的這種能力是那些不開放源碼的操作系統(tǒng)所缺少的?！　√幚硗栴}有那些困難和挑戰(zhàn)呢？　　ｗｉｌｄｉｎｇ：　一個(gè)應(yīng)用軟件的停滯問題是有著多種原因的，也包括那些可能由于內(nèi)核空間的問題所引起的停滯。這意味著有時(shí)候這些問題不是開發(fā)者所能夠控制的。但是這正是ｌｉｎｕｘ的優(yōu)勢(shì)所在。所有的源代碼都是開放的，所以如果你遇到了某種進(jìn)程的內(nèi)核阻滯狀況，那么就可以聯(lián)系其源代碼，從而查看該進(jìn)程在內(nèi)核中是如何作用的。然而，在大部分情況下，是沒有必要進(jìn)行這么深層次研究的。為了探究進(jìn)程停滯的原因到底何在？應(yīng)用軟件的開發(fā)者需要認(rèn)真的研究這些軟件層面的狀況及證據(jù)（例如，堆棧的路徑等）?！　?duì)于用戶或者維護(hù)人員而言，他們一般不會(huì)了解應(yīng)用軟件的具體工作程序，也不會(huì)沒有能力進(jìn)入到源代碼層面進(jìn)行測(cè)試，這是遇到系統(tǒng)停滯問題可以靈活的進(jìn)行處理。例如，在某種情況下，進(jìn)程ａ在等待進(jìn)程ｂ結(jié)束后所釋放的資源，而進(jìn)程ｂ又在等待進(jìn)程ａ占有的資源。這就是所謂的“死鎖”，這也正是復(fù)雜應(yīng)用軟件中經(jīng)常出現(xiàn)的問題，可以作為停滯問題的一種診斷方案?！　∪绻悴磺宄M(jìn)程ａ及進(jìn)程ｂ的具體等待原因，那么你甚至不需要明白這到底是不是“死鎖”的情況，而別無選擇的關(guān)掉這兩個(gè)進(jìn)程后重新開啟。正是這種類似情況，因此對(duì)于應(yīng)用軟件而言，進(jìn)行完全的資源及上鎖情況的跟蹤是十分重要的，這可以幫助解決這種比較棘手的問題?！　。猓澹瑁恚幔睿骸￡P(guān)于停滯問題的另一個(gè)挑戰(zhàn)在于，當(dāng)停滯問題發(fā)生時(shí)，進(jìn)程或者線程經(jīng)常不知道它被停滯了或者何時(shí)將被停滯。這種情況和沖突問題是不同的，當(dāng)沖突問題發(fā)生時(shí)，進(jìn)程可以截取大部分的信號(hào)，并且信號(hào)處理程序可以添加到平臺(tái)系統(tǒng)中來處理這些特殊情況，例如清理內(nèi)存，堆棧跟蹤等等。但是，當(dāng)停滯問題發(fā)生時(shí)，這種特殊的處理程序雖然不是完全不可能進(jìn)行，但是往往比較靈活，不太固定?！　⊥栴}發(fā)生時(shí)，往往去重新啟動(dòng)該系統(tǒng)或者應(yīng)用軟件。有一點(diǎn)需要切記的是，發(fā)生停滯問題時(shí)，診斷該問題的一些資料和證據(jù)經(jīng)常被活動(dòng)的內(nèi)核及應(yīng)用軟件所捕獲。如