Java异常本身不会直接导致内存泄漏，但异常处理不当可能间接引发堆内存问题，如对象无法及时回收、资源未释放、缓存堆积等；其核心在于异常处理方式而非异常对象本身。
Java异常本身不会直接导致内存泄漏，但异常处理不当可能间接引发堆内存问题，比如对象无法被及时回收、资源未释放、缓存堆积等。
异常不占用显著堆内存
抛出异常（如 new RuntimeException()）会创建异常对象，包含堆栈跟踪（StackTraceElement 数组）。默认情况下，JVM 会捕获当前线程的调用栈，生成约几十到几百个栈帧信息。这部分内存开销是临时且可控的——通常单次异常消耗几KB堆内存，对整体影响微乎其微。
注意：Throwable.fillInStackTrace() 是开销主要来源；若重写该方法并禁用（如在自定义异常中直接 return this），可进一步降低开销。
真正影响堆内存的是异常处理方式
以下几种常见模式容易造成堆内存压力或泄漏：
立即学习“Java免费学习笔记（深入）”；
- 在异常分支中持续创建大对象：例如 catch 块里反复 new byte[1024*1024] 或加载大文件，而未限制次数或未清理引用。
- 未关闭资源导致对象长期驻留：比如 InputStream、Connection、ThreadLocal 等，在异常路径下忘记 close() 或 remove()，使关联对象（含缓冲区、连接池句柄等）无法被 GC 回收。
- 异常被吃掉后缓存错误状态：捕获异常却不处理业务逻辑，却把部分初始化失败的对象加入全局缓存或静态集合，形成“半成品”对象堆积。
- 递归/循环调用中频繁抛异常：可能导致栈深度激增、异常对象成批生成，极端情况下触发 OOM（如 StackOverflowError 后又抛 OutOfMemoryError）。
如何验证异常是否影响内存
不要凭感觉判断，建议通过工具定位：
- 用 jstat -gc <pid> 观察 Full GC 频率是否在异常密集发生时段上升；
- 用 jmap -histo:live <pid> 对比异常前后对象实例数，重点关注异常类、日志对象、缓冲容器等；
- 用 VisualVM / JProfiler / Async Profiler 抓取 heap dump，筛选 “java.lang.Exception” 及其子类的实例数量和 retained heap；
- 开启 JVM 参数 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps，结合业务日志分析 GC 与异常时间点是否相关。
基本上就这些。异常不是内存杀手，但它是暴露代码健壮性的一面镜子——关键不在“抛不抛”，而在“怎么捕、怎么清、怎么防”。
