现代jvm中try-catch在循环内或外性能几乎无差异，关键在于异常是否发生及频率；无异常时jit优化充分，有异常时开销源于异常本身而非位置。
现代 JVM（JDK 8u212 及以上，尤其是 JDK 17/21）中，try-catch 放在循环内或外，本身几乎不带来可测量的性能差异。真正影响性能的，不是语法位置，而是异常是否实际发生、发生的频率，以及异常处理逻辑对执行路径稳定性的影响。
无异常时：两者基本没区别
只要异常没被抛出，JIT 编译器会把正常执行路径当作“热路径”重点优化。无论是循环内还是循环外写 try-catch：
- 字节码层面只生成一条异常表（Exception Table）记录，查找开销恒为 O(1)
- JIT 可照常做方法内联、循环展开、向量化等优化，不受 try 语句嵌套位置干扰
- JMH 实测显示：零异常场景下，两种写法耗时差异通常在 ±1% 以内，属噪声范围
有异常时：关键看频率和处理方式
异常一旦高频发生，性能下降就不是因为“try 写在哪”，而是因为异常本身的开销：
- 每次抛异常都会构建完整栈轨迹，产生堆内存压力，间接加剧 GC 频率
- JIT 可能触发去优化（deoptimization），已编译的热点代码退回到解释执行
- 若 catch 块里修改循环变量、抛新异常、调用阻塞 I/O，会破坏控制流可预测性，让 JIT 放弃激进优化
此时，循环内捕获意味着每次异常都走一遍上述流程；循环外捕获则只触发一次——但这属于业务中断策略的选择，不是“性能优化手段”。
别再信“早期 JDK 的遗留认知”
JDK 6/7 时代确实存在循环内 try 导致明显开销的问题，源于当时异常上下文设置成本高、JIT 优化能力弱。但自 JDK 8u212 起，这一问题已被大幅缓解。当前主流版本中：
- 没有“每次进入 try 就注册一次异常表”的开销
- 没有“循环内 try 阻止 JIT 向量化”的硬性限制
- 盲目将 try 移到循环外，可能掩盖真实问题（比如本该修复的数据脏读，却靠提前终止来回避）
该关注什么，而不是位置
比起纠结 try 放哪，更应检查：
- 异常是否本可避免？例如用 if 先校验空值或范围，而非依赖 NullPointerException 或 ArrayIndexOutOfBoundsException
- 是否在高频路径上抛受检异常？考虑改用返回 Optional 或状态码
- catch 块是否做了重操作？如日志全量打印、同步网络调用、锁竞争等——这些才是真正的瓶颈
- 是否真需要每轮都捕获？比如文件处理失败，记录错误后继续，就该放循环内；而数据库事务要求原子性，就必须放循环外并配合回滚
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
