java中try-catch本身不慢，真正开销在于异常抛出，其耗时可达普通方法调用的上百倍；应根据业务语义选择循环内外放置位置，并避免用异常作流程控制。
Java里用try-catch本身不慢，真正拖慢程序的是异常被抛出来——一次异常开销可能是普通方法调用的上百倍。关键不是“要不要用try-catch”，而是“在哪用、怎么用、为什么用”。
try-catch放循环里还是外？看业务语义
这不是语法题，是设计选择。
- 循环外包一层：适合强一致性场景。比如批量更新用户积分，要求全部成功或全部失败。一旦某次迭代出错，立即终止，避免部分写入导致数据不一致。
- 循环内各包各的：适合容错型任务。比如解析1000条日志，某条格式错误不能让整批失败。单次异常被捕获后，不影响后续处理。
- 混合策略更常见：外层兜底防崩溃，内层细粒度捕获并记录错误详情；或者按批次分组（如每100条一组），组内失败只跳过该组。
别让异常当if用——性能杀手的根源
异常机制本为“意外情况”而生，但很多人把它当成流程控制手段，这会触发最重的开销环节：栈遍历 + 堆栈跟踪生成 + 异常对象构造。
- 用
Integer.parseInt()加catch处理字符串是否为数字 → 改用Character.isDigit()预判或正则粗筛 - 逐行JSON解析都套try-catch → 先用轻量正则检查是否含
{/[，再集中解析合格项 - 数据库查不到就靠
EmptyResultDataAccessException分支 → 改用exists()或count() > 0提前探查
JVM层面的真实开销在哪
现代JDK（尤其是HotSpot）对无异常路径做了深度优化：try块本身几乎零开销，编译器会跳过异常表查询；真正昂贵的是异常抛出那一刻。
- 异常对象创建要分配堆内存、填充堆栈快照，耗时远超普通对象
- 频繁抛同一类异常会干扰JIT内联判断，使热点代码降级编译
- finally块若也抛异常，会掩盖原始异常，增加排查难度
- 资源管理优先用
try-with-resources，它生成更高效字节码，且自动处理异常抑制
实用优化建议
写代码时多问一句：这个“异常”真的是意外，还是我本可以预判的常规情况？
- 捕获具体异常类型（如
NumberFormatException），而非泛泛的Exception - catch块里避免耗时操作：不查DB、不发HTTP、不写大文件；只记日志+设状态
- 生产环境慎用
e.printStackTrace()，改用SLF4J等日志框架并控制输出级别 - 高频路径上，把try-catch移到循环外；低频或不可控输入处，才考虑内嵌
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
