首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
您现在的位置: 程式碼之家 >> 編程語言 >  >> Java 程式設計 >> Java 相關知識

Java 五大常見異常深度剖析:NPE、數值格式、字符串越界、類加載、系統錯誤

     編輯:Java 相關知識

1. NullPointerException —— 空指針的萬惡之源

根因

基本類型有默認值,編譯期強制賦值;引用類型默認 null,編譯器不攔截未初始化調用。所有 NPE 本質上都是「對 null 解引用」。

三大典型現場


// 現場 1:直接使用請求參數
out.println(request.getParameter("username")); // 參數無 → null → println 輸出 "null" 但後續操作崩

// 現場 2:對 null 調用 equals/toString
String name = request.getParameter("username");
if (name.equals("root")) { ... } // name 為 null → NPE

// 現場 3:Session 失效後鏈式調用
String user = session.getAttribute("user").toString(); // 屬性無 → null → NPE

三級防禦體系

  1. 源頭攔截:Controller 入口統一校驗必填參數,缺失直接返回 400/提示頁
  2. 過程防禦:if (obj != null) { obj.method(); } 或 Optional.ofNullable(obj).ifPresent(...)
  3. 默認值兜底:String name = Optional.ofNullable(req.getParameter("name")).orElse("");

統一異常處理模板:對所有可預期異常採用「記錄日誌 + 友好提示 + 降級/熔斷」三步走。

2. NumberFormatException —— 字符串轉數字的邊界之戰

現場


String s = request.getParameter("memberId"); // 用戶輸入 "T1082"
int id = Integer.parseInt(s); // 拋 NumberFormatException

解決方案對比

策略代碼優點缺點
默認值兜底catch → id = 0簡單下游邏輯可能誤判 0 為合法 ID
拋業務異常catch → throw new BizException("會員ID格式錯誤")語義清晰、統一錯誤碼需全鏈路異常處理機制
前端雙重校驗JS 正則攔截 + 後端再驗證用戶體驗好、減少無效請求不可替代後端校驗

推薦:後端統一用 @InitBinder 註冊自定義 Converter,轉換失敗拋統一 BindException,由 @ControllerAdvice 統一返回 JSON 錯誤。

3. StringIndexOutOfBoundsException —— 字符串操作的隱形炸彈

高危操作

substring(begin, end)、charAt(index)、getBytes()、valueOf(char[])。

安全封裝模式


public static String safeSubstring(String str, int begin, int end) {
    if (str == null) return "";
    int len = str.length();
    if (begin < 0) begin = 0;
    if (end > len) end = len;
    if (begin >= end) return "";
    return str.substring(begin, end);
}

所有業務代碼禁用原生 API,強制走工具類。IDE 可配置檢查規則禁止直接調用高危方法。

4. NoClassDefFoundError —— 類加載期的幽靈

兩大成因

  1. 文件缺失/路徑錯:.class 未打包、未部署、目錄結構不匹配包名
  2. 類加載器隔離:父子加載器可見性不一致(如 WAR 包含 A.jar,EAR lib 也含 A.jar 不同版本)

排查步驟

  1. 重新打包部署 (Maven clean package)
  2. 檢查服務器部署目錄實際文件
  3. 啟用 -verbose:class 觀察類加載來源
  4. 排查多模塊依賴衝突 (mvn dependency:tree)

5. java.lang.Error —— 系統級資源耗盡

三大觸發鏈路

  1. 資源未關閉 → 連接池耗盡/文件句柄耗盡/端口耗盡
  2. 資源重複關閉/錯誤關閉 → 底層庫拋錯 → 線程崩潰
  3. 外部依賴不可用 (DB 掛掉) → 線程堆積 → OOM/拒絕服務

工程化治理

  • 語法層:全面推行 try-with-resources,Sonar 規則禁止手動 close()
  • 架構層:統一連接池、線程池、HTTP 客戶端池,配置驗證查詢、空閒回收、最大等待
  • 觀測層:Prometheus 監控連接池使用率、線程池隊列長度、文件句柄數,設置告警閾值
  • 韌性層:熔斷器、限流器、超時控制、降級預案

總結:從「修補漏洞」到「構建免疫系統」

單點修復治標,體系化防禦治本。成熟團隊應建立:

  1. 編碼規約:禁用高危原生 API、強制工具類/Optional/Try-with-resources
  2. 靜態掃描:SonarQube/SpotBugs 集成 CI 攔截隱患
  3. 統一異常處理:@ControllerAdvice + 錯誤碼體系 + 結構化日誌
  4. 資源治理:池化、監控、熔斷、演練

異常不可避免,但「不可控的異常」才是真正的敵人。

  1. 上一篇文章:
  2. 下一篇文章:
Copyright © 程式碼之家 All Rights Reserved