核心思路是让JIT内联高频逻辑：将计算抽为private/final小方法，剥离try-catch；异常捕获上移至调用层；禁用循环内try和宽泛catch；通过JIT日志验证inline(hot)是否生效。

核心思路不是“绕过编译器限制”，而是让 JIT 编译器愿意内联——关键在于把高频执行的逻辑从 try-catch 作用域中彻底剥离，使其成为纯净、无异常表干扰的小方法。

把计算逻辑抽成独立的 private/final 方法

被频繁调用的核心代码（如数值运算、字符串处理、循环体）必须不被任何 try 包裹。JIT 对 private/static/final 方法天然倾向内联，因为调用目标确定、无多态开销。

• 错误写法：在 for 循环内部或计算方法里直接加 try-catch
• 正确写法：将 5–10 行核心逻辑单独提取为 private int computeValue(int a, int b)，不带任何异常处理
• 若该方法只被本类调用，加 final 进一步强化内联信号；若已为 private，final 是冗余但无害

异常捕获上移到调用层

真正需要容错的是业务流程，不是原子计算。把 try-catch 放在 service 或 controller 层，只包裹对纯净方法的调用，而非方法内部。

• 例如：resizeCore(...) 做像素插值运算 → 无 try；外围 resizeImage(...) 方法用 try-catch 处理 IO 或参数异常
• 这样 resizeCore 的字节码干净、体积小（通常 <35）、无异常表、无同步块，极易被 C2 内联
• 同时保留了完整的异常语义：上层仍可记录日志、降级、重试，不影响可观测性

避免在热点路径引入异常相关结构

try-catch 本身零运行时开销，但它的存在会改变 JIT 的编译决策维度。只要方法含异常表，JVM 就需生成额外元数据、限制 OSR 入口点、降低内联优先级。

• 禁用：在 while / for 循环头/尾套整个 try，尤其不要在每轮迭代中 new 异常对象
• 慎用：catch (Exception e) —— 宽泛类型会让 JIT 更难做逃逸分析和异常传播推断
• 推荐：catch (NumberFormatException e) 这类具体类型，配合 final 方法，有助于 JIT 判定异常不会逃逸出当前栈帧

验证是否生效：看 JIT 日志，不靠猜

改完代码后，必须通过 JVM 参数确认内联是否真实发生，否则只是自我安慰。

• 启动时加：-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining -XX:+LogCompilation
• 运行后搜索日志中类似 inline (hot) com.example.MyClass.computeValue 的行，带 (hot) 才算成功
• 若看到 blocked by exception handler 或 too big，说明抽离不彻底，或方法体内仍有隐式异常源（如自动装箱、数组越界未防御）