抽象ID
很高興能回答這個問題：
定位分析錯誤能力是一個合格的Java程序員應該必須具備的能力；通俗來講Java程序出錯也分幾種類型：代碼自身編寫出錯，代碼邏輯出錯導致編譯出錯不能通過，程序運行時出錯，下面我們來講一下如何處理這些錯誤信息：
1.代碼編寫錯誤應該算比較好找出來的錯誤，主要是語法運用，框架使用配置，分層編寫邏輯與注入這幾個地方會出現錯誤一般現階段很多編寫代碼軟件都會自動提示出來排查晚上就可以了，也比較考驗程序員編寫代碼的功底，一個合格的程序猿一般很容易處理這些問題
2.代碼編譯錯誤指的是編寫未見錯誤但是編譯不通過，一般情況多數是由，一些依賴等一些配置文件未正常引入導致的，或者對一些路徑處理不妥當或者是持久層框架註解不當或缺失，對象初始化等很多問題造成，控制檯會對錯誤進行簡單定位自己去排查就可以了，錯誤種類比較多就不一一解釋
3.程序運行時異常範圍比較廣最基礎的就是代碼環境未配置妥當，缺少配置，多線程引入未處理妥當，程序設計不合理，對象重複自身調用造成宕機，堆棧異常，或者分佈式項目在運行時未配置好項目之間的互相依賴造成種種錯誤，這些異常處理起來比較麻煩需要根據日誌信息或者測試環境下debug模式按順序一一排查，最終解決錯誤
以上是我的拙見，代碼寫的越多一些設計運用得當，編寫功底紮實，這些錯誤也就出現的很少，或者能快速解決，謝謝！
回敬青春
本地最後還是debug調試下，生產環境就看日誌，根據不同的調用鏈，追蹤問題！
鍾淵影視
1 控制檯報錯的信息
通過查看控制檯報錯信息，將報錯內容翻譯出來（通過多次項目編碼的過程中，大部分報錯信息都差不多，可以記住一些常見的英文單詞，以便下次可以快速的定位問題），這樣基本上就可以將問題定位出來，這也是最好解決的狀況，也是表明你是菜鳥的重要體現（不過沒有關係，下次注意就好了，成長是需要一個過程的）。
2 使用debug定位+try catch捕獲異常信息
該方法主要是針對本地代碼可以啟動，頁面也可以正常顯示，某些功能不能正常實現的問題。首先確保項目是用debug起的，將具體的方法代碼找到，打上斷點，找到具體的報錯的地方，使用try-catch將異常信息打印出來，通過控制檯查看異常信息，定位問題。（該方法主要是適用於自己寫的需求代碼，也是開發過程中最常用的定位問題手段）
3 查看log日誌信息
這個手段也是我們在開發過程中常用的，我們可以通過查看log日誌看到具體報錯信息，用一個文本編輯器打開（我使用的是EditPlus），先將原來的日誌信息刪除，然後在重新點開頁面，使用EditPlus的話點擊重新載入就可以看到新的報日誌信息，將error的信息選中，定位error就好了。
4 使用xshell查看日誌信息
如果你們公司項目每個方法進出都記錄了操作日誌或者info日誌，你可以使用xshell查看錯誤信息，直接定位環境上的錯誤信息（線上項目）
總的一句話，主要我們在項目中經常性的總結，隨著接觸的項目需求越來越多，我們定位問題的速度也是越來越快的，記住：千里之行始於足下，堅持到最後的，才能夠笑到最後！
爪哇程序猿
定位錯誤最普遍的方式就是日誌分析，姑且不談是代碼的運行環境（生產、測試、本地）。
這個問題可以暫時理解為通過日誌定位錯誤有哪些技巧？
1、日誌分類一定要做，分類的維度有很多種，登錄型的，權限型的，業務型的，數據庫操作的等等。
2、打印日誌要完全，時間，類名，詳細的錯誤堆棧信息，還可以加上一些關鍵參數值，因為錯誤有時候不一定是崩潰日誌，也有可能是業務異常，這些關鍵參數值能給你分析業務帶來有效的指引。
3、對於分佈式系統可以考慮上ELK日誌分析系統。ELK日誌系統介紹：
ELK分別是Elasticsearch、Logstash、Kibana三個開源框架縮寫。
Elasticsearch：開源分佈式搜索引擎，提供存儲、分析、搜索功能。特點：分佈式、基於reasful風格、支持海量高併發的準實時搜索場景、穩定、可靠、快速、使用方便等。它可以接收蒐集的海量結構化日誌數據，並提供給kibana查詢分析
Logstash：開源日誌蒐集、分析、過濾框架，支持多種數據輸入輸出方式。用於收集日誌，對日誌進行過濾形成結構化數據，並轉發到elasticsearch中
Kibana：開源日誌報表系統，對elasticsearch以及logstash有良好的web頁面支持。
一個簡單的ELK應用架構圖：
圖來網，侵刪。
4、補充一點心得之談，出錯了以後靜下心來仔細思考為什麼出現錯誤，最好的解決和最快的解決方式都有什麼，主動給出方案建議利弊，會很出彩。
編程乾貨曬場
已經出錯了，那首要做的就是解決掉這個問題，至於定位錯誤的技巧，我覺得這個要根據你的情況來，是生產環境？測試環境？還是本地？
生產環境出錯
這種情況的報錯，一般都是在不經常犯錯的地方拋出了異常，因為既然是生產環境，那麼在程序使用前，一定是至少經過開發本地測試、測試人員驗證、正式上線三個步驟。這三個步驟以後，一般常規的錯誤肯定已經被解決了。那麼現在出錯的原因，多半就是一些極其特殊的情況，比如：客戶騷操作、機房網絡策略異常、時間日期跨度（有些bug只會出現在年頭或者年尾）。排查的方法首先就是看常規日誌有沒有明顯報錯，結合記錄的客戶操作類日誌，及數據庫數據更新日誌進行排查。
測試環境出錯
這種情況下出錯，相比生產環境要好很多，因為只是測試環境，不至於那麼緊張。解決這類問題，可以採用“順藤摸瓜”的方法，首先還原報錯產生的條件，什麼情況下會出錯誤，根據操作步驟，我們可以很快定位到出錯的代碼塊，仔細排查代碼邏輯，到底是哪裡有問題。測試環境出錯，在處理問題的時間上相比正式環境，是很有優勢的，加上可以還原，所以處理問題也更容易。
本地開發出錯
如果是自己本地代碼出錯，那就直接採用最簡單快捷的方式了，代碼調試。使用編輯器自帶的調試功能，加上斷點，一步步走代碼邏輯，查看各處代碼值是否正常。一般來講，本地開發最常見的錯誤莫過於空指針異常了，往往一番加斷點打日誌排查後，發現是自己寫的小bug。相比上面兩種情況，本地是最好解決的。
霚裡看花最是迷人
將本地的代碼寫好，運行的時候，對於新手的我們難免會出現各種報錯信息，以下是我在項目過程中：定位錯誤信息的幾種方式。
一、最原始的-控制檯報錯的信息
通過查看控制檯報錯信息，將報錯內容翻譯出來（通過多次項目編碼的過程中，大部分報錯信息都差不多，可以記住一些常見的英文單詞，以便下次可以快速的定位問題），這樣基本上就可以將問題定位出來，這也是最好解決的狀況，也是表明你是菜鳥的重要體現（不過沒有關係，下次注意就好了，成長是需要一個過程的）。
二、初中級-使用debug定位+try catch捕獲異常信息
該方法主要是針對本地代碼可以啟動，頁面也可以正常顯示，某些功能不能正常實現的問題。首先確保項目是用debug起的，將具體的方法代碼找到，打上斷點，找到具體的報錯的地方，使用try-catch將異常信息打印出來，通過控制檯查看異常信息，定位問題。（該方法主要是適用於自己寫的需求代碼，也是開發過程中最常用的定位問題手段）
三、中級階段-查看eclipse安裝目錄下的log日誌信息
這個手段也是我們在開發過程中常用的，我們可以通過查看log日誌看到具體報錯信息（我在項目中，一般是用來定位頁面報錯信息，就是頁面打不開或者報錯），在eclipse安裝目錄下找到一個.log文件，用一個文本編輯器打開（我使用的是EditPlus），先將原來的日誌信息刪除，然後在重新點開頁面，使用EditPlus的話點擊重新載入就可以看到新的報日誌信息，將error的信息選中，定位error就好了。
四、高級階段-使用xshell查看日誌信息
如果你們公司項目每個方法進出都記錄了操作日誌或者info日誌，你可以使用xshell查看錯誤信息，該方法一般是不跑本地代碼，直接定位環境上的錯誤信息（大項目的時候）。
總的一句話，主要我們在項目中經常性的總結，隨著接觸的項目需求越來越多，我們定位問題的速度也是越來越快的，記住：千里之行始於足下，堅持到最後的，才能夠笑到最後！
Echa攻城獅
日誌日誌日誌。
線上問題很難定位，加了日誌會幫助很快找到出bug的地方。還有就是加一個報警的系統。當程序出現異常被catch的時候或者直接throw的時候會通過郵箱.短信的方式提醒你線上出現了問題。能夠第一時間知道系統出問題了……
在線上加日誌最好debug，這樣不會在線上打印很多日誌，影響機器cpu。我們定位問題的時候將日誌級別調為debug。然後排查問題。
快速高效的排查問題。
希望大家線上永無bug
J小勁
程序出錯是很正常的事情，每天你都會遇到各種各樣的異常，那麼遇到問題應該怎麼定位問題，首先要看控制檯，報的異常是什麼？如果是生產環節，那麼可以看服務器日誌，模擬出錯，然後定位問題，當然還有一些問題可能是因為程序編寫不規範該加的符號沒有加， 更有甚者可能是因為開發工具或者緩存等因素造成錯誤發生，不過做程序只要時間久了，慢慢就有經驗了，遇到錯誤就知道該怎麼解決了，一點建議僅供參考，希望對你有所幫助！
阿里鵬
一般有這幾種方法：
1.通過輸出語句，來確定錯誤語句位置，比如System. out. println（“------------------”），在程序上下多處加入此語句當然為了可以適當修改比如橫線換成#。看看控制檯的打印，那塊沒有沒有打印，那麼它上面代碼有錯誤。這種不能看到詳細信息，比如變量的傳遞。
2.通過控制檯輸出的錯誤信息，點擊會跳到對應的錯誤代碼，來判斷怎麼出錯的。這種方法對程序邏輯錯誤不好判斷。
3.通過開發工具比如eclipse，在方法下面打一個斷電，通過debug運行，來調試代碼，此方法也是程序員經常使用的方法，可以清楚看到變量的傳遞，方法調用，包括閱讀源碼經常用到。此方法如果走的太快了，跳過去，可能要重新運行一遍debug。
代碼接盤俠
分不同環境，如果過是本地就直接debuge；如果是生產環境，儘量能在本地環境能重現，再來debuge。
生產環境，需要記錄exception的詳細詳細，特別是trace信息，這是查錯誤組主要的信息來源，會告訴你哪行程序出錯了，看了代碼 結合 錯誤信息，大概能判斷出錯誤原因。
