受检异常阻碍jit优化：降低内联优先级、触发去优化、增大代码体积、拉长调用链；应边界收口、预检替代、用try-with-resources，使异常处理让位于运行期优化事实。
受检异常（Checked Exception）强制要求在编译期处理，这看似提升了健壮性，却常与现代JVM的控制流优化机制形成隐性冲突——尤其在热点路径上，它会实质性阻碍JIT编译器的内联决策、增加分支预测开销、抬高去优化风险。
受检异常破坏方法“热纯度”，触发JIT去优化
HotSpot JIT将频繁执行的方法标记为“热”，并尝试激进内联。但一旦方法声明throws IOException或SQLException等受检异常，JIT会将其视为“异常敏感”：即使该异常从不实际抛出，只要字节码中存在athrow指令或调用链含throws签名，JIT就可能降低其内联优先级。更严重的是，若某次运行真触发了该异常，整个已内联的调用链可能被撤回（deoptimization），退回到解释执行——这个过程开销远高于不内联本身。
try-catch块污染内联边界，增大代码体积
包含try-catch的代码段会生成异常表（exception table）和栈映射帧（stack map frames）。这些元数据虽不执行，却被JIT计入方法“复杂度评分”。当目标方法本身很短（如一个工具类的包装方法），JIT往往判定：内联后反而因异常表拼接、跳转逻辑插入导致代码膨胀和分支预测失败，得不偿失。finally块尤其明显——它要求在所有出口路径插入重复逻辑，JIT难以融合，直接放弃内联。
异常传播拉长调用链，触达内联深度上限
JIT默认内联深度上限为9层（C2编译器）。而典型的I/O操作常经多层封装：service → dao → jdbcTemplate → Connection → PreparedStatement。若其中任意一层（如jdbcTemplate）含有catch (SQLException e)，JIT会将该层标记为“异常相关调用”，进而限制对上游方法（如service）的进一步内联，哪怕service本身完全无异常逻辑。结果是：本可内联融合的纯计算逻辑被硬生生割裂，失去寄存器重用、死代码消除等关键优化。
更优解：用语义封装替代语法捕获
不是不用受检异常，而是把它们“关进笼子”：
-
边界收口：只在I/O入口（如Controller、Repository实现类）统一捕获受检异常，转换为业务语义明确的运行时异常（如
DataAccessException），上层调用者无需声明throws -
预检替代捕获：对高频校验（如参数非空），用
if (obj == null) throw new IllegalArgumentException()代替try { ... } catch (NullPointerException e)，避免引入异常表 -
资源管理交由编译器：用
try-with-resources替代手动try-finally，其生成的字节码更紧凑，JIT更易识别并优化资源释放路径
本质上，受检异常是编译期契约，而JIT优化是运行期事实。二者冲突时，应让契约服务于事实——把异常处理推到真正需要响应的位置，而非让它渗透进性能敏感的控制流核心。
