多catch块本身几乎无性能开销，真正瓶颈是异常抛出时的堆栈构建与对象创建；应避免用异常做流程控制，优先预检、降级和轻量包装，并确保catch顺序正确。
多catch块本身几乎不带来运行时性能开销，真正影响性能的是异常发生时的堆栈构建、对象创建和处理逻辑。Java在没有异常抛出时，try-catch结构是零成本的；只有当异常实际被抛出并捕获时，才会触发JVM的异常处理机制，这部分开销明显高于普通控制流。
异常抛出才是性能瓶颈
Java中throw操作会触发完整的堆栈跟踪（StackTraceElement数组生成），这是最耗资源的环节。一次异常抛出的开销通常是普通方法调用的数十倍。因此，关键不是“写了几个catch”，而是“是否频繁抛出异常”。
- 避免用异常做流程控制：比如用
NumberFormatException来判断字符串是否为数字，应改用String.matches("\d+")或Integer.parseInt()配合if预检 - 受检异常（如
IOException）通常对应真实外部故障，无法完全规避，但可通过缓存、连接池、预校验等方式降低发生频率 - 非受检异常（如
NullPointerException）多数源于编码疏漏，应通过静态检查、单元测试和防御性编程提前拦截
多catch顺序对性能无影响，但对正确性至关重要
catch块的排列顺序由编译器强制校验，不影响运行效率，但错误顺序会导致编译失败或逻辑失效——这不是性能问题，而是功能性缺陷。
- 子类异常必须写在父类前面：例如
FileNotFoundException→IOException→Exception - 若把
Exception放在最前，后续所有catch都会被标记为“不可达代码”，编译直接报错 - Java 7+支持的多异常合并语法（
catch (IOException | SQLException e)）仅适用于无继承关系的异常类型，编译后生成的字节码与单catch等效，无额外开销
企业级场景中的性能敏感实践
在高并发服务中，异常处理策略需兼顾可观测性与吞吐量。重点不在减少catch数量，而在让异常“少发生、快响应、易归因”。
- 对可预期失败（如用户输入格式错误、库存不足）使用自定义业务异常，并在Controller层统一转换为HTTP状态码，避免堆栈打印
- 对第三方调用失败（如RPC超时、DB连接拒绝），优先走降级逻辑而非抛异常；确需抛出时，用轻量级包装（如不填充完整堆栈）
- 日志记录要分级：ERROR级别只记关键上下文（如订单ID、接口名、错误码），不记全堆栈；DEBUG级别才输出
e.printStackTrace() - 批量操作中采用循环内捕获，单条失败不影响整体吞吐；但需注意避免每条都新建异常对象，可复用错误模板或使用错误码枚举
异常处理不是性能优化的主战场，而是系统健壮性的基础设施。写对catch顺序、选对异常类型、控制抛出频次，比纠结“多个catch会不会变慢”更能带来实质收益。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
