軟件崩潰了,該如何解決？
解決問題講究的是對症下葯。軟件崩潰，也同樣如此。我們需要找到崩潰的原因。對於軟件崩潰，我們如何去定位問題，這就是你今天問的問題。
中醫的望聞問切，是很有用的。對於軟件的問題的調查和分析，同樣也可以望聞問切。
一、望
望，就是觀察現象。所謂觀察現象，就是觀其的運行的情況。軟件是如何運行起來的，又是如何崩潰的，崩潰的提示是什么。這些是很表面的崩潰現象，可以很直觀的看到。這個層面，我們只需要觀察到基本的運行的現象，搜集相關的描述。當然，也不是簡單看着崩潰一次就完事的。我們至少要了解這些情況：操作系統、運行權限、軟件的操作流程、崩潰的錯誤提示，崩潰的現象等。這些情況看似很簡單，但是卻給定位錯誤提供了最基礎的根據。
除了很有經驗的人，或者對自己的軟件了如指掌的人，通過望就可能知道問題所在。因為軟件之前會出現這些問題，所以就可以直接找到問題所在。而對於一般的水平的人，或者軟件確實很復雜，那么就很難做到一看就知病因的地步。這個也很正常。這一步就是搜集基本的直觀的錯誤信息，這樣就可以了。
這一步也不能完全是看一遍就了事的。最終有沒有解決，還是要通過這一步來觀察，至少要從表面上消除症狀。如果所有症狀都和找到的問題一一對應，解釋的合情合理，解決后症狀就消失了，還原症狀又出來了，這樣就確定是真的找到問題，至少在症狀上是真的找到問題了。
另外，很多時候，不是一遍就行，還需要反反復復的讓軟件死來死去，從這個過程中觀察規律。這也是搜集現象的一種手段。單次的運行只有一次現象，當大量的現象匯聚就形成了一個規律性現象，此時可能更能表現出問題。舉個例子，一個產生隨機數的程序，一次兩次可能只是覺得隨機數始終不大於10，你以為這是正常的。但是通過大量的試驗，結果一直都不大於10，而你當初設定的范圍是0-100，如此來看，就很可能有問題。然后再通過這個現象分析出來，根據統計學的概率論，一直小於10肯定不正常。如果你只是測試幾次，這個問題是很難查出來的。這就是規律性問題。
二、聞
聞，就是聽聲息。所謂聽聲息，就是因為直接看是看不出來的。所以需要進一步的去找症狀。注意，這里還是在找症狀。只不過是找的更加深入一點。聲息不是表面的氣色，是看不見的。在軟件上，我們對應到內存、CPU、磁盤等的操作情況。很多復雜的問題，往往不是表面現象能看得出來的。此時我們需要聽其聲息。毫不誇張的說，我們甚至有時候會去聽聲音哦，比如聽硬盤轉動的聲音，聽風扇的聲音等等。硬盤轉速的變化，可能是由於程序異常的讀寫導致轉速不規律，或者陷入死循環的讀寫磁盤，都會導致硬盤瘋狂旋轉。當然，這里說的是機械硬盤。如果是固態呢，我們可以感受溫度。而風扇的瘋狂則有可能是陷入死循環，導致CPU長期執行高運算量的計算而發熱很大，風扇自然轉速加快以散熱。
舉這些例子並不是說讓你去這么做，當然有時候確實需要這樣做。特別是做硬件開發，那太常見了。比如要聞一下電路板是否燒焦了。更多時候，軟件問題很少會涉及到以上的那些操作。
我們這里說的聞，更多指的是深入一層次的觀察現象。因為表面的現象已經無法分析出問題。我們一般會從內存的事情情況、CPU的使用情況、硬盤的讀寫方面着手觀察。通過CPU的使用率，可能分析出死循環、死遞歸等。而硬盤讀寫可以分析出文件的讀寫卡死問題。內存的問題則有很多的內存占用，以至於導致系統內存陷入無可用內存狀態，最后甚至導致整個系統掛掉，這個我曾經就遇到並解決過。
那么具體如何看，最簡單的工具就是，任務管理器。當然還有很多逼格很高的工具，可以分析進程線程、動態庫、鎖等更高級的東西。比如有的工具可能分析的出來死鎖問題而導致的軟件被系統殺死。那么分析的深度如何，就看個人的知識水平如何了。如果你連進程是什么都不知道，就不要想着能夠操作這些高級的工具了。而這些分析的過程，還是需要自己去多實踐多總結。沒有一個治百病的經驗，只有實踐才是最好的工具。
三、問
問，就是詢問症狀。如果你的軟件給用戶使用，可能你前面兩步搜集到的信息確實有限，即使用戶錄屏了，依然還是滿足不了的話，那么你就需要去詢問情況了。
詢問是很有必要的。同時也要注意一個地方，那就是先從最白痴最基礎的地方問起。比如用戶沒有網，然后啟動你的程序，你的程序沒有考慮這個問題，然后就直接認為是有網，然后掛了，拋了網絡異常。而你對此是沒有預先考慮到的，所以出錯了。如果你先不問用戶電腦聯網情況，就是問一大堆，可能都找不到問題所在。這也可能是因為你本身對於聯網這個事情也不清楚導致的。
詢問用戶是彌補你不能直接搜集問題現象。當然了，詢問用戶不是我們這里要說的重點。我們詢問的應該是計算機。你是不是覺得詢問計算機是非常神奇的事情。計算機又不能說話。這就是人機交流，而且是程序員必備的技能哦。
所謂詢問計算機，其實就是要主動去與計算機交流，看看計算機能夠給你提供多少信息。只要你足夠厲害，你問什么計算機都會給你什么信息。說的直白點，也就是做條件測試。這是一種主動性的現象觀察。通過對不同情況的模擬測試，獲得對應的信息，然后再反過來分析現象。這個在望的基礎上走的更遠。往往很多軟件的問題的定位都是通過問計算機得以解決的。
用到的手段如：控制台命令測試、系統設置的切換、切換不同的操作系統運行、使用不同的權限運行、模擬不同的操作方式、使用不同的用戶張號等等。方法很多，不一而足。更多是結合自己軟件的特性來做針對性的測試觀察。
四、切
切，就是把脈。通過以上的深度調查，必然能夠搜集到大量的信息，如果還不能確診，那么就要繼續深入。最后一道就是把脈。把脈的是代碼。我們通過現象，定位代碼的大致范圍，然后仔細分析代碼的流程，然后進行大量的測試，去對照現象進行分析，或者臨時修改代碼進行測試性運行，慢慢縮小問題的范圍，最后定位問題。
代碼是程序的脈，代碼是程序的靈魂。在代碼中調試錯誤的工具和方法，相信各個IDE提供了強有力的工具。我就不說了。我們要用好手中的每一個調試工具，讓自己更多了解程序的運行情況。
那么最后說一下如何提高解決效率。
1.搜集充足的現象
沒有足夠的現象，是很難定位問題的，問題越精確，也就能越快定位問題。問題現象了解的越多，就越能准確定位問題所在地。如果現象太少，目標就太泛，這樣解決效率自然很低。如何搜集問題，在前面已經詳細講述了。
2.保持足夠冷靜的思維
思維的冷靜是非常重要的。遇到的問題越緊急，越需要冷靜的思維。思維的冷靜不代表你不着急，只有冷靜的思維，才能在眾多的現象中找到蛛絲馬跡。
3.發散思維，打破思維僵局
思維僵局，往往是找問題最大的天敵。如果在一個問題上，始終都不得其解，記住，要及時退出這樣的狀態。你可以先放下問題，走兩步，或喝喝茶。換一個方向思考分析問題，往往是非常有用的。
4.細心分析現象和代碼流程
在大量錯誤涌來的時候，細心很重要。我們要細心對待每一個問題，然后再認真的分析代碼的流程。很多問題可能是並發症，解決了源頭問題就可以解決所有問題。只有通過各種下問題，逐步追根溯源，慢慢找到最源頭，然后從源頭上解決。
那么這四點，加上前面的搜集和調查問題的方法，應該是非常高效的解決辦法了。看似簡單，卻不簡單。而每一步都需要大量的實踐，在長期的實踐中積累到足夠的經驗和技巧，才能快速的解決各種疑難雜症，沒有捷徑可走。
如果你想更好的提升你的編程能力，學好C語言C++編程！彎道超車，快人一步！
【C語言C++學習企鵝圈子】，分享（源碼、項目實戰視頻、項目筆記，基礎入門教程）
歡迎轉行和學習編程的伙伴，利用更多的資料學習成長比自己琢磨更快哦！
編程學習書籍：
編程學習視頻：
