本篇內(nèi)容介紹了“怎么提高Debug效率”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

成都創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),嘉興企業(yè)網(wǎng)站建設(shè),嘉興品牌網(wǎng)站建設(shè),網(wǎng)站定制,嘉興網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營(yíng)銷,網(wǎng)絡(luò)優(yōu)化,嘉興網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭(zhēng)力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶成長(zhǎng)自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。

縮小問題范圍

縮小問題范圍的方式有很多，本質(zhì)上其實(shí)是從當(dāng)時(shí)的環(huán)境中找到與問題更高相關(guān)的變量。最常見的變量主要在以下這些：

• 運(yùn)行環(huán)境

• 所操作的數(shù)據(jù)

• 瀏覽器

• 對(duì)應(yīng)的源碼版本

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

提煉并優(yōu)化每一類bug的標(biāo)準(zhǔn)處理流程

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

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

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 輸出與預(yù)期不符

3. 程序報(bào)錯(cuò)

4. 程序明顯響應(yīng)慢

5. 程序crash

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

01 輸出與預(yù)期不符

這種bug最頭疼，為什么呢?因?yàn)樗幌衲欠N異常、報(bào)錯(cuò)的bug，有堆棧信息，可以快速縮小排查范圍，甚至直接定位到產(chǎn)生的地方。

那么怎么辦呢?如果這個(gè)問題在測(cè)試環(huán)境，那么最簡(jiǎn)單，直接單步調(diào)試走起，這個(gè)時(shí)候如果對(duì)IDE的調(diào)試工具掌握得越深入，效率也會(huì)越高，比如條件變量、多線程調(diào)試等等。

這里多說一句，強(qiáng)烈建議每個(gè)人掌握自己所用IDE的條件變量和多線程調(diào)試這兩種方法，在當(dāng)前的大環(huán)境下，整個(gè)軟件開發(fā)領(lǐng)域的大型項(xiàng)目和多線程運(yùn)用都比幾年前高得多。

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

02 程序報(bào)錯(cuò)

這種bug對(duì)有些經(jīng)驗(yàn)的程序員來說是最簡(jiǎn)單了，因?yàn)橹苯痈嬖V了你產(chǎn)生異常的代碼位置。

但是對(duì)新手就不同了，很多新手會(huì)拿著描述異常的一堆文字去搜索引擎搜，比如(NullPointer  Exception)，搜出來N多文章，一篇一篇看下來并嘗試都發(fā)現(xiàn)不能解決自己的問題，其實(shí)就是由于自己還沒習(xí)慣于去看堆棧信息。因?yàn)閯e人的NullPointer  Exception和你的NullPointer Exception產(chǎn)生的原因并不一樣。

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

不過值得提醒的是，在日常編寫的代碼的時(shí)候，千萬不能隨意的try catch代碼塊，然后throw一個(gè)new  exception，因?yàn)檫@會(huì)導(dǎo)致堆棧信息不完整。

03 程序明顯響應(yīng)慢

這種問題一般是在產(chǎn)生資源競(jìng)爭(zhēng)，或者資源緊張的時(shí)候發(fā)生。排查他們的難度也比較高。

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

不過不要緊，我建議你以后遇到這種情況，優(yōu)先從以下這幾個(gè)指標(biāo)入手。

• TCP連接數(shù)

• 內(nèi)存占用率

• 線程數(shù)

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

大多數(shù)情況下，TCP連接相關(guān)的問題主要就是兩個(gè)：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 連接使用完后未及時(shí)釋放

3. 針對(duì)高頻調(diào)用未使用長(zhǎng)鏈接，而使用了短鏈接。此時(shí)一旦下游服務(wù)響應(yīng)慢就會(huì)快速打滿65535個(gè)連接。

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

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 某個(gè)大對(duì)象應(yīng)該是共享使用的，在代碼里不小心寫成了每一個(gè)實(shí)例各自一份。

3. 某個(gè)對(duì)象分配的時(shí)候不小心帶上了static關(guān)鍵字，導(dǎo)致GC一直無法回收為其分配的內(nèi)存。

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

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

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

04 程序crash

導(dǎo)致crash的主要原因有兩點(diǎn)。

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 是由于前面提到的原因3未及時(shí)察覺，導(dǎo)致程序運(yùn)行直到資源耗盡，由操作系統(tǒng)干預(yù)強(qiáng)行終止運(yùn)行。

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

第一點(diǎn)參照原因3的處理方式。

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

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

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

“怎么提高Debug效率”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！