java不建议复用异常对象以降低gc开销，因其fillinstacktrace()开销大、栈信息与创建时刻强绑定，复用会掩盖真实错误位置；异常语义是信号而非数据载体，且生命周期短、gc压力微乎其微。
异常对象单例化复用不是标准的 GC 优化手段，Java 中 不建议、也不支持复用异常对象来降低 GC 开销。原因很直接：异常对象（如 Exception、RuntimeException 及其子类）在创建时会自动捕获当前线程栈轨迹（stack trace），调用 fillInStackTrace() 方法。这个过程开销大、不可忽略，且栈信息与创建时刻强绑定——复用会导致错误的堆栈指向，掩盖真实问题，破坏可观测性与调试能力。
为什么不能把异常当普通对象池化？
异常的核心语义是“意外状态的信号”，不是数据载体或工具对象：
- 每次 new Exception() 都生成全新、准确的调用链；复用后 stack trace 固定，日志和监控中无法定位真实出错位置
- JVM 对异常有特殊处理（如 HotSpot 的栈展开优化），强制复用可能干扰 JIT 编译器行为
- 异常对象通常生命周期极短（抛出即销毁），占 GC 压力比例微乎其微；真正造成 GC 压力的是业务中高频创建的 数据对象（如 String、DTO、List 元素等），而非异常本身
真正有效的 GC 减负方向
聚焦高产垃圾源，而非异常：
-
避免无意义异常驱动流程：不用 try-catch 包裹正常控制流（例如用 NumberFormatException 判断字符串是否为数字），改用正则或
Integer.parseInt()+Optional封装 -
重用可复用的非异常对象：用
ThreadLocal<stringbuilder></stringbuilder>、对象池（如 Apache Commons Pool）、基本类型集合（Eclipse Collections）替代循环内反复 new -
减少装箱与临时包装：用
int[]替代List<integer></integer>，尤其在十亿级数值计算场景，内存节省可达 40%+ - 启用 G1 并调优参数：-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:InitiatingHeapOccupancyPercent=35，让 GC 更早、更细粒度介入，避免老年代堆积触发 Full GC
如果真想“省异常开销”，只有一种安全做法
对完全不关心堆栈信息的运行时断言场景（如内部校验开关关闭时跳过），可用静态 final 异常实例，但必须满足两个前提：
- 该异常永不被实际 throw（仅用于 instanceof 判断或占位）
- 或仅用于日志告警（如
LOG.warn("xxx", DUMMY_EXCEPTION)），且明确接受堆栈无意义
示例（仅作说明，非常规推荐）：
private static final RuntimeException DUMMY_EXCEPTION = new RuntimeException() {@Override public Throwable fillInStackTrace() { return this; }
};
这种写法绕过栈填充，但代价是彻底丢失诊断价值。生产环境应优先保证可观测性，而不是为毫秒级创建开销牺牲可维护性。
