Java中对象创建有四种方式：new、反射（Constructor.newInstance）、Class.forName().newInstance（已过时）、反序列化（ObjectInputStream.readObject）；对象进入可回收状态取决于根可达性分析，不可达即待回收；finalize已废弃，应使用Cleaner或PhantomReference；对象销毁无确定时间点，资源须显式释放。
对象什么时候被创建：new、反射、反序列化都算
Java里对象创建不止 new 一种方式。最常见的是 new MyClass()，但还有三种容易被忽略的途径：
-
Class.forName("MyClass").newInstance()（已过时，推荐用getDeclaredConstructor().newInstance()） -
Constructor.newInstance()—— 反射创建，绕过构造函数访问控制 - 反序列化：
ObjectInputStream.readObject()，不调用任何构造方法，直接分配内存并填充字段
注意：通过反射或反序列化创建的对象，如果类定义了私有构造函数或禁用了默认构造器，仍可能成功（JVM 层面允许），这和 new 的语义不同。
对象何时进入可回收状态：引用计数早被淘汰，得看可达性分析
Java 不用引用计数，而是用根可达性（GC Roots）判断。一个对象只要从 Thread、static 字段、本地栈变量、JNI 引用等 GC Roots 出发无法到达，就视为“不可达”，进入可回收状态。
常见误判场景：
立即学习“Java免费学习笔记（深入）”；
-
static Map<string object> cache = new HashMap();</string>—— 忘记清理会导致对象长期存活，哪怕业务逻辑早已不用 - 内部类隐式持有外部类引用，比如
new Thread(() -> { doSomething(); }).start();中的 lambda 如果捕获了外部this，可能延长外部实例生命周期 - 使用
ThreadLocal后没调用remove()，在线程池复用场景下会引发内存泄漏
finalize() 已被废弃，替代方案是 Cleaner 或 PhantomReference
finalize() 在 JDK 9 被标记为 @Deprecated，JDK 18 彻底移除。它不可靠、性能差、无法保证执行时机，甚至可能阻止 GC 回收。
现代替代方式只有两个实际可用路径：
- 用
Cleaner（JDK 9+）注册清理逻辑，例如释放 native 内存或关闭文件句柄：private static final Cleaner cleaner = Cleaner.create(); private final Cleaner.Cleanable cleanable; private final FileDescriptor fd; MyResource(FileDescriptor fd) { this.fd = fd; this.cleanable = cleaner.register(this, new CleanupAction(fd)); } - 用
PhantomReference+ReferenceQueue做更底层的资源跟踪，但需自行管理队列轮询，适合框架作者，普通业务极少需要
别再写 protected void finalize() throws Throwable —— 编译器不会报错，但运行时不会调用。
对象真正销毁的时间点：GC 触发后也不一定立刻回收
“销毁”在 Java 中没有明确时间点。对象变为不可达后，只表示“可以被回收”。是否回收、何时回收，完全取决于 GC 算法和 JVM 参数：
- G1 默认在混合 GC 阶段处理老年代部分区域，不是所有不可达对象都会在这次被清掉
- ZGC 和 Shenandoah 是并发收集器，对象可能在应用线程还在读写时就被标记为待回收，但内存真正归还给操作系统可能延迟数秒甚至更久
- 即使触发了
System.gc()，也仅是建议，HotSpot 默认配置下大概率被忽略（尤其在 Server VM）
真正要注意的不是“销毁时间”，而是“资源释放时机”。文件、Socket、DirectByteBuffer 这些必须显式 close() 或 clean()，不能依赖 GC。
