关键在于异常何时产生开销及JVM如何将其翻译为机器指令，需聚焦异常表生成逻辑、抛出与声明成本差异、JIT对异常路径的优化策略，以及AOT/跨平台环境下的适配。
直接看异常在不同JVM版本下的行为差异，比单纯升级更有效。关键不是“怎么捕获异常”，而是“异常何时真正产生开销”以及“JVM如何把它翻译成机器指令”。重构系统时，要围绕这个转译链做针对性优化。
盯住异常表（Exception Table）的生成逻辑
JVM每个方法的字节码都附带一张异常表，它决定了catch块能否被命中、finally如何插入、甚至影响内联决策。不同JVM版本对这张表的构建策略有变化：
- JDK 8–11：异常表项按源码顺序静态生成，嵌套try-catch会生成冗余条目，增加查找开销
- JDK 12+（特别是JDK 17+）：C2编译器会对异常表做合并与范围收缩，减少线性匹配次数；但前提是方法未被频繁去优化（deoptimization）
- GraalVM Native Image：AOT阶段无法保留完整异常表，会将未显式声明的checked异常转为运行时异常，且不支持动态生成stackTrace
重构建议：用 javap -v ClassName 对比不同JDK编译出的class文件，观察异常表项数量与范围是否异常膨胀；若存在多层空try-catch或仅用于日志的catch，应直接删减——这比加@SuppressWarning更治本。
区分“抛出成本”和“声明成本”
很多人误以为写个try-catch就有性能损耗，其实不然。真正昂贵的是throw new XxxException()这一句：
- 从JDK 9开始，Throwable::fillInStackTrace默认调用
getStackTraceDepth()并遍历全部栈帧，耗时与调用深度正相关 - JDK 14引入
-XX:+OmitStackTraceInFastThrow（默认开启），对NullPointerExceptionArrayIndexOutOfBoundsException等高频异常跳过栈填充——但自定义异常不受惠 - JDK 17后，StackWalker API可替代传统
getStackTrace()，支持懒加载与过滤，适合诊断型日志而非控制流
重构建议：对业务中高频出现的“伪异常”（如查不到用户就抛UserNotFoundException），改用Optional或ResultRuntimeException并重写fillInStackTrace()返回this，前提是不依赖完整堆栈定位问题。
利用JIT反馈重构异常路径
HotSpot的C2编译器会基于运行时采样，将“极少走的catch分支”标记为冷路径，并可能将其从编译代码中剥离，只保留在解释执行入口。这意味着：
- 如果某段catch代码从未被执行过，JIT不会为其生成机器码，也不会计入方法内联阈值
- 但一旦该catch首次触发，JVM需回退到解释模式执行，并触发重新编译，带来明显延迟毛刺
- JDK 21的ZGC + Shenandoah已支持在异常处理路径上做更细粒度的分代回收，降低
Throwable对象分配压力
重构建议：用-XX:+PrintCompilation和jstat -compiler监控关键方法是否因异常路径反复退优化；对确定会触发的异常场景（如网络超时），提前在预热阶段主动抛一次，让JIT完成编译固化。
面向AOT与跨平台运行时的异常适配
当系统要支持GraalVM Native Image或Android ART时，异常机制不再是“透明”的：
- GraalVM要求所有可能抛出的异常类必须在构建期注册（
@RegisterForReflection），否则运行时报NoClassDefFoundError而非原异常 - Android R+对
ExceptionInInitializerError做了拦截重写，原始cause可能丢失，需用getCause().getCause()双层提取 - WebAssembly JVM（如JWebAssembly）不支持原生栈展开，
try-finally靠状态机模拟，catch仅支持精确类型匹配，不能捕获父类
重构建议：建立项目级异常白名单，在构建脚本中自动注入反射注册；避免在static块中抛异常；对跨平台模块，用接口统一异常构造逻辑，而非直接new具体类型。
