調查的bug的手段有哪些？

一、打log，看日誌

代碼log的重要性和代碼自己是同樣的。在關鍵的邏輯和判斷條件處添加日誌，最好作到即便不作debug也能夠了解代碼運行邏輯。若是不知道哪些地方應加日誌，簡單的方式就是全部的自定義函數的入口和出口都添加上日誌。可使用切面編程或者代理，本身封裝一個log的框架，利用切面或代理操做就會簡單不少，對原始的代碼入侵也小。

日誌中不只要有流程的標記，還有有狀態信息，好比：時間、線程號或用戶id、關鍵的參數信息。能說明誰在什麼時間什麼條件下作了一件什麼事情，把這個事情說清楚就行。

這樣的日誌量可能會很大，日誌的分級處理也很重要，trace、debug、info、warn、error等信息分別表示。error信息中除了異常時的運行棧信息，還須要有一些關鍵的內存參數信息，好比當前方法的參數或者邏輯的關鍵條件等。

二、用戶訪談

要不要作用戶訪談？打電話仍是與用戶見面？這個要看工程師的我的溝通能力。有的人和用戶溝通親切且專業，溝通能力強，有說話的技巧，用戶不反感，那就能夠作用戶訪談，和用戶瞭解清楚當時發生問題，作了什麼操做。不少奇怪的問題都是和特定的操做環境甚至操做流程有關係，作用戶訪談要問清楚的幾件事：

1. 當時的操做環境，系統，運行環境
2. 網絡環境，若是是網絡問題，和用戶溝通一下能不能接入他們網絡復現問題
3. 當時的操做過程，操做順序
4. 一些特殊的操做習慣

記下基本的信息，最好用腦子記，當時不要打字或用寫下來，這樣會給用戶壓迫感，感受太正式了，說的內容就會本身提早處理一下。不少操做的細節就是在無心中提到的，因此訪談的時候能夠適當隨意些，可是注意聆聽，若是有細節感受有點不太同樣，先記在內心，不要打斷用戶，讓他順暢的說完，再提問。

三、代碼review，畫流程圖

梳理清楚代碼邏輯，多看幾遍代碼，一邊看代碼，一邊和需求/邏輯對比，發現異常的地方。若是邏輯比較複雜，層次比較深，看一遍記不住全部邏輯，那最好畫出流程圖，邏輯梳理找到漏洞或可疑點。運氣很差，還要增長log，測試調試。

四、用google

這個成本最低，能夠先作。把問題、異常信息貼到google裏面，先看看其餘人遇到相似的狀況了嗎？60%的問題這種方式就能解決。

五、用工具分析運行狀態

若是能夠復現問題了，就可使用一些內存分析工具，檢查發生問題的狀態。不一樣技術都有內存分析工具，jmap, jstack等等，多多利用，學習怎麼使用這樣工具會讓解決問題效率提高不少。

六、評估危害

沒有不存在bug的程序，評估bug的危害和解決成本就很重要。
有沒有直接影響到了用戶體驗，影響到支付流程，影響到了生命安全，影響到用戶比例有多少。

有的問題頻率雖然不高，可是很致命；有到雖然不會傷害生命，可是規模大；有的規模不大，也不致命，但用戶發生一次就被勸退了。這些都很嚴重。

危害的評估，主要是三個方面：規模頻率、嚴重程度、危害是否可逆。