类存储于方法区（JDK 8+为元空间），含元数据及堆中的Class对象镜像；对象存储于堆，布局含对象头、实例数据和对齐填充；类卸载极难，对象销毁由GC通过可达性分析自动完成。
类的存储：加载到方法区（或元空间）
类本身不是对象，而是 JVM 运行时的元数据结构。当类首次被主动使用（如 new 实例、调用静态方法、反射等），JVM 通过类加载器完成加载、验证、准备、解析、初始化五步流程。
加载完成后，类的结构信息（常量池、字段、方法、接口、注解等）被存入方法区（JDK 8+ 后为元空间 Metaspace，使用本地内存而非堆内存）。
- 方法区是线程共享区域，随 JVM 启动而创建，通常不参与常规 GC，但元空间会触发 Full GC 或直接扩容失败抛出
OutOfMemoryError: Metaspace - 每个已加载类在方法区中对应一个唯一的
java.lang.Class对象（由 JVM 自动创建），该对象也存于堆中，作为类元数据在堆中的“镜像” - 类卸载条件极苛刻：必须满足“该类所有实例已被回收 + 加载该类的 ClassLoader 已被回收 + 该类的 Class 对象没有被任何地方引用”，极少发生，仅在动态类加载场景（如 OSGi、热部署）中可能触发
对象的存储：分配在堆内存中
对象是类的运行时实例，生命周期从 new 指令开始，全部存储在堆（Heap）中——这是 JVM 最大、线程共享的内存区域，也是垃圾收集器管理的核心区域。
对象在堆中的布局包含三部分：
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 对象头（Object Header）：含 Mark Word（锁状态、GC 分代年龄、哈希码）和类型指针（指向方法区中该类的元数据）
- 实例数据（Instance Data）：按字段宽度和继承顺序排列的成员变量值（基本类型存值，引用类型存指向堆中另一对象的指针）
- 对齐填充（Padding）：保证对象起始地址为 8 字节倍数，提升 CPU 缓存访问效率
例如：User u = new User(); 中，u 是栈中局部变量表里的一个引用（4 或 8 字节指针），new User() 的实际数据结构则完整落在堆中。
对象的销毁：依赖可达性分析与垃圾回收
Java 没有显式的“销毁”语法，对象的消亡完全由垃圾收集器（GC）自动完成。核心逻辑是：当对象不可达（即从 GC Roots 出发无法到达）时，它成为可回收对象。
- GC Roots 包括：虚拟机栈/本地方法栈中引用的对象、方法区中静态属性引用的对象、常量引用的对象、JNI 引用的对象等
- 一旦对象被判定为不可达，它不会立即消失；会在下一次 GC 周期中被标记、清除（或复制、整理），最终其占用的堆内存被释放
- 注意：
finalize()方法（已废弃）或Cleaner等清理机制只提供一次“复活”机会（不推荐使用），不影响可达性判断主流程
类与对象销毁的关键区别
类的卸载几乎不发生，对象的回收频繁且自动化——这是 Java 内存管理设计的根本取向：类是稳定的元信息，对象是易变的运行时实体。
开发者能直接影响的是对象的引用关系（如及时置 null、避免长生命周期容器持有短命对象），从而协助 GC 尽早识别并回收内存；而类的生命周期基本交由 JVM 和类加载器策略控制。
