核心思路是让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 的字节码干净、体积小（通常
- 同时保留了完整的异常语义：上层仍可记录日志、降级、重试，不影响可观测性
避免在热点路径引入异常相关结构
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，说明抽离不彻底，或方法体内仍有隐式异常源（如自动装箱、数组越界未防御）
