Mindprod指出，这不是一个容易回答的简单问题：

JVM可以自由地以内部或大端或小端的任何方式存储数据，并具有一定的填充或开销，尽管基元必须表现得好像它们具有官方大小一样。
例如，JVM或本机编译器可能会决定将boolean[]64位长块（如）存储为BitSet。只要程序给出相同的答案，就不必告诉你。

• 它可能会在堆栈上分配一些临时对象。
• 它可能会优化某些变量或方法调用，使其完全不存在，而用常量替换它们。
• 它可能会版本化方法或循环，即编译一个方法的两个版本，每个版本针对特定情况进行了优化，然后预先决定要调用哪个版本。
  然后，当然，硬件和操作系统会在芯片缓存，SRAM缓存，DRAM缓存，普通RAM工作集和磁盘上的后备存储上具有多层缓存。你的数据可能会在每个缓存级别重复。所有这些复杂性意味着你只能非常粗略地预测RAM消耗。

Measurement methods

你可以Instrumentation.getObjectSize()用来获取对象消耗的存储空间的估计值。

要可视化实际的对象布局，覆盖区和引用，可以使用JOL（Java对象布局）工具。

Object headers and Object references

在现代的64位JDK中，对象具有12个字节的标头，填充为8个字节的倍数，因此最小对象大小为16个字节。对于32位JVM，开销为8字节，填充为4字节的倍数。 （从梅德Spikhalskiy的回答，Jayen的回答，和JavaWorld的。）

通常，引用在32位平台或64位平台（不超过-Xmx32G;）上为4个字节。和32Gb（-Xmx32G）以上的8个字节。 （请参阅压缩的对象引用。）

结果，一个64位JVM通常需要30-50％以上的堆空间。（我应该使用32位还是64位JVM？，2012，JDK 1.7）

Boxed types, arrays, and strings

与原始类型（来自JavaWorld）相比，盒装包装具有额外的开销：

Integer：16字节的结果比我预期的要差一些，因为一个int值只能容纳4个额外的字节。Integer与将值存储为原始类型时相比，使用该方法花了我300％的内存开销

Long：也为16个字节：显然，堆上的实际对象大小受特定JVM实现针对特定CPU类型的低级内存对齐的约束。看起来Long是8个字节的对象开销，再加上8个字节的实际long值。相反，Integer有一个未使用的4字节漏洞，这很可能是因为我使用的JVM在8字节字边界上强制了对象对齐。

其他容器也很昂贵：

• Multidimensional arrays：它提供了另一个惊喜。
  开发人员通常采用int[dim1][dim2]数字和科学计算中的构造。

在int[dim1][dim2]数组实例中，每个嵌套int[dim2]数组都是Object独立的。每一个都增加了通常的16字节数组开销。当我不需要三角形或参差不齐的数组时，这表示纯开销。当阵列尺寸大大不同时，影响会增大。

例如，一个int[128][2]实例占用3,600字节。与int[256]实例使用的1,040字节（具有相同的容量）相比，3,600字节代表246％的开销。在的极端情况下byte[256][1]，开销因子几乎为19！将其与C / C ++情况进行比较，在这种情况下，相同的语法不会增加任何存储开销。

• String：String的内存增长跟踪其内部char数组的增长。但是，String该类又增加了24个字节的开销。

对于String大小为10个字符或更少的非空字符，相对于有用的有效负载而言，增加的开销成本（每个字符2个字节，长度4个字节）相对于100％到400％。

Alignment

考虑以下示例对象：

class X {                      // 8 bytes for reference to the class definition
   int a;                      // 4 bytes
   byte b;                     // 1 byte
   Integer c = new Integer();  // 4 bytes for a reference
}

单纯的总和表明的实例X将使用17个字节。但是，由于对齐（也称为填充），JVM以8字节的倍数分配内存，因此它将分配24字节而不是17字节。