java中try-catch在无异常时性能开销极小，真正拖慢程序的是异常抛出过程；其高成本源于堆栈跟踪生成、调用栈遍历匹配及栈帧展开，误用作控制流（如频繁解析失败）将导致性能骤降数个数量级。
Java中try-catch本身在无异常时几乎不拖慢程序，真正影响执行效率的是异常被抛出的过程——不是“写了try”，而是“总在throw”。
try-catch块在正常路径下开销极小
现代JVM（如HotSpot）将try块编译为字节码中的异常表（exception table），不插入运行时判断或跳转指令。只要没异常发生，CPU不会多执行任何操作，循环里写100个try-catch和写100个普通语句，性能基本一致。
异常抛出才是性能断崖的根源
一旦触发throw，JVM必须同步完成多项高成本操作：
- 创建异常对象并填充完整堆栈跟踪（逐帧收集方法名、行号、类加载器等）
- 遍历调用栈查找匹配的catch块，涉及类型检查与范围比对
- 展开栈帧、重置执行上下文，可能中断JIT已做的内联与逃逸分析
- 若未被捕获，还需向上逐层传播，重复查找与重建
实测显示：10万次异常抛出耗时约为10万次整数除法的400倍；频繁在解析循环中因格式错误抛NumberFormatException，会让吞吐量骤降数个数量级。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
哪些场景容易误用并拖慢系统
以下做法本质是把异常当控制流用，应优先改写：
- 用
Integer.parseInt()+ catch NumberFormatException验证字符串是否为数字 → 改用Character.isDigit()预检或正则\d+ - 批量处理日志时，每条都try-catch解析时间字段 → 先用正则粗筛
\d{4}-\d{2}-\d{2}，再对合格项解析 - 网络请求失败后立即try-catch再sleep重试 → 改为检查HTTP状态码（如429/503），按错误类型做指数退避
什么情况下可以放心使用
当异常确实代表罕见、不可预测的意外事件，且无法前置校验时，循环内加try-catch是合理且清晰的：
- 读取一批本地文件，99.9%存在，极个别被外部进程临时删除
- 调用文档明确标注“仅在网络分区时抛IOException”的遗留服务
- 访问内存映射文件时偶发底层OS信号中断
此时异常是信号而非流程分支，开销可接受，代码也更贴近真实语义。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
