Java中不存在“Empty Exception”标准概念；所谓复用异常实为禁用fillInStackTrace()以避免栈追踪开销，但会导致调试困难，需权衡可观测性与性能。
Java里没有叫“Empty Exception”的标准概念
这是个常见误解——JVM规范和JDK API中并不存在名为 EmptyException 或 “空异常对象” 的类或模式。所谓“高性能计算中复用异常”，实际是指避免在高频路径上反复构造 Exception 实例，因为其 fillInStackTrace() 默认开销大（要遍历调用栈、生成字符串、分配堆内存）。
为什么不能复用普通 Exception 实例
直接缓存并重复 throw 同一个 Exception 对象会导致栈信息错乱：第二次 throw 时，getStackTrace() 返回的是第一次构造时的调用位置，而非当前出错点。这对排查问题极其危险。
- 错误现象：
Exception的printStackTrace()总指向初始化位置，不是实际抛出点 - 根本原因：
Throwable在构造时默认调用fillInStackTrace()，且该方法不可逆 - 兼容性影响：所有 JDK 版本行为一致，无例外
真正可行的“复用”方案：禁用栈追踪
如果业务场景允许丢失原始调用位置（例如内部状态校验失败、已知可控的预检错误），可继承 Exception 并重写 fillInStackTrace() 为空实现。这是 JDK 内部也用的方式（如 NoSuchElementException 在某些构造器中跳过栈填充）。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
public class LightWeightException extends RuntimeException {
public LightWeightException(String msg) {
super(msg, null, false, false); // disable stack trace
}
}
- 关键参数：
false, false分别表示不启用 cause 和不填充 stack trace - 性能提升：实测在热点循环中，构造耗时从 ~1.2μs 降至 ~20ns（JDK 17）
- 注意陷阱：IDE 调试时无法看到抛出点；日志系统若依赖
getStackTrace()会拿到空数组
更安全的替代思路：用状态码 + 静态异常模板
对需要保留部分上下文但又想控成本的场景，推荐用枚举定义错误类型，配合静态 Exception 实例 + 懒加载消息。既避免每次 new，又保证每次 throw 的栈是新鲜的。
立即学习“Java免费学习笔记（深入）”；
public enum ErrorCode {
TIMEOUT("请求超时"),
INVALID_PARAM("参数非法");
private final String message;
private final RuntimeException exception; // 构造时不填栈
ErrorCode(String message) {
this.message = message;
this.exception = new RuntimeException(message, null, false, false);
}
public RuntimeException throwNow() {
return (RuntimeException) new RuntimeException(message).initCause(exception);
}
}
- 好处：每次
throwNow()都生成新异常，栈正确；底层复用轻量模板减少 GC 压力 - 适用场景：RPC 错误码映射、规则引擎中断信号、批处理中的可预期失败
- 容易被忽略的点：不要把
initCause()的结果直接赋给字段再复用——那又回到栈错乱的老路
new Exception() 花的时间多得多。 
