Java异常处理性能瓶颈主因是异常创建、堆栈生成及不当吞没，而非try-catch本身；应缩小try范围、精准捕获具体类型、不捕获非受检异常、资源操作必用try-with-resources。
Java异常处理不是性能瓶颈的主因，但写法不当会拖慢响应、掩盖问题、增加维护成本。真正影响性能的，往往不是try-catch本身，而是异常对象的创建、堆栈追踪生成、以及不合理的捕获与吞没逻辑。高性能的异常处理，核心是“少抛、准捕、快走、不藏”。
缩小try块范围，只包裹真正可能出错的代码
一个try块里塞入20行逻辑，既难定位异常源头，又让JVM在无异常时也承担额外的监控开销（虽微小但可避免）。关键在于：只对明确可能抛出受检异常或需隔离风险的操作加try。
- 文件读取、数据库查询、网络调用等I/O操作单独包裹
- 数值解析、JSON反序列化等格式转换操作独立处理
- 避免把参数校验、业务判断、日志打印等稳定逻辑放进try
精准捕获具体异常类型，禁用catch(Exception e)
捕获Exception或Throwable会一并吞掉NullPointerException、ArrayIndexOutOfBoundsException等本该暴露的编程错误，导致缺陷潜伏。JVM生成完整堆栈信息也有开销，而泛型捕获后不做区分处理，等于白花资源。
- 优先按实际抛出类型写多个catch，如FileNotFoundException → IOException
- 子类异常必须写在父类前面，否则编译报错且逻辑失效
- 若需统一兜底，应在最外层（如Controller）做有限封装，而非每层都catch Exception
非受检异常不捕获，靠预防代替兜底
NullPointerException、IllegalArgumentException这些RuntimeException，本质是代码缺陷信号。用try-catch掩盖它们，等于绕过质量关口。高性能系统更依赖“fail-fast”——早发现、早修复。
立即学习“Java免费学习笔记（深入）”；
- 参数进来先判空、校验状态，用Objects.requireNonNull()等工具主动抛出
- 集合操作前检查size()、使用Optional替代null返回
- 单元测试覆盖边界场景，比运行时捕获更高效、更可靠
资源操作必用try-with-resources，杜绝finally手动关
手动在finally里close资源，容易遗漏、重复关闭、或close本身再抛异常（掩盖原始异常）。try-with-resources由JVM字节码层面保障自动关闭，无额外性能损耗，且语义清晰。
- 所有实现AutoCloseable的资源（FileInputStream、Connection、Scanner等）都应声明在try括号内
- 多个资源用分号隔开，JVM按声明逆序关闭，无需嵌套
- 即使try块中发生异常，资源仍会被关闭，原始异常不会被覆盖（Java 7+优化）
