七年經驗的程序員寫的程序CPU飆到99%，竟然還在用笨辦法查原因！

公司一個程序員寫的程序崩了，一查原因才發現原來程序在運行一段時間以后，電腦的CPU竟然飆到了99%，然后就直接卡死了，幸運的是，這種情況是100%可以復現的，我懷疑他代碼里面寫了“死循環”，然后就讓他通過IDE去監控CPU過高的地方，結果他監控的方式卻讓我有點驚訝，只見他打開了他認為可能會出現死循環的地方，在那下斷點，研究起代碼來……

我之所以驚訝，那是因為這個程序員已經有七年的軟件開發經驗了，想不到連監控CPU負載都不會，還是選擇使用傳統的下斷點監控的方式，雖然說這種方式一定程度上是能發現問題，可是，如果是這個“死循環”藏得比較深，那你就調吧，估計調半天都查不出原因。

于是我就問他：“你不會監控CPU？”

然后他就好奇得問：“怎么監控？”

然后，我就告訴他，現在他寫的程序是100%可以復現這個“死循環”的，那么只要使用IDE運行起這個軟件，然后就可以在IDE里面查看軟件運行時哪些代碼被頻繁執行以及大部分占用CPU過高的代碼，如圖所示：

當然了，如果發現程序占用內存過高，也可以通過監視程序調用情況，查看哪些代碼在執行時頻繁調用內存或者占用內存過高的情況，如圖所示：

以Visual Studio為例，Visual Studio中有個叫做“診斷工具”的工具，可以實時顯示CPU和內存的使用情況，遇到CPU和內存使用過高的情況時，我們可以在“診斷工具”里面自己查看CPU和內存到底是被哪些代碼所影響，然后我們就可以通過修改代碼邏輯來減少CPU和內存使用過高的情況了！

當然了，不是所有CPU和內存使用過高都可以通過修改代碼去解決，比如當我們需要調用一張像素比較大的圖片的時候，因為需要處理圖片，因此圖片是緩存在內存當中的，圖片越大，占用的內存越高，此時單純得通過修改代碼其實很難優化內存占用問題。

這時候，如果增加“虛擬內存”還解決不了問題，代碼優化又會讓代碼看起來晦澀難懂，這時候最簡單粗暴的方法就是增加物理內存了！

但無論怎么說，只要是代碼問題導致的CPU和內存增加，都可以通過監控CPU和內存的方式去查找原因，根據原因去想不同的對策！

我這么一說，同事豁然開朗，他說他干了七年程序員，知道Visual Studio里面有“診斷工具”這個東西，但是具體怎么用，他還從來沒有關心過，這下算是清楚了，以后再去查找CPU和內存升高的問題就再也不用以前下斷點調試這個笨辦法了！

其實，驚訝之余，我也理解為什么我的同事干了七年程序員連這點東西都不會，因為這些事情我見得比較多了。

比如我見過一個五年工作經驗的程序員不會封裝dll文件，當時我是蠻驚訝的，后來才知道他以前做的項目都是寫在一個包里面的，只知道如何調用dll，但是從來沒有封裝過dll給別人用過。

我也見過很多程序員使用強類型去聲明變量的，不是說這樣不可以，只是現在大部分編程語言使用弱類型去聲明變量已經被大部分程序員所習慣了，所以，遇到使用強類型去聲明變量的，對于我來說，看起來是比較新鮮的！

究其原因，有的是真不知道可以用弱類型來聲明變量，這和他們使用的IDE也有關系，比如說我就遇到過不少還在使用Visual Studio2008或者Visual Studio2012的，Visual Studio2012我忘了是否可以使用弱類型來聲明變量了，但是Visual Studio2008是肯定不可以的！

結語

我最近和一個年近50的程序員聊天的時候就正好聊到了這些問題，他的想法就是代碼越簡單越好，現成的框架他能不用就不用，這是他的邏輯，而且，他也不是說排斥去用框架，而是框架對他來說算是個新鮮玩意了，過去寫代碼哪有那么多東西。

通過這兩個例子，我其實想說的就是一個人對于代碼、對于IDE的使用，其實是受過去的工作所影響的，有些你我認為很常見的操作，他們如果一直沒接觸，又不是太喜歡去研究，那不知道也就不算奇怪了！