jvm通过类元数据而非每个对象实例来获知非数组对象的大小，而数组则依赖其额外的长度字段；对象字段访问依赖编译期已知的固定偏移量，无需运行时动态计算大小，但垃圾回收等场景仍需精确尺寸信息。
在Java虚拟机（JVM）的内存模型中，对象在堆上的布局严格遵循规范，但其“可读范围”——即从起始地址开始应读取多少字节——并非由每个对象自身显式携带，而是由类型语义 + 元数据驱动决定。理解这一点，关键在于区分两类实体：普通对象（instance objects） 和 数组对象（array objects）。
一、普通对象：大小由类定义，而非实例存储
每个非数组对象的内存布局包含三部分（以HotSpot为例）：
- Mark Word（8字节，64位开启指针压缩时为4字节）：存储哈希码、锁状态、GC分代年龄等；
- Klass Pointer（4或8字节）：指向该对象所属Klass结构体的指针，即类元数据在方法区的入口；
- Instance Data：按字段声明顺序（受JVM字段重排序与对齐规则影响）存放实际字段值；
- （无独立 size 字段）
⚠️ 重要事实：对象实例本身不保存自身大小。那么JVM如何知道一个 String 或 ArrayList 实例占多少字节？答案是——查它的 Klass。
Klass 是JVM为每个加载类维护的核心元数据结构，其中明确记录了：
// 简化示意（HotSpot源码逻辑）
class InstanceKlass {
int _size_helper; // 实例大小（单位：字长，如8字节/word）
Array<fieldDescriptor>* _fields; // 字段描述符数组，含偏移量、类型、宽度
};当JVM需要计算对象大小（例如在GC复制阶段），它通过对象头中的 klass pointer 快速定位到对应 InstanceKlass，再读取 _size_helper 即得总字节数。字段访问同理：编译器或JIT在生成字节码/机器码时，已将 obj.fieldA 编译为类似 mov rax, [rbx + 12] 的指令——12 是该字段在类布局中的固定内存偏移量，由类加载时字段排序和对齐规则决定，全程无需运行时查大小。
二、数组对象：长度内置于对象头，支持动态尺寸
数组是特例。其对象头在 Mark Word 和 Klass Pointer 后，额外增加一个 length 字段（4字节，int 类型）：
| 组成部分 | 大小（64位+压缩指针） | 说明 |
|---|---|---|
| Mark Word | 4 bytes | 锁/哈希/年龄等 |
| Klass Pointer | 4 bytes | 指向 ArrayKlass |
| Length | 4 bytes | ✅ 显式存储元素个数 |
| Element Data | length × element_size | 如 int[100] → 400 bytes |
因此，JVM访问 arr[i] 时：
- 先读取 length 字段做边界检查（if (i < length) ...）；
- 再根据元素类型计算偏移：base_address + header_size + i * element_byte_size。
这正是为什么 array.length 是O(1)操作——它直接读取对象头中预置的字段，无需遍历或计算。
三、何时真正需要“对象大小”？——不只是读取，更是管理
虽然字段访问不依赖对象总长，但以下关键场景必须精确知道尺寸：
- 垃圾回收（GC）压缩（Compaction）：移动对象时需完整拷贝 size 字节；
- 内存诊断工具（如jmap、JFR）：统计堆占用需逐个对象求和；
- 逃逸分析与栈上分配（Scalar Replacement）：需确认对象能否完全放入栈帧；
- Unsafe.objectFieldOffset() / VarHandle：底层内存操作需安全边界。
此时，JVM统一通过 Klass::size_helper()（普通对象）或 arrayOopDesc::length()（数组）获取，实现高效且一致的尺寸感知。
✅ 总结一句话：
JVM不靠对象“自报家门”获知大小，而是通过类元数据（静态契约） 管理普通对象，靠数组头长度字段（动态契约） 管理数组——设计哲学是：复用性优先于冗余存储，元数据集中优于实例分散。
