Java异常性能优化关键在于减少创建频次、精准捕获、剥离重操作；禁用异常作流程控制，预检替代解析异常；捕获需具体类型、分层收口；切面轻量异步；工具链强制规范。
Java 异常处理本身有开销，但真正影响性能的往往不是 try-catch 语法，而是捕获逻辑的设计方式。优化关键在于：**减少异常创建频次、避免宽泛捕获、剥离重操作、让异常真正“该抛时抛、该捕时准”**。
避免在高频路径上抛异常做流程控制
异常本质是“非正常流程”，JVM 创建异常对象需填充完整堆栈（fillInStackTrace()），耗时远高于普通对象。若用 NumberFormatException 来判断字符串是否为数字，或用 ParseException 来校验日期格式，就属于典型误用。
- 改用预检逻辑：如
StringUtils.isNumeric(str)、DateTimeFormatter.parseBest()或正则预匹配 - 仅在真正发生意外时抛异常（例如解析用户提交的非法 JSON、第三方接口返回不可信结构）
- 对已知可能失败的输入，优先走“返回 Optional/Result 封装”而非依赖 try-catch 捕获
捕获要具体，不写 catch (Exception e)
泛捕不仅语义模糊，还会导致本该快速暴露的严重问题（如 NullPointerException、ArrayIndexOutOfBoundsException）被静默吞掉，间接引发更隐蔽的逻辑错误或数据污染——排查成本远高于性能损耗本身。
- 只捕获你明确知道如何恢复的异常类型，例如：
catch (IOException | TimeoutException e)处理网络调用失败 - 按继承顺序从具体到宽泛排列，防止子类异常被父类
catch提前截断 - 中间层（Service/DAO/Util）禁止泛捕；兜底统一收口到 Web 层或网关层，并完整记录堆栈
切面和日志中的异常处理要轻量异步
AOP 切面里写重逻辑是性能隐形杀手。一个 @Around 切面若在 proceed() 前后做 JSON 序列化、同步发 HTTP 请求或查 DB，异常未抛出前性能已崩。
立即学习“Java免费学习笔记（深入）”；
- 切面内只做拦截、标记、简单上下文提取（如方法名、参数长度）
- 日志记录、监控上报、告警通知全部交给线程池异步执行
- 异常发生时，切面不尝试“修复”，只确保原始异常透出，由上层按策略处理（重试/降级/熔断）
善用工具约束 + 静态检查提前拦截
靠人自觉容易遗漏。把规范变成 CI 红线，才能守住底线。
- 用 SonarQube 或 Checkstyle 配置规则：禁止
catch (Exception|Throwable)、禁止空 catch 块、禁止printStackTrace() - 在构建阶段启用编译器插件（如 ErrorProne），对泛捕、忽略返回值等模式直接报错
- 内部 SDK 封装外部调用时，将
throws Throwable显式改为细粒度异常（如ApiTimeoutException），降低上层被迫泛捕压力
