「異常僅用於異常情況」是 Java 核心設計哲學，但實務中常見濫用異常控制流程、過度捕獲、堆疊追蹤開銷大等導致效能退化。本文從 JVM 實作原理、微基準測試、生產事故案例三個維度，深度解析異常處理的效能影響，並給出具體優化清單。
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class ExceptionBenchmark {
@Benchmark public void normalFlow() { int x = 1 / 1; } // 正常分支
@Benchmark public void tryCatchNoThrow() {
try { int x = 1 / 1; } catch (ArithmeticException e) {} // 無拋出
}
@Benchmark public void throwCatch() {
try { throw new Exception(); } catch (Exception e) {} // 建構+拋出+捕獲
}
@Benchmark public void throwCatchStackTrace() {
try { throw new Exception(); } catch (Exception e) { e.getStackTrace(); } // + 捕獲堆疊
}
}
/*
典型結果 (JDK 17, x86_64, 熱身後)：
normalFlow ~ 0.3 ns/op
tryCatchNoThrow ~ 0.4 ns/op (JIT 優化極佳，幾乎零開銷)
throwCatch ~ 150 ns/op (建構異常物件、填充堆疊)
throwCatchStackTrace ~ 1,200 ns/op (完整堆疊追蹤捕獲約 8x 開銷)
*/
結論：try-catch本身極輕量（JIT 會優化為無操作），真正開銷在於new Exception()建構與fillInStackTrace()。每秒拋出數萬次異常才會成為瓶頸，但高頻業務邏輯切勿用異常控制流程。
| 模式 | 問題 | 影響 | 修正 |
|---|---|---|---|
| 用異常做參數驗證/業務判斷 | 正常流程拋出大量異常 | CPU 飆升、GC 壓力大、日誌洪水 | 改用 if-else、Optional、Result 模式、Validation 註解 |
捕獲後 e.printStackTrace() 寫標準錯誤 | 同步 I/O 阻塞、日誌格式不統一、缺乏級別 | 輸出延遲、磁碟 IO 瓶頸、難以分析 | 統一使用 SLF4J + Logback：log.error("msg", e)，非同步 Appender |
| 多層包裝異常未保留原因 | throw new BizException(e.getMessage()) 丟失堆疊 | 根因追蹤困難、重複日誌 | throw new BizException("msg", e) 保留 cause |
捕獲 Exception/Throwable 過寬 | 吞沒 InterruptedException、OutOfMemoryError | 執行緒中斷失效、JVM 崩潰無感知 | 精確捕獲具體異常類別，catch (IOException | SQLException e) |
| finally 區塊拋出異常覆蓋原異常 | 原始原因被遮蔽 | 除錯極難 | 使用 try-with-resources 或 suppressedExceptions 機制 |
StackTraceElement[] 陣列（類名、方法名、檔名、行號）。fillInStackTrace() 返回 this（如 java.lang.StackOverflowError、部分自定義異常），可跳過捕獲，極大降低開銷。// 1. 無堆疊異常基類（高頻業務錯誤碼場景）
public class NoStackTraceException extends Exception {
@Override public synchronized Throwable fillInStackTrace() { return this; }
}
// 2. 條件式捕獲（僅除錯模式捕獲完整堆疊）
public class ConditionalStackException extends RuntimeException {
private static final boolean CAPTURE_STACK = Boolean.getBoolean("debug.exception.stack");
@Override public synchronized Throwable fillInStackTrace() {
return CAPTURE_STACK ? super.fillInStackTrace() : this;
}
}Logback AsyncAppender + PatternLayout 包含 %ex{full}，將昂貴的堆疊格式化移出業務執行緒。
public sealed interface Result permits Result.Success, Result.Failure {
record Success(T value) implements Result {}
record Failure(String code, String message) implements Result {}
static Result ok(T v) { return new Success<>(v); }
static Result err(String code, String msg) { return new Failure<>(code, msg); }
boolean isSuccess() { return this instanceof Success; }
T getOrThrow() { return switch(this) { case Success(var v) -> v; case Failure(var c, var m) -> throw new IllegalStateException(c + ":" + m); }; }
} public Optional findById(Long id) { ... } // 而非拋出 NotFoundException
// 呼叫端
userRepo.findById(id)
.ifPresentOrElse(u -> process(u), () -> log.warn("User not found: {}", id)); public class UserDTO {
@NotBlank @Size(max=50) private String username;
@Email private String email;
// Controller 方法加 @Valid，自動回傳 400 + 詳細錯誤，無需手動拋異常
}catch (SpecificException e)，避免 catch (Exception e)。throw new BizException("msg", rootCause)。log.error("context", e)，禁止 e.printStackTrace()。suppressed exceptions。-XX:-StackTraceInThrowable（慎用，會影響除錯）或自定義無堆疊異常類別。現象：高峰期 CPU 持續 100%，GC 頻繁，回應時間從 50ms 飆升至 5s+。
排查：線上 arthas 抓取熱點方法發現 OrderService.checkStock() 大量拋出 InsufficientStockException（庫存不足視為異常）。每秒拋出 ~5 萬次異常，堆疊捕獲佔用 60% CPU。
修正：改用 Result<Boolean> 返回庫存檢查結果，InsufficientStockException 改為無堆疊異常。
效果：CPU 降至 15%，GC 正常化，P99 延遲恢復 60ms。
異常是 Java 強大的錯誤處理機制，但濫用即濫能。理解 fillInStackTrace 開銷、JIT 優化邊界、日誌非同步原理，配合 Result/Optional/Validation 現代模式，即可在保證程式碼健壯性的同時榨乾效能。記住：好代碼用異常表達「失敗」，不錯代碼用異常控制「流程」。
