jvm 通过类元数据获取非数组对象的固定大小，而数组则依赖其独立的长度字段；对象字段访问依赖编译期已知的偏移量，无需运行时动态计算大小，但垃圾回收等场景仍需精确对象尺寸。
在 JVM 内存模型中，对象布局（Object Layout）是理解内存访问机制的关键。每个 Java 对象在堆中由三部分组成：对象头（Header）、实例数据（Instance Data） 和 对齐填充（Padding）。其中对象头又细分为 Mark Word（存储哈希码、锁状态、GC 分代年龄等）和 Klass Pointer（指向类元数据的指针）。对于数组对象，对象头还额外包含一个 Array Length 字段（4 字节或 8 字节，取决于平台与数组长度范围）。
关键在于：非数组对象的大小是类级别的静态属性。JVM 在类加载阶段即通过 ClassFile 解析出所有实例字段的类型、顺序与对齐要求，结合虚拟机规范（如 -XX:+UseCompressedOops 等选项），在方法区（Metaspace）中为该类缓存一个精确的 instance size（以字节为单位）。例如：
public class Point {
private int x;
private int y;
}在 64 位 JVM 启用压缩指针（默认）且无特殊对齐配置下，Point 实例的对象头占 12 字节（Mark Word 8B + Klass Ptr 4B），两个 int 字段共 8 字节，加上 4 字节对齐填充，总大小为 24 字节。该值被固化在 InstanceKlass 结构中，所有 Point 实例共享同一尺寸——因此 JVM 无需在每个对象中重复存储大小信息，仅凭 klass pointer 即可查得。
相比之下，数组对象必须携带长度信息：int[] arr = new int[100]; 的对象头中明确保存 length = 100，JVM 依此计算总内存占用：12B（头） + 4B（length） + 100×4B（元素） + padding。这也解释了为何数组访问（如 arr[i]）必须执行边界检查（bounds check）——而普通对象字段访问（如 p.x）直接通过预计算的固定偏移量完成，例如 x 字段在 Point 中的偏移量可能是 16，JVM 直接执行 load_int [base + 16]，无需知道整个对象多长。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
值得注意的是，虽然字段访问不依赖对象总大小，但某些运行时操作却高度依赖它：
- 垃圾回收（尤其是 G1/Parallel/Serial 的压缩式 GC）：移动对象时必须完整复制从起始地址到末尾的所有字节，缺一不可；
- Unsafe.copyMemory 或序列化框架：需准确界定对象内存边界；
- 调试器与 JFR（Java Flight Recorder）：需要精确计算对象占用空间以生成内存快照。
因此，JVM 并非“不需要”非数组对象的大小，而是将它从实例级下沉到类级存储，实现空间与性能的双重优化。开发者可通过 jol（Java Object Layout）工具验证实际布局：
mvn org.openjdk.jol:jol-cli:0.16:run -Dexec.args="org.sample.Point"
总结：JVM 不靠对象头“自描述”大小，而是通过 klass pointer → 类元数据 → 预计算 size 的间接路径获取非数组对象尺寸；数组则因动态性必须显式携带 length 字段。这种设计兼顾了内存效率、访问速度与运行时灵活性。
