java中受检异常与非受检异常在性能上无本质差异，真正影响性能的是异常是否被实际抛出及栈轨迹生成等操作，而非是否受检；避免用异常控制流程、优先防御性检查、必要时禁用栈轨迹才是有效优化手段。
Java中受检异常和非受检异常在性能上没有本质差异——异常对象的创建、抛出、栈展开（stack unwinding）等开销，与它是否受检无关，只取决于异常类型、调用深度、是否填充栈轨迹（stack trace）等因素。
真正影响性能的关键点不是“是否受检”，而是“是否真的抛出”
编译器对受检异常的强制处理（try-catch/throws）本身不产生运行时开销；它只是语法约束。性能损耗发生在异常被实际抛出并传播时，无论 IOException 还是 NullPointerException，只要发生，JVM 都要：构造异常对象、捕获当前线程栈快照、逐层回溯调用链、触发异常处理器……这一整套流程成本相近。
- 空 try-catch 块（没抛异常）几乎零开销——现代 JVM 早已优化掉无异常路径的性能影响
- 频繁抛出异常（比如用异常控制流程）才是性能杀手，不管它是受检还是非受检
- StackTraceElement 数组生成、字符串拼接（如 getMessage()）、日志输出等，才是主要耗时环节
为什么有人觉得“受检异常更慢”？
这是一种常见误解，根源在于使用模式差异：
- 受检异常多出现在 I/O、网络、数据库等外部交互场景，这些操作本就慢——慢的是磁盘读写或网络延迟，不是异常机制本身
- 开发者常把受检异常“层层 throws 向上传递”，导致调用链更长，异常最终抛出时栈更深，栈展开成本略高（但仍是次要因素）
- 为满足编译要求而写的冗余 try-catch（比如空 catch 或仅打印日志），掩盖了问题却没提升健壮性，让人误以为“处理受检异常拖慢系统”
非受检异常反而更容易引发隐性性能风险
因为编译器不拦着，开发者可能：
- 在循环里反复触发 NullPointerException，靠 catch 吞掉——这比一次受检异常处理昂贵得多
- 忽略校验逻辑，让 IllegalArgumentException 在深层方法中爆发，导致更晚发现、更难定位、更多无效计算已执行
- 用 RuntimeException 包装受检异常（如 throw new RuntimeException(e)）来绕过检查——既失去语义，又没省下开销，还牺牲可维护性
实际优化建议
别纠结“受检 vs 非受检”的性能标签，关注真实行为：
- 避免用异常做正常流程控制（例如不用 IOException 判断文件是否存在，改用 Files.exists()）
- 对高频路径（如解析、校验）优先做防御性检查，防止 RuntimeException 被意外抛出
- 必要时禁用栈轨迹（new MyException("msg").setStackTrace(new StackTraceElement[0])），尤其在自定义业务异常中
- 日志记录异常时，慎用 e.printStackTrace()，改用结构化日志 + 选择性输出关键堆栈帧
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
