怎么提高Debug效率

本篇內容介紹了“怎么提高Debug效率”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

縮小問題范圍

縮小問題范圍的方式有很多，本質上其實是從當時的環境中找到與問題更高相關的變量。最常見的變量主要在以下這些：

• 運行環境

• 所操作的數據

• 瀏覽器

• 對應的源碼版本

建議你先從這幾個變量進行驗證。然后再弄清楚上一次正常操作與當前出現bug的操作之間的這段時間發生過什么。大多數情況下，問題的根源就藏在這里面。那種潛藏很久才遇到的疑難問題，畢竟是少數。

提煉并優化每一類bug的標準處理流程

工作中很多流程需要SOP，在修復bug這件事上也可以這么做，如此可以將每一次修復一個疑難bug的過程給沉淀下來。

常見的bug類型主要有4類：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 輸出與預期不符

3. 程序報錯

4. 程序明顯響應慢

5. 程序crash

每一類都有適合它們的排查方式，如果你總是用同一個套路去排查這4類問題，效率自然不會太高。

01 輸出與預期不符

這種bug最頭疼，為什么呢?因為它不像那種異常、報錯的bug，有堆棧信息，可以快速縮小排查范圍，甚至直接定位到產生的地方。

那么怎么辦呢?如果這個問題在測試環境，那么最簡單，直接單步調試走起，這個時候如果對IDE的調試工具掌握得越深入，效率也會越高，比如條件變量、多線程調試等等。

這里多說一句，強烈建議每個人掌握自己所用IDE的條件變量和多線程調試這兩種方法，在當前的大環境下，整個軟件開發領域的大型項目和多線程運用都比幾年前高得多。

如果沒法單步調試的情況，那么只能通過多打一些日志，來達到接近單步調試的效果。不過這點需要你做一些預判，在一些代碼分支、可疑位置打上日志即可，畢竟編寫記錄日志的代碼也需要時間不是。

02 程序報錯

這種bug對有些經驗的程序員來說是最簡單了，因為直接告訴了你產生異常的代碼位置。

但是對新手就不同了，很多新手會拿著描述異常的一堆文字去搜索引擎搜，比如(NullPointer  Exception)，搜出來N多文章，一篇一篇看下來并嘗試都發現不能解決自己的問題，其實就是由于自己還沒習慣于去看堆棧信息。因為別人的NullPointer  Exception和你的NullPointer Exception產生的原因并不一樣。

堆棧信息中記錄了整個調用鏈路，所以通過這里你可以看到完整的方法調用順序。

不過值得提醒的是，在日常編寫的代碼的時候，千萬不能隨意的try catch代碼塊，然后throw一個new  exception，因為這會導致堆棧信息不完整。

03 程序明顯響應慢

這種問題一般是在產生資源競爭，或者資源緊張的時候發生。排查他們的難度也比較高。

如果說前面兩類問題中，高水平和低水平的區別只在于解決效率的高低上，那么這個問題對低水平的程序員們來說可能是不管花多少時間都找不到問題的原因。

不過不要緊，我建議你以后遇到這種情況，優先從以下這幾個指標入手。

• TCP連接數

• 內存占用率

• 線程數

對于TCP連接，你身邊得常備一份netstat命令手冊，然后敲入命令，分別查看連接數是否接近到了65535?TIME_WAIT、CLOSE_WAIT狀態的連接是不是過多?

大多數情況下，TCP連接相關的問題主要就是兩個：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 連接使用完后未及時釋放

3. 針對高頻調用未使用長鏈接，而使用了短鏈接。此時一旦下游服務響應慢就會快速打滿65535個連接。

對內存問題的分析，主要是就是通過分析GC來進行，主要關注是否有什么類型的對象占用內存過大了。如果存在過大的情況，主要原因是以下兩個：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 某個大對象應該是共享使用的，在代碼里不小心寫成了每一個實例各自一份。

3. 某個對象分配的時候不小心帶上了static關鍵字，導致GC一直無法回收為其分配的內存。

不同的編程語音有不同的GC分析工具，需要熟練掌握。

對線程的分析，和TCP連接類似，主要集中在線程的數量和狀態上。線程并不是數量越多、性能就越好。數量越多，可能花在線程之間的上下文切換上的時候就比實際執行代碼邏輯還要多。

另外，是不是有大量線程blocked或者deadlocked了?隨便挑其中一個線程，分析其當前的堆棧信息，就是問題所在。

04 程序crash

導致crash的主要原因有兩點。

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 是由于前面提到的原因3未及時察覺，導致程序運行直到資源耗盡，由操作系統干預強行終止運行。

3. 代碼中存在未捕獲的exception。

第一點參照原因3的處理方式。

第二點就很簡單了，在代碼的最外層做一個大大的try  catch，然后打上日志將堆棧信息記錄下來，發布到線上，自然就能看到是那里出現的問題，然后轉到原因2的處理方式。

最后，提高Debug能力必須要多實踐。所以，我是非常建議你在條件允許的情況下，勇敢地去挑起排查線上疑難雜癥的任務，甚至并不是你直接負責的功能模塊。

可能在外人看來你在幫別人“擦屁股”，但這會讓你的Debug能力得到明顯的提升，并且容易形成對你的依賴，讓你越來越強。

“怎么提高Debug效率”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！