频繁抛出捕获异常会加重jvm垃圾回收压力，因异常对象创建时默认采集完整堆栈跟踪并占用堆内存，导致minor gc频次上升、异常对象晋升老年代加剧full gc风险，并可能引发元空间oom。
频繁抛出和捕获异常会显著加重JVM垃圾回收压力，核心原因在于异常对象的创建、堆内存占用以及后续GC行为的连锁反应。
异常对象本身消耗堆内存
每次抛出异常（如 new RuntimeException() 或 throw new NullPointerException()），JVM 都会创建一个完整的异常实例。这个对象不仅包含基础字段，还默认采集当前线程的完整堆栈跟踪（stack trace），通常包含数十甚至上百帧方法调用信息。这些数据全部分配在堆内存中，且多数属于“短生命周期但体积不小”的对象。
- 堆栈跟踪信息以字符串数组、类引用、方法句柄等形式存在，占用可观空间
- 即使空异常（
new Exception()）也会触发fillInStackTrace()，生成并缓存调用链 - 若异常被频繁复用（如静态异常单例），虽可缓解，但违背异常语义，不推荐
触发更频繁的 Minor GC 和晋升压力
大量异常对象集中在 Eden 区快速分配，很快填满 Eden，导致 Minor GC 频次上升。而异常对象往往“存活一两个 GC 周期后就不再被引用”，本该快速回收——但实际中：
- 部分异常被日志框架捕获后长期持有（如 SLF4J 的 MDC、异步日志队列），延长生命周期
- 异常对象引用了 Class、StackTraceElement 等元数据，间接拖慢回收速度
- Minor GC 后未回收的异常对象可能因年龄阈值到达而晋升到老年代，污染老年代空间
间接加剧 Full GC 风险
当异常引发的临时对象持续涌入，叠加业务对象增长，容易造成：
- 老年代因异常对象晋升 + 其他长生命周期对象共同堆积，触发 Metaspace 或老年代内存告警
- GC 日志中出现
Metadata GC Threshold或Allocation Failure后紧接 Full GC - Full GC 停顿时间拉长，业务线程卡顿，进一步掩盖真实瓶颈，形成恶性循环
与类加载器、元空间的隐性耦合
某些异常（如 NoClassDefFoundError、ClassNotFoundException）的抛出，常伴随动态类加载失败。而反复加载/卸载失败的类，会导致：
- 元空间持续增长，尤其在使用自定义类加载器（如 OSGi、热部署框架）时
- 类加载器无法被回收 → 其加载的所有 Class 对象及关联的常量池、方法区数据滞留
- 最终表现为元空间 OOM，但根源可能是异常驱动的错误类加载模式
本质上，异常不是“免费的控制流机制”。把它当普通 if-else 用，等于主动向堆里倾倒带堆栈的垃圾。真正该做的，是把异常留给**意外情况**，对可预期的分支（如参数校验失败、资源不存在）改用返回值或状态码处理。
