Java异常链本身不导致内存泄漏，但被静态或长生命周期对象持有时会阻止整条链及关联对象回收；需避免异常持有业务对象、使用弱引用、精简堆栈、及时释放资源并监控Throwable实例增长。
java中异常链传递本身不会直接导致内存泄漏，但若异常对象被不当持有（尤其是长生命周期容器或静态上下文），就可能让整条异常链及其引用的堆对象无法回收。防止的关键在于控制异常对象的生命周期和引用强度，而非异常机制本身。
避免异常对象被静态或长生命周期对象长期持有
异常对象常携带堆栈跟踪、消息字符串，甚至捕获的上下文对象（如通过initCause()或构造函数传入）。一旦被静态集合、单例缓存、全局日志处理器等长期持有，整个异常链及其引用的对象都会滞留内存。
- 不要将异常实例存入静态Map/Queue/List中，除非明确设置了过期策略或弱引用包装
- 日志框架中若启用“异常快照”或“错误上下文持久化”，需确认其内部是否使用WeakReference或限制缓存大小
- 自定义异常类避免持有业务对象（如User、Request等）作为字段；若必须持有，考虑用WeakReference包装
谨慎处理嵌套异常与循环引用
手动构建异常链时（如new RuntimeException("msg", cause)），若cause本身又引用了当前异常（例如在回调中误传this），会形成循环引用。虽然现代GC能处理简单循环，但配合其他强引用仍可能阻碍回收。
- 避免在异常构造中传入this、外部类实例或持有大量状态的对象
- 检查第三方库是否在异常中隐式保存上下文（如某些RPC框架会把Request对象塞进异常的
suppressed或cause） - 使用
Throwable.setStackTrace(new StackTraceElement[0])精简无用堆栈（尤其测试或监控场景），减少内存占用
资源型异常要配合try-with-resources切断引用链
当异常由未关闭资源触发（如SocketException关联着未释放的Channel），异常对象可能间接持有所属资源的引用。此时仅捕获异常不够，必须确保资源本身已被释放，否则异常链成了“泄漏代理”。
- 所有实现
AutoCloseable的资源必须用try-with-resources，不依赖异常是否发生 - 不要在catch块中重新抛出原始异常的同时保留对资源的强引用（例如把流对象存为字段再throw）
- 若需在异常中透传资源状态，只提取必要字段（如URL、ID），而非整个资源实例
监控与验证异常相关泄漏点
异常泄漏往往隐蔽：Heap Dump中常见java.lang.Exception或子类实例数异常增长，且多数被static字段或线程局部变量（如ThreadLocal）引用。
立即学习“Java免费学习笔记（深入）”；
- 用MAT分析时筛选
java.lang.Throwable子类，查看支配树（Dominators Tree）中谁在强引用它们 - 检查
ThreadLocal变量是否意外存了异常（尤其异步任务中未清理的上下文） - 在关键模块上线前，开启JVM参数
-XX:+PrintGCDetails并观察Full GC后Throwable类实例是否持续增长
