try-catch无异常时几乎无性能开销，真正代价在于异常抛出：栈轨迹构建占60%以上，异常表匹配与栈帧跳转共同导致耗时激增，实测抛异常比空catch慢260倍。
try-catch 本身在无异常时几乎不产生性能开销，真正影响高性能代码的是异常的抛出与处理过程。关键不在“写了 catch”，而在“是否真抛了异常”。
理解异常表如何不拖慢正常路径
编译器把每个 try-catch 编译成字节码中的异常表条目，只记录四件事：监控起始位置、结束位置、处理器入口地址、捕获类型索引。JVM 执行时完全不查这张表——除非异常真的发生。也就是说，只要没抛异常，这段代码和普通 if 判断一样轻量。
- 异常表是静态结构，存于 .class 文件的 Code 属性中，运行期只读
- 正常执行路径下，JVM 不做任何异常匹配判断，零分支预测干扰
- 即使方法里有 10 个 try-catch，只要没触发，CPU 流水线不受影响
量化异常抛出的真实成本
一次异常抛出（athrow 指令）平均耗时在纳秒级到微秒级之间，但代价集中在三处：
- 栈轨迹构建：遍历当前线程所有栈帧，提取类名、方法名、行号，封装为 StackTraceElement 数组 —— 占总开销 60% 以上
- 异常表匹配扫描：在当前方法异常表中顺序查找匹配项，通常 O(1)～O(N)，N 是该方法中 try-catch 块数量
- 栈帧解构与跳转：弹出当前栈帧，重置程序计数器到 handler_pc，重建新栈帧执行 catch 逻辑
实测数据（HotSpot JDK 17，Intel Xeon Gold）：空 try-catch 循环 100 万次，耗时 ≈ 8ms；若每次循环都抛 ArithmeticException 再捕获，耗时跃升至 ≈ 2100ms —— 性能下降超 260 倍。
高性能场景下的异常使用红线
在吞吐敏感或延迟敏感路径（如 Netty I/O 处理、高频风控计算、实时聚合），应严格避免将异常用于流程控制：
- 不用
Integer.parseInt(str)+ catch NumberFormatException 来校验数字格式，改用正则或 Apache Commons 的NumberUtils.isCreatable() - 不用
map.get(key) == null后 throw NullPointerException 来判空，改用Objects.requireNonNull()或 Optional 显式表达语义 - 在 for-each 循环中不依赖 IndexOutOfBoundsException 终止遍历，必须用 size() 控制边界
验证与定位异常热点的实战方法
当怀疑异常成为性能瓶颈时，不要靠猜，用工具实测：
- 开启 JVM 参数
-XX:+PrintGCDetails -XX:+PrintCompilation -XX:+LogCompilation，配合-XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints获取更细粒度事件 - 用 JFR（Java Flight Recorder）录制运行时事件：
jcmd <pid> VM.unlock_commercial_features && jcmd <pid> JFR.start settings=profile duration=60s filename=rec.jfr</pid></pid>，然后在 JDK Mission Control 中筛选 java.ExceptionThrow 事件，看频次和堆栈 - 用 async-profiler 抓取 CPU 火焰图：
./profiler.sh -e cpu -d 30 -f flame.svg <pid></pid>，重点观察java.lang.Throwable.fillInStackTrace是否出现在热点路径
