先纠正一个常见误解：Java数组的内存占用，并不能简单地用“元素个数 × 单元素大小”来准确计算。它实际由三部分组成：数组对象头、元素数据区，以及为了对齐而填充的字节。计算的前提是64位JVM默认开启了指针压缩（-XX:+UseCompressedOops）；如果堆内存超过32GB，或者你显式关闭了压缩，引用和类指针会翻倍，结果就会完全不同。
数组对象头：比普通对象多占用4字节
数组本质上也是对象，但它比 new Object() 多了一个字段——长度（length）。因此它的对象头固定包含三部分：
- Mark Word：8字节，存放哈希码、锁状态、GC年龄等运行时信息
- Klass Pointer：4字节（指针压缩启用时），指向元空间中的类定义
- Array Length：4字节，仅数组独有，记录
length值
合计16字节。这是所有数组的起点，与你里面存什么类型无关。
元素数据区：按类型严格累加计算
这一部分是真正存储数据的地方，大小 = 数组长度 × 单元素字节数。注意区分基本类型和引用类型：
- 基本类型数组：没有额外开销。例如
int[5]→ 5×4=20字节；long[3]→ 3×8=24字节 - 引用类型数组：只计算引用本身（4字节/个），不包括它指向的对象。比如
String[10]的元素区是10×4=40字节；每个String对象另算（通常24–40+字节）
另外，字段排列遵循自然对齐规则（比如 long 对齐到8字节边界），但数组元素是连续同构的，不涉及内部字段重排，因此无需考虑字段间的填充。
对齐填充：凑整到8字节倍数
JVM要求每个对象总大小必须是8的倍数，这能提升CPU缓存访问效率。填充只发生在最后，补足即可：
- 公式：
padding = (8 - (header + data) % 8) % 8 - 举个例子：
int[2]→ 头16B + 数据8B = 24B → 24%8==0 → 填充0B - 再比如：
byte[1]→ 头16B + 数据1B = 17B → 补7B → 总24B
常见误区是误以为每个字段后面都要补，其实只在对象末尾一次性补齐。
典型示例手算验证
以 new int[3] 为例（64位 + 指针压缩）：
- 对象头：16字节（8+4+4）
- 元素区：3×4=12字节
- 当前和：16+12=28字节
- 对齐：28→向上取整到8的倍数是32，需填充4字节
- 最终：32字节
再看 new Integer[1]（注意是包装类数组）：
- 对象头：16字节
- 元素区：1×4=4字节（仅存一个
Integer引用） - 当前和：20字节→补4字节→总24字节
- ⚠️ 这还不包括那个
Integer对象本身（它另占约16字节）
不复杂，但容易忽略。计算时把这三块分开加一遍，基本不会出错。
