Java数组内存占用计算：对象头与元素空间深度解析

先纠正一个常见误解：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字节）

不复杂，但容易忽略。计算时把这三块分开加一遍，基本不会出错。