Java对象创建发生在new、反射、反序列化或代理时，非类加载时；类加载仅初始化静态成员；构造方法执行是对象创建的明确信号；Unsafe.allocateInstance()绕过构造导致未初始化；finalize()已弃用，应使用Cleaner或虚引用；Spring Bean生命周期由容器控制，与JVM对象生命周期正交；GC只回收堆内存，非堆资源需显式释放。
Java对象的创建时机由new和类加载共同决定
Java对象不是在类加载时就创建的，而是在执行 new 操作符、反射调用 Constructor.newInstance()、反序列化（ObjectInputStream.readObject()）或使用某些框架代理（如Spring CGLIB）时才真正实例化。类加载（ClassLoader.loadClass()）只加载字节码并初始化静态成员，不触发实例构造。
常见误解是“类加载 = 对象创建”，结果在静态代码块里误写耗资源逻辑，导致类首次加载就卡顿或失败。例如：
static {
// ❌ 错误：这里不是对象创建，但可能被当成“初始化对象”来写
databaseConnection = connectToDB(); // 类加载时就执行，哪怕从不 new 这个类
}
- 对象创建的唯一明确信号是构造方法（
public MyClass()）开始执行 - 如果用了
Unsafe.allocateInstance()，则绕过构造方法——对象已分配内存但未初始化，字段全为默认值（null/0/false），极易引发 NPE - Lombok 的
@RequiredArgsConstructor生成的构造器不会自动处理final字段的延迟初始化，需确保传入非 null
finalize() 已被弃用，替代方案是Cleaner或虚引用
finalize() 自 Java 9 起标记为 @Deprecated(forRemoval = true)，JVM 不保证调用时机，甚至可能完全不调用。它还会拖慢 GC，因为需要额外的引用队列处理和二次标记。
正确做法是用 Cleaner（Java 9+）配合虚引用管理非堆资源：
立即学习“Java免费学习笔记（深入）”；
private static final Cleaner cleaner = Cleaner.create();
private final Cleaner.Cleanable cleanable;
private Resource() {
this.cleanable = cleaner.register(this, new ResourceCleaner());
}
private static class ResourceCleaner implements Runnable {
@Override
public void run() {
releaseNativeHandle(); // 显式释放文件句柄、内存映射等
}
}
-
Cleaner不依赖 GC 周期，注册后由 JVM 后台线程异步触发，更可控 - 不要在
Runnable中访问对象字段——此时对象可能已被回收，仅适合清理外部资源 - 若必须兼容 Java 8，改用
PhantomReference+ReferenceQueue手动轮询，但实现复杂且易漏
Spring Bean 的生命周期 ≠ Java 对象生命周期
Spring 容器管理的是“Bean 实例”，其生命周期由容器控制，与 JVM 的对象创建/销毁机制正交。一个 @Component 类被 new 出来后，若未交给 Spring 管理（比如用 new MyService() 手动创建），那么它的 @PostConstruct、InitializingBean.afterPropertiesSet()、@PreDestroy 全部不会执行。
-
@Scope("prototype")的 Bean：每次context.getBean()都触发完整生命周期回调，但销毁回调（@PreDestroy）**不会自动调用**，需手动调用ConfigurableApplicationContext.close()或显式调用销毁方法 -
DisposableBean.destroy()和@PreDestroy只在容器关闭或 Bean 被显式移除时触发，不是 GC 触发的 - 若 Bean 内部持有线程、NIO Channel、MappedByteBuffer，必须在销毁回调中释放，否则造成资源泄漏——GC 不会帮你关 socket
对象真的“销毁”了吗？GC 只回收内存，不等于资源释放
JVM 的垃圾回收只负责堆内存回收，对文件描述符、数据库连接、DirectByteBuffer 底层内存、GPU 显存等非堆资源无感知。这些资源必须显式释放，否则即使对象被 GC，资源仍持续占用。
-
ByteBuffer.allocateDirect()分配的内存不受 GC 控制，依赖Cleaner或sun.misc.Unsafe.freeMemory()（不推荐） - 使用 try-with-resources 时，确保
AutoCloseable.close()方法是幂等且线程安全的；若 close 抛异常，后续资源可能未释放 - 弱引用（
WeakReference）和软引用（SoftReference）不影响 GC 判定，但它们的get()返回 null 后，原对象若还有其他强引用，就不会被回收——别以为“放进了 WeakReference 就安全了”
最常被忽略的一点：对象字段中持有的第三方 SDK 实例（比如 Netty 的 EventLoopGroup、Elasticsearch 的 RestHighLevelClient）往往自带生命周期管理，必须按其文档显式 shutdown()，而不是指望 GC。
