怎么排查由于两个强业务实体在堆内相互强引用且生命周期游离的泄漏-java教程-PHP中文网

这是典型的循环强引用导致的内存泄漏，因对象脱离业务上下文后仍被静态集合、监听器、缓存等长生命周期结构意外持有，需通过mat分析gc roots路径并结合日志与弱引用优化解决。

怎么排查由于两个强业务实体在堆内相互强引用且生命周期游离的泄漏

这种情况属于典型的“循环强引用+无明确生命周期管理”导致的内存泄漏，Java 的可达性分析（GC Roots）无法回收这类对象，因为它们彼此持有强引用，又未被任何 GC Root 直接或间接引用——但又没被业务逻辑主动释放。关键不在于“能不能被 GC”，而在于“该不该被 GC 却一直活在堆里”。排查重点是确认它们是否已脱离业务上下文，却仍被某个长生命周期容器或静态结构意外持有着。

确认是否真为游离循环引用泄漏

先排除误判：两个对象互相引用本身不会导致泄漏，只有当它们整体已无业务用途、本该被回收，却因外部强引用链存活时，才算泄漏。

检查它们是否被静态集合、缓存、监听器列表、单例服务、线程局部变量（ThreadLocal）、未关闭的资源包装类等长期持有
用 MAT 打开 heap dump，筛选这两个类的实例，查看 “Merge Shortest Paths to GC Roots” —— 不勾选 “exclude weak/soft/phantom references”，看是否有非预期的强引用路径（比如 static Map → 某 Service → listenerList → EntityA → EntityB → EntityA）
对比多个时间点的 heap dump，观察这两类实例数是否持续增长，且 Retained Heap 稳步上升

定位隐藏的强引用持有者

游离往往意味着“没人记得它还活着”。真正的问题常藏在看似无害的中间层：

检查所有注册中心、事件总线（如 Spring ApplicationEventPublisher + Listener）、RPC 客户端回调容器——这些地方常以 Map> 形式缓存监听关系，若 EntityA 实现了 Listener 接口但未显式注销，就会滞留
审查自定义缓存工具类：是否用了 static ConcurrentHashMap 且 key 是 EntityA 的实例（而非 ID），导致整个对象图被锁死
排查 AOP 代理或序列化框架（如 FastJSON、Jackson）的全局配置：某些反序列化策略会缓存 Class -> Deserializer 映射，若 EntityA 含复杂嵌套或自定义反序列化逻辑，可能引发间接持有

验证与修复的关键动作

不要只改代码，要让行为可观察、可验证：

在 EntityA 和 EntityB 的构造/销毁处加日志（或使用 Arthas watch 命令监控 new 和 finalize 调用），确认创建后是否真有对应清理动作
将 EntityA 和 EntityB 改为弱引用持有对方（如 WeakReference），仅当业务逻辑明确需要双向访问时才临时 get()；避免强引用闭环
若必须强引用，引入显式生命周期契约：例如定义 dispose() 方法，在业务流程终点统一调用，并配合 try-finally 或 try-with-resources 封装