在開發、測試、線上運行的過程中，程序難免會出現問題，如果快速地定位程序的問題，是每個程序員的必修課。

01.日志是基礎

當程序報錯，最簡單且快速的方法就是查詢日志中的報錯信息了；所以我們在敲代碼的時候，一定不能對CheckedException只捕捉不處理。

• 首先不要忽略異常，第一可以在捕捉到異常后將日志信息輸出，要么通過Throw或throws向上拋，讓上層的代碼進行處理；

• 接上，不要捕捉異常后，輸出完日志又向上拋出異常，這樣當查詢定位錯誤時，會產生誤導；

• 對于捕捉到的異常，最好可以精確地指出具體是什么異常，而不要用catch(Exceptione)替代；

• 如果選擇了輸出異常，那么就要把異常單獨打印到一個日志文件中，否則你很可能需要在一大堆日志文件中翻閱查找；

• 另外，日志信息盡可能的詳細，比如方法的入參、與其他系統交互的報文等等。

如果你能在日志文件中快速的找到報錯信息的話，那么再定位錯誤程序就容易很多：

1. 通常異常輸出能看到報錯的類、方法、甚至代碼行數，可以先檢查程序是不是有顯而易見的錯誤；

2. 如果是開發測試環境，可以通過IDE進行代碼調試，如果錯誤每次都可以復現，那就是一個明顯的BUG，如果是部分數據有問題，那么就要分析是程序不嚴謹，還是數據有問題；

3. 如果是生成環境的話，我們很難進行線上調試，那么只能通過日志來進行具體的分析了，條件允許的話，可以把生產環境的數據拿下來進行檢查和調試。

02.完善的監控

很多程序員會說，我的日志都很完善了，還需要監控么？我建議最好是有的，而且監控越完善越好。

• 首先，通過日志查詢問題，通常都是業務人員或用戶在操作過程中遇到問題，找到運維和開發之后，我們再去翻日志；如果有監控的話，可以實時地發現問題，提前解決問題。

• 第二，現在很多項目都不是單臺部署，應用部署個幾臺、幾十臺甚至幾百臺都很常見，當發現問題之后，人肉翻日志已經不太現實了，如果有一個日志平臺的話，那就會方便很多。

• 第三，很多公司的項目都是分布式架構、微服務架構，越來越多的服務都是鏈路調用，A系統調B系統，B系統再調C系統和D系統，這種情況下翻一個服務的訪問鏈路，就需要從幾個系統上拿日志，人肉運維是很費時費力的。

03.OOM、CPU占用率高等異常分析

上面說到的各種錯誤，基本上是有明確的代碼問題，不管是代碼本身的問題，還是數據的問題導致代碼報錯，另外一種不是“顯性”的異常（最終可能依然是代碼的問題），比如內存使用過高、CPU使用過高、頻繁FullGC、OOM等等，通常這一類的問題不好重現、定位困難。

• 如果有報錯信息，首先還是要查找關鍵報錯信息，比如java.lang.OutOfMemoryError:Javaheapspace，很明顯就是堆溢出；

• 這時候你需要知道堆里面存的是什么，這樣有助于你進行問題的排查：Java堆用于存儲對象實例，如果有大量的對象無法被垃圾回收機制清除，那么超過堆容量限制之后，就會發生溢出；

• 我們可以使用內存映像分析工具，對堆儲存快照進行分析；如果有內存泄漏，可以通過工具查看泄漏對象；如果不存在泄漏的話，可以檢查代碼中是否有遞歸、死循環等等。