java对象生命周期始于类加载而非new，经历加载、链接、初始化三阶段；new仅分配内存并设默认值，实例构造器才完成初始化；对象存活取决于gc roots可达性分析；gc不负责资源释放，需显式关闭。
类加载阶段：不是new的时候才开始
Java对象的生命周期，起点其实是类加载，不是new那一刻。JVM启动后，类在首次主动使用时（比如调用static方法、访问static字段、new实例、反射等）才会触发加载、链接（验证/准备/解析）、初始化三步。其中<clinit></clinit>（类构造器）只执行一次，且是线程安全的。
常见错误现象：ClassNotFoundException或NoClassDefFoundError，往往不是代码写错了，而是类加载失败（比如jar包缺失、双亲委派被破坏、热部署冲突）。
- 使用场景：Web应用中
ServletContextListener里提前触发类初始化，避免首次请求时卡顿 - 参数差异：
-XX:+TraceClassLoading可打印加载日志，-verbose:class更轻量 - 性能影响：类加载本身有IO和字节码校验开销，大量动态生成类（如某些ORM、Mock框架）容易引发元空间（Metaspace）OOM
对象创建与初始化：new ≠ 完全就绪
new指令只是分配内存并设置默认值（0、null、false），真正执行的是<init></init>（实例构造器）——它把super()、字段赋值、构造函数体按顺序合并进来。如果父类构造器里调用了被子类重写的方法，此时子类字段还是默认值，极易出错。
常见错误现象：对象字段为null或0，但代码里明明写了初始化；或者NullPointerException发生在构造器中。
- 使用场景：单例双重检查锁（DCL）必须给实例字段加
volatile，否则可能看到未完全初始化的对象 - 性能影响：逃逸分析开启时（
-XX:+DoEscapeAnalysis），JVM可能栈上分配对象，跳过堆GC流程 - 注意：
Object.clone()不走<init></init>，而是直接复制内存，字段值是原样拷贝
可达性分析与GC Roots：谁决定对象该活该死
对象是否“存活”，不看有没有new过，而看能否从GC Roots（如线程栈帧里的局部变量、静态字段、JNI引用等）出发，通过引用链到达它。只要不可达，下一次GC就可能被回收——哪怕它刚被new出来一秒。
常见错误现象：OutOfMemoryError: Java heap space不一定是内存泄漏，也可能是短生命周期对象暴增（如循环里不断new byte[1024*1024]）；而真正的泄漏常表现为老年代缓慢增长，且Full GC后回收极少。
- 使用场景：缓存用
WeakReference或SoftReference，避免强引用阻止GC；但要注意WeakHashMap的key是弱引用，value仍需手动清理 - 兼容性影响：ZGC/Shenandoah等低延迟GC器对“对象正在被访问”的判断逻辑更复杂，某些基于
finalize()或Cleaner的资源清理可能失效 - 别依赖
finalize()：它不保证执行时机，甚至不保证执行，JDK 9起已标记为@Deprecated
对象终结与内存释放：GC不是万能的
GC只负责堆内存回收，不等于资源释放。文件句柄、数据库连接、DirectByteBuffer底层内存等，都得靠程序员显式关闭。JVM只在GC前可能调用finalize()（已废弃）或Cleaner注册的清理动作，但这些机制不可靠、不可控、有性能开销。
常见错误现象：程序运行久了报java.io.IOException: Too many open files，查代码发现FileInputStream没关；或堆外内存持续上涨，jmap -histo看不到大对象，但jcmd <pid> VM.native_memory summary</pid>显示Internal或Mapped区域飙升。
- 使用场景：必须用try-with-resources包装所有
AutoCloseable资源；DirectByteBuffer建议配合Cleaner（而非finalize）做兜底 - 性能影响：频繁创建
PhantomReference+引用队列轮询，会拖慢GC停顿 - 最容易被忽略的一点：对象被GC后，其持有的其他对象如果还被其他地方引用，那些对象不会因此变“可回收”——可达性分析是全局的，不是级联的
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
