异常对象不建议作为单例或缓存变量反复抛出，核心原因是其栈轨迹在构造时即固化，复用会导致堆栈信息始终指向创建位置而非真实抛出点，严重误导问题定位；同时违反异常作为运行时事件通知的设计语义，并引发线程安全风险。

异常对象不建议作为单例或缓存变量反复抛出，核心原因在于：**异常的本质是运行时快照，包含精确的栈轨迹（stack trace），而该轨迹在构造时即固化；重复使用会丢失真实发生位置，误导问题定位。**

栈轨迹在构造时就已冻结

Java中所有异常（Throwable及其子类）在实例化时，会自动调用fillInStackTrace()方法，捕获当前线程的完整调用栈，并保存为内部字段（如backtrace）。这个过程不可逆，也不会因后续复用而更新。

例如：

• 你提前创建一个new IllegalArgumentException("param invalid")并缓存为static final常量；
• 之后在方法A、方法B、方法C中都直接throw cachedException；
• 最终打印的堆栈始终指向“最初创建它的那一行”，而非实际抛出位置——这会让日志和监控完全失效。

违反异常的设计语义

异常不是状态容器，而是**事件通知机制**。它的存在意义是回答三个问题：“发生了什么？”、“在哪里发生的？”、“当时上下文如何？”

复用异常对象相当于用同一张“事故报告单”反复填写不同现场的事故，既掩盖真实根因，也破坏JVM对异常传播路径的跟踪能力。调试时看到的at com.xxx.Service.methodA(Service.java:42)其实是假的，真正出错的可能是Service.java:187。

线程安全与可变状态风险

部分异常（如IOException）支持追加抑制异常（addSuppressed()）、设置原因（initCause()）等操作。若多个线程并发复用同一个异常实例，可能引发竞态：

• 线程1调用e.addSuppressed(e2)；
• 线程2同时调用e.initCause(e3)；
• 结果不可预测，甚至抛出IllegalStateException。

即使不操作这些方法，异常对象本身也不是为并发共享设计的。

性能优化的误区

有人误以为“避免重复创建异常能提升性能”。确实，fillInStackTrace()开销较大，但：

• 异常本就不该高频发生——它是异常流，不是常规控制流；
• 真正耗时的是栈遍历，而非对象分配；现代JVM对短生命周期对象分配极快；
• 用错误方式“优化”导致诊断成本飙升，得不偿失。

若真有高频校验场景（如参数检查），应改用返回码、Optional或自定义非异常状态对象，而非复用异常。