如何提高debug的能力，看日誌分析錯誤原因的能力？

01-13

我覺得區分程序員的一個重要指標就是debug的能力，分析錯誤原因的能力，但是對如何提升這種能力感到很迷茫，靠經驗嗎？比如根據tomcat的日誌找到出錯的原因。我目前的水平只能對於一些java中常見的異常和錯誤能找到出錯的地方，但是如果項目特別大的話就會很凌亂，我知道自己很大的一部分原因是基礎不紮實，但我感到憂慮的是基礎紮實了也似乎很難找到一條可以提高這方面能力的道路，例子具體一點，我想根據tomcat的錯誤日誌找到代碼出錯的位置，如果我將《深入剖析tomcat》一書認真看完會有比較大的提升嗎？還是每次仔細閱讀錯誤日誌，再百度，找到解決方法，積累排錯經驗提升更快一些呢？

看log靠的是你對這個項目的代碼的熟悉程度，不是靠你的編程水平或者debug能力。

debug的能力是這樣練出來的：

熟悉業務
熟悉代碼
熟悉業務與代碼的映射關係
熟悉日誌系統，熟悉各個模塊都在哪些關鍵點列印了日誌
熟悉調試工具
重複上面的步驟，多多解Bug，培養感覺
重複上面的步驟，多多解Bug，培養感覺
重複上面的步驟，多多解Bug，培養感覺

多調試多總結。

不過我覺得解決bug更多在於對系統和語言底層的理解，去猜測可能踩了哪些坑。

日誌反而只是驗證的手段

贊同輪子哥，這種事情干多了，雖然工程師這個名頭，實際上一行代碼都寫不出。。。

離了kernel team，就是個屁...

我覺得我的工作初中生會看幾個英文就可以做了...

我覺得debug很輕鬆啊，讓我說原因也說不出個所以然，嘗試著總結幾點，希望對你有用。

一個是邏輯思維能力，一個是業務熟悉程度，一個是相信自己能解決BUG（很多人敗在這一步，都是中途放棄了），一個是嘗試從不同角度看問題

個人也做大框架維護，大量的各種日常bug，心得是必須熟悉整體框架，必須熟悉，必須熟悉，重要說三。

其次是熟練掌握各種調試技巧了，比如Ctrl+t之類，光看日誌不行，要熟悉堆棧調用。（想到再補充）

不熟悉代碼流程，你就是把log看一千次也沒用，不如安心看10次代碼，然後看10次log。

項目到了android系統階段，沒人會對全部代碼熟悉。切不說，高通底層代碼基線就變來變去，谷歌的升級，其他team無節操的提交，光是一個子系統的代碼量也夠看的了。但是遇到問題，第一辦法還是看log，看ramdump。這時候就需要經驗了。

經驗是什麼？我覺得有句話說得好，知識從來不會被真正忘記，它最終會進入你的意識深處，變成你用來判斷對錯的直覺。

經驗就是大數據經過多層神經網路後的結果啊！

排名最高前的回答沒有正面回答問題。最近幾天正在上百兆的Log裡面撈針，講幾個心得權當拋磚引玉。

比如說，你看到下面這段日誌：

13:09:30,330 [pool-1-t-1] INFO a.b.c.ReportService - Saving report 1 13:09:30,330 [btpool0-7] INFO a.b.c.ReportService - Saving report 2 13:09:40,129 [main] INFO a.b.c.ReportService - Saving report 3

如果你只看到了保存了三個報告是不夠的，特別是在出錯的情況下。除了message之外，你還有關註：

1. 誰記錄這條日誌

這是最基本的，你要看到哪個類（對應的是Logger的名字，不過一般大家都是用類名做Logger name的）報了這個錯誤。有了這個你就可以到代碼裡面去查具體打出這條日誌的代碼。

2. 什麼時候記錄了這條日誌

也就是這個事情發生的時間。看時間的時候要跟其他的記錄關聯起來，最好是放到日誌分析工具裡面（推薦ELK）。這種分析要回答的幾個常見問題是：

a. 什麼時候發生的這個問題，當時在運行什麼業務？

b. 發生這個問題的前後在做什麼？假設出錯的報告是report 2，你應當敏銳的意識到report 1和report 2是（幾乎）同時保存的。

c. 有沒有關聯的錯誤和警告？

d. 發生這個問題有沒有時間上的規律——比如每天早上固定某個時間附近？

3. 哪個線程記錄這條日誌

最容易被忽略的是是線程。如果你的產品是多線程數據處理，要看是不是錯誤總是發生在某個線程上面。我寫了一篇文章adfasdfasdf

一個常見的做法是過濾出一個線程的日誌，單獨分析。

我回答題主的最後一個問題.

我從來都是在myeclipse里跑tomcat,所以出錯的時候我回去點鏈接,直接跳轉的類的那一行.

有的是自己寫的,能看,有些是有源碼的.沒有的反編譯.

眼睛放亮點,1 Il 你分的出么?新手常犯的錯誤是:HelloWorld程序里把println里的那一豎打成數字1..

我在貼吧遇到過類的集合比類的名字加了個s,那貨從頭到尾沒看出來.代碼改的一塌糊塗.

多看一些規範和模板,這些基礎的不熟悉,有些錯誤你看不出來.

曾經見過jsp報錯,怎麼都找不出來.最後發現這位女學員又import一次:java.util.*

用好調試器，自從windbg熟練以後調試效率高太多了。

推薦一本書，調試九法，很多日常用的調試方法裡邊都清晰地描述出來了

1. 把英語學好

2. 用Google而不是百度

日常填坑工程師來回答一下。

比較贊同 @vczh 的觀點，日誌體現的問題大部分不屬於編碼能力範圍。

題主的觀點比較有問題，列印出來的異常大部分是業務異常，而不是tomcat本身的的異常，列印出來的異常堆棧最上部分是出錯誤的具體位置，可以通過這個位置找到代碼的位置，接下來起作用的就是你對代碼的熟悉程度。

而且，如果是底層容器拋出來的異常，大部分的容器的官方文檔都會說明，你即使看完了tomcat的源碼，你也不可能把所有的異常都記住。