Java继承本身不致内存泄漏，但父类中静态集合、全局注册或子类钩子方法误传this等不当引用管理会延长子类对象生命周期；排查需聚焦GC Roots路径中继承链上的强引用持有方。
Java 继承关系本身不会直接导致内存泄漏，但继承结构常被用作“容器”或“持有者”，容易放大某些引用管理不当的问题——比如父类持有了子类实例的强引用、模板方法中未清理的回调、或抽象基类中静态/长生命周期字段误存子类对象。排查重点不在“继承语法”，而在“谁在什么生命周期里攥着谁”。
看父类字段是否引入长生命周期引用
继承带来的风险常藏在父类的成员变量里。尤其当父类是单例、工具类、监听器基类或框架抽象类时，它的字段可能意外延长子类对象的存活时间。
- 检查父类中是否有 static 集合、缓存、监听器列表，且子类实例被 add 进去后从未 remove
- 关注父类构造器或 init 方法中是否注册了子类对象到全局事件总线、线程池、定时任务等外部容器
- 留意父类是否重写了
finalize()或使用了 Cleaner，但未正确释放子类持有的资源（如文件句柄、NIO Buffer）
查子类对父类钩子方法的实现是否造成循环引用
模板方法模式（如 Spring 的 InitializingBean、AbstractExecutorService 子类）中，子类实现的钩子方法若保存了 this 引用到静态上下文或异步执行器，就可能切断 GC 路径。
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 搜索子类中重写的
onStart()、init()、afterPropertiesSet()等方法，看是否将this传给了静态工厂、全局线程池、ScheduledExecutorService 或第三方 SDK 的 register 接口 - 检查子类是否在父类提供的回调接口中创建了匿名内部类或 lambda，并隐式捕获了外部子类实例（例如：父类调用
doAsync(() -> handle())，而handle()是子类方法）
分析堆转储时聚焦“继承链上的 GC Root 路径”
MAT 中不能只看类名，要顺着引用链看“是谁、以什么身份、通过哪一级继承关系把子类实例钉在内存里”。
立即学习“Java免费学习笔记（深入）”；
- 定位一个典型的子类实例（如
OrderServiceV2），右键 → Path to GC Roots → exclude weak/soft references - 如果路径终点是
com.xxx.base.ServiceManager.INSTANCE.services，说明父类 ServiceManager 的静态集合在 hold 它 - 如果路径经过
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask→lambda$submit$0→ 某个子类对象，说明异步任务没结束，子类无法回收
代码审查时盯紧“父子协作边界”
继承不是黑盒复用，而是契约协作。泄漏常发生在契约被破坏的地方：
- 父类声明了
protected void onDestroy()，但子类没重写，导致资源未释放 - 父类提供
addListener(Listener l)，但没配套removeListener()，子类注册后无处注销 - 子类重写
equals()/hashCode()时用了父类未初始化的字段，导致缓存失效、对象堆积
