多态对象生命周期判定与普通对象一致，关键看是否从gc roots可达；声明类型不影响可达性，仅引用存在与否决定存活，如animal a = new dog()中a未置null则dog实例存活。
多态对象实例的生命周期判定，和普通对象一样，不因多态性而改变判断逻辑。关键仍是看它是否从 GC Roots 可达——只要存在一条引用链能追溯到该对象，无论其声明类型是父类、接口还是运行时实际类型，它就存活；反之则进入回收候选队列。
多态对象的可达性不受声明类型影响
Java 的可达性分析只关心“有没有引用指向它”，不关心引用变量的编译时类型。例如：
-
Animal a = new Dog();—— 实际创建的是Dog实例，但只要变量a还在作用域内且未置为null，该Dog对象就从栈上局部变量（GC Root）可达； -
List<animal> list = new ArrayList(); list.add(new Cat());</animal>——Cat实例通过list中的元素引用链，从局部变量list（GC Root）可达； - 即使把
a向上转型为Object obj = a;，只要obj仍持有引用，Dog实例依然存活。
多态场景下容易误判不可达的典型情况
真正影响生命周期的，不是多态本身，而是引用管理方式：
- 方法参数传入多态对象后，在方法内部未被保存，方法返回即局部引用消失 → 对象可能立即不可达；
- 将多态对象存入静态集合（如
static Map<string animal> cache</string>），即使局部变量已失效，它仍通过静态字段（GC Root）保持可达； - 使用
WeakReference<animal></animal>包装多态对象，GC 时会无视该弱引用，导致对象提前不可达； - 匿名内部类或 Lambda 捕获了外部多态对象引用，可能延长其生命周期（尤其当内部类被长期持有时）。
finalizer 或 Cleaner 不改变可达性判定逻辑
即使多态对象重写了 finalize() 或注册了 Cleaner，也不会让它“多活一轮”——它仍需先被判定为不可达，才会进入 F-Queue 或待清理队列。而且 finalize() 已被标记为废弃，Cleaner 也仅用于资源清理，不干预可达性分析过程。
验证多态对象是否真的不可达
不能只看变量名或类型，要追踪真实引用路径：
- 用 JVM 工具（如
jmap -histo或 VisualVM）查看堆中实例数量变化； - 配合
-XX:+PrintGCDetails观察 GC 日志中对应类的回收情况； - 在关键位置插入
System.gc()（仅测试用）并配合Runtime.getRuntime().freeMemory()辅助观察，但注意这不保证立即回收。
