抛出异常不会直接影响Java垃圾回收，GC依据对象可达性进行回收，异常仅改变执行流程而不改变引用状态；如str在catch块中因作用域结束不可访问，其回收与异常无关；若异常导致资源未及时释放，如大对象未置null或静态集合未移除引用，会间接延长对象存活时间，属编程逻辑问题；异常对象本身在不再被引用后可被正常回收，若被保存至静态字段等长生命周期结构则延迟回收；总之异常是正常控制流，合理管理引用即可避免影响内存回收。
抛出异常本身不会直接影响Java的垃圾回收（GC）机制。垃圾回收主要关注对象的可达性，而不是程序中是否发生异常或如何处理异常。
异常与对象生命周期无关
Java的垃圾回收器通过判断对象是否还能被引用（即是否可达）来决定是否回收该对象。抛出异常只是改变了程序的执行流程，并不会改变对象的引用状态。
例如：
try {String str = new String("临时字符串");
throw new RuntimeException("测试异常");
} catch (Exception e) {
// str 超出作用域
}
在这个例子中，str 在 catch 块中已经不可访问，它的生命周期结束是因为作用域结束，而不是因为抛出了异常。一旦没有引用指向这个 String 对象，它就可能在下一次GC时被回收。
立即学习“Java免费学习笔记（深入）”；
异常可能导致资源未及时释放（间接影响）
虽然异常不影响GC的可达性判断，但如果异常导致代码提前跳出，而没有正确清理引用，可能会间接延长对象的存活时间。
比如：
- 在方法中创建了大对象，但抛出异常后没有机会将其置为 null
- 持有对象引用的变量生命周期较长（如静态集合），异常导致添加后未移除
这些情况会让对象继续保持可达状态，从而延迟回收，但这属于编程逻辑问题，不是异常本身的机制问题。
异常对象本身的回收
异常对象（如 new Exception()）和其他对象一样，会在不再被引用后被GC回收。常见场景中，catch 块结束后，异常引用通常就失效了，可以被回收。
需要注意的是：如果将异常对象保存到静态字段、日志上下文或其他长生命周期结构中，它会持续存活，直到引用被清除。
基本上就这些。异常的抛出是正常控制流的一部分，JVM 的垃圾回收机制早已考虑到这类情况，只要合理管理引用，就不会因异常影响内存回收。
