适合单例化的异常需同时满足：不携带动态字段、不依赖栈追踪定位、抛出频率高（qps百级以上）、语义明确且分类固定；实现时应重写fillinstacktrace()返回this，并用静态块或enum初始化。
高频异常路径上反复创建异常对象，会显著加重 GC 压力——因为 Exception 及其子类默认携带完整栈轨迹（fillInStackTrace()），每次构造都分配堆内存、生成大量临时字符串和数组对象。这类异常若具备“可预测性”（如参数校验失败、空值拒绝、业务规则拦截等）且不依赖运行时动态上下文，就属于典型的“热异常”，适合用单例对象复用；而真正需要诊断的底层系统异常（如 IOException、SQLException）仍应保留原始栈信息，归为“冷异常”，按需新建。
哪些异常适合做成单例？
满足以下全部条件的业务异常可考虑单例化：
- 不携带运行时动态字段（如用户ID、订单号等敏感或变化数据）
- 不依赖
fillInStackTrace()定位具体出错行号（例如统一在网关/切面层记录日志，而非靠异常栈追溯） - 抛出频率高（QPS 百级以上）、生命周期短（捕获后立即处理，不跨线程长期持有）
- 语义明确、分类固定（如
InvalidParamException、ResourceNotFoundException）
如何安全实现单例异常？
关键是否定默认栈追踪行为，避免无谓开销：
- 继承目标异常类，重写
fillInStackTrace()方法，直接返回this（跳过栈采集） - 在静态块或
Enum中初始化单例实例，确保线程安全与唯一性 - 若需携带轻量上下文（如错误码），可通过构造函数传入不可变字段，但禁止存入集合、流、连接等资源型对象
- 避免在单例异常中覆盖
getMessage()等方法引入字符串拼接逻辑
实际效果与风险提示
某电商风控接口将 RuleBlockedException 改为单例后，观测到：
- Young GC 频率下降约 18%，每次 GC 回收对象数减少 23%（因少建 3–5 个栈帧数组 + 字符串对象）
- 平均响应延迟降低 0.8ms（主要节省了栈遍历与字符串格式化 CPU 时间）
但需注意：不能用于需要精准定位调用链路的场景。例如日志中仅打印单例异常的 toString()，将始终显示同一行号（即单例初始化位置），失去调试价值。建议配套在全局异常处理器中补充 Thread.currentThread().getStackTrace() 的精简快照，或通过 MDC 注入 traceId 实现可追踪性。
与冷热数据分离理念的对应关系
这本质是把异常对象按访问模式做了冷热划分：
- 热异常：高频抛出、低信息密度、可预测结构 → 单例复用，走“内存常驻+零栈采集”路径
- 冷异常：低频发生、高诊断价值、强上下文绑定 → 每次新建，保留完整栈与动态字段
二者共存于同一系统，由业务语义驱动隔离策略，而非简单按类型硬编码。真正的优化点，不在“是否用单例”，而在“是否理解这条异常路径到底需要什么信息”。
