try-catch本身不阻碍JIT编译，但作用域过大会稀释热点密度、延迟C2编译；应将核心逻辑抽为无try的小方法，异常处理外移到调用层。
try-catch 本身不阻碍 JIT 编译，但作用域过大可能干扰热点识别与内联优化——关键不在“捕获”，而在“范围”。
try-catch 不影响正常路径性能，但扩大作用域会稀释热点密度
JVM 在无异常时完全忽略异常表，try-catch 块对执行速度零开销。问题出在：JIT 编译器以“方法”为单位触发编译，而一个被大段 try 包裹的方法，其内部真正高频执行的逻辑（比如循环体或核心计算）可能因异常处理代码混杂，导致方法整体热度被摊薄，延迟进入 C2 编译队列。
- 一个含 50 行代码的方法，其中仅 8 行是每帧调用的数值计算，其余 42 行是日志、IO 或兜底 catch —— JIT 可能长期只用 C1 快速编译，不升到 C2 做深度优化
- 若把这 8 行独立成小方法，并确保它不被任何 try 包裹，它更容易被识别为“高调用频次方法”，更快触发内联与向量化
将异常处理外移，让核心逻辑“裸奔”进热点编译
不是去掉异常处理，而是把 try-catch 拆到调用层，让被 JIT 重点优化的子方法保持纯净。
- 错误写法：在计算方法内部包一层 try-catch，哪怕只为了吞掉某个 RuntimeException
- 推荐写法：计算逻辑单独抽成 private 方法，不加任何 try；异常捕获放在上层业务方法中
- 例如：图像缩放核心循环 → 提炼为
private int[] resizeCore(int[] src, int scale)；外围 service 方法用 try-catch 包裹对该方法的调用
避免在循环体内使用 try-catch，尤其不要包裹整个 for
循环体是 JIT 最常触发 OSR（栈上替换）的场景之一。一旦整个 for 被 try 包裹，JVM 必须为该方法生成更复杂的异常表，且 OSR 入口点受限，可能放弃对该循环的深度优化（如循环展开、向量化）。
立即学习“Java免费学习笔记（深入）”；
- 禁止：
try { for (int i = 0; i - 允许：
for (int i = 0; i —— 细粒度、类型明确、不影响循环结构 - 更优：
process(i)内部已做防御性检查（如 null 判断、索引校验），从源头避免异常抛出，比 catch 更高效
用 final 方法 + 明确异常类型，辅助 JIT 做逃逸分析和内联决策
JIT 对 final 方法更倾向内联；而 catch 块中若声明的是具体异常（如 catch (NumberFormatException e)），而非宽泛的 Exception，JVM 在类型推导时能更准确判断异常传播路径，有利于逃逸分析判定对象是否逃逸、是否可栈上分配。
- 把工具类方法设为
private或final，减少虚方法调用开销 - catch 子句按异常继承链从具体到宽泛排列，避免父类异常提前截断匹配
- 对已知不会抛出检查异常的代码段，不用强制 try-catch；JIT 会更放心地做激进优化
