目錄

第一類：常見的運行時異常

第二類：業務相關的特定異常

第三類：框架和集成相關的異常

需要避免的坑

總結

---

在我的項目開發和生產運維中，遇到的異常可以歸納為以下幾類：

第一類：常見的運行時異常

這類異常通常是由於編碼疏忽或邏輯不嚴謹造成的。

• 空指針異常

• 場景： 最經典的比如：調用 null 對象的方user.getName()， 從Map中get一個不存在的鍵返回null後繼續操作，或者自動拆箱Integer為int時對象為null。
• 原因與解決： 根本原因是缺少null值判斷。我的解決方法是：1）在調用前進行判空；2）使用Optional類來優雅地處理可能為null的情況；3) 在獲取 Map 值時使用getOrDefault方法。

• 類型轉換異常

• 場景： 在使用集合框架時，比如從一個聲明為List的集合裏取出一個元素並強轉為String，但實際上裏面存放的是Integer。
• 原因與解決： 原因是類型不安全。解決方法是：1）在使用泛型集合時，始終指定具體的類型參數，利用編譯器的類型檢查；2）在強制轉換前使用instanceof進行類型判斷。

• 數組越界/字符串越界異常

• 場景： 循環或訪問數組、列表、字符串時，索引超出了有效範圍。
• 原因與解決： 循環條件或索引計算錯誤。解決方法是在訪問前檢查索引是否 >=0 且 < array.length

第二類：業務相關的特定異常

這類異常與你的項目業務邏輯緊密相關，能體現你的業務理解能力。

• 場景： 比如在一個電商項目中，我遇到過 InventoryShortageException。
• 原因： 用户下單時，系統檢測到商品庫存不足。
• 解決： 這不僅僅是一個技術異常，更是一個業務流程問題。我們不僅在代碼中拋出這個異常，還在前端給用户明確的提示“商品庫存不足”，並引導用户重新選擇。同時，這個異常會觸發告警，通知運營人員及時補貨。

第三類：框架和集成相關的異常

這類異常能體現你對所用技術棧的熟悉程度。

• Spring框架中的異常：

• BeanCreationException： 比如Bean注入失敗，可能是因為循環依賴。我們通過代碼重構，使用@Lazy註解或 setter 注入來解決。
• TransactionException： 事務回滾失敗。我們檢查了事務的傳播屬性和數據庫連接，確保在異常發生時事務能正確回滾。

• 數據庫相關異常：

• DataIntegrityViolationException： 插入數據違反了數據庫約束（如唯一鍵衝突、外鍵約束）。我們通過在前端增加數據校驗和在代碼中先查詢再插入的邏輯來避免。
• DeadlockLoserDataAccessException： 數據庫死鎖。我們通過分析數據庫死鎖日誌，調整業務邏輯中SQL的執行順序，或者縮短事務執行時間來減少死鎖概率。

• 網絡和微服務異常：

• ConnectException / SocketTimeoutException： 在調用外部HTTP接口或微服務時，連接超時或讀取超時。
• 原因與解決： 網絡不穩定或下游服務響應慢。我們的解決方案是：1）合理設置連接和讀取超時時間；2）引入重試機制（如Spring Retry）；3）使用熔斷器模式（如Hystrix或Resilience4j）防止雪崩效應。

需要避免的坑

• 不要説“我沒遇到過什麼異常”： 這會顯得你經驗不足。
• 不要只停留在表面： 不要只説“我遇到了NPE，然後加了判空”。要深入一點，講講場景和思考。
• 不要抱怨： 不要把問題歸咎於同事或過時的代碼，要展示你主動解決問題的能力。

總結

面試官問這個問題，不僅僅是想聽你列舉異常名稱，他更想考察你的實戰經驗、問題分析能力和解決複雜問題的思路。用一個結構化的回答，並結合一個深入的故事，會讓你在這個問題上獲得高分。