Object类方法不直接控制生命周期，但深度参与各阶段：getClass()提供运行时类型元数据；finalize()已弃用，曾提供不确定的终结回调；clone()创建独立生命周期新对象；wait/notify协调线程状态；toString/equals/hashCode影响语义使用与潜在内存泄漏。
Object 类本身不直接控制对象生命周期，但它提供的几个关键方法深度参与了对象从创建、使用到回收各阶段的行为表现，尤其在内存管理、线程协作和对象语义定义上起着底层支撑作用。
getClass() 与对象类型信息的绑定
getClass() 返回运行时类对象（Class>），它在对象创建完成、初始化阶段结束后即可稳定访问。这个方法不改变生命周期，但为反射、序列化、动态代理等机制提供元数据基础——这些机制可能间接触发对象提前创建、延迟释放或跨生命周期引用。例如，通过 ClassLoader 加载类时若持有对象引用，可能延长其可达性时间。
finalize() 曾参与终结阶段，现已弃用
finalize() 是唯一曾被设计用于“对象销毁前回调”的方法，但它实际执行时机不确定，且仅在 GC 判定对象不可达、并完成一次标记-清除循环后才可能调用。JVM 不保证调用、不保证顺序、甚至不保证执行——它只是给对象一次“复活”机会（比如在 finalize 中重新建立强引用）。自 Java 9 起该方法已被标记为 @Deprecated，Java 14 开始默认禁用，推荐用 Cleaner 或 PhantomReference 替代。它的存在曾让开发者误以为能精确控制销毁，实则模糊了生命周期边界。
clone() 影响对象副本的独立生命周期
clone() 创建新对象实例，返回的是一个独立于原对象的新对象。只要实现 Cloneable 接口并重写为 public，调用 clone() 就会触发完整对象创建流程：分配内存 → 初始化零值 → 复制字段 → 执行构造逻辑（浅拷贝不调构造器，深拷贝需手动处理）。这意味着克隆出的对象拥有自己的生命周期起点，与原对象解耦。若未正确处理可变成员（如数组、集合、其他对象引用），可能导致两个生命周期意外共享状态。
立即学习“Java免费学习笔记（深入）”；
wait()/notify()/notifyAll() 协调对象在多线程中的存活状态
这三个方法不改变对象本身的生命周期阶段，但会影响其“是否被线程阻塞等待”这一运行时状态。调用 wait() 会使当前线程释放锁并进入等待队列，对象仍存活；notify() 只是唤醒一个等待线程，不终止对象；而只有当所有线程都不再持有对该对象的强引用，且无其他引用链可达时，GC 才可能回收。它们本质是线程同步工具，但错误使用（如在非同步块中调用、忽略虚假唤醒）会导致线程长期挂起，间接拖慢关联对象的回收节奏。
toString()、equals()、hashCode() 塑造对象的语义生命周期
这三个方法虽不操作内存或线程，却决定了对象如何被外部系统“看待”和“使用”。例如：
- 重写不规范的 equals() + 未同步重写 hashCode()，会导致对象放入 HashMap 后无法被正确查找或删除，造成逻辑上的“内存泄漏”——对象本该被移除却因哈希桶错位而滞留；
- toString() 被日志框架频繁调用，若实现中意外持有了长生命周期对象（如闭包引用外部上下文），可能阻止整个引用链被回收；
- 未重写 toString() 的默认实现包含 hashCode() 值，而 hashCode() 在首次调用后会被缓存（某些 JVM 实现），这虽微小，但在高频短生命周期对象场景下可能增加 GC 压力。
Object 类的方法不是生命周期的开关，而是贯穿始终的语义锚点和行为接口。理解它们何时被谁调用、有何副作用，才能写出既符合 JVM 规则又贴近业务意图的对象。
