Mindprod指出，这不是一个容易回答的简单问题：
JVM可以自由地以内部或大端或小端的任何方式存储数据，并具有一定的填充或开销，尽管基元必须表现得好像它们具有官方大小一样。 例如，JVM或本机编译器可能会决定将boolean[]64位长块（如）存储为BitSet。只要程序给出相同的答案，就不必告诉你。
你可以Instrumentation.getObjectSize()用来获取对象消耗的存储空间的估计值。
要可视化实际的对象布局，覆盖区和引用，可以使用JOL（Java对象布局）工具。
在现代的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）
与原始类型（来自JavaWorld）相比，盒装包装具有额外的开销：
Integer：16字节的结果比我预期的要差一些，因为一个int值只能容纳4个额外的字节。Integer与将值存储为原始类型时相比，使用该方法花了我300％的内存开销
Long：也为16个字节：显然，堆上的实际对象大小受特定JVM实现针对特定cpu类型的低级内存对齐的约束。看起来Long是8个字节的对象开销，再加上8个字节的实际long值。相反，Integer有一个未使用的4字节漏洞，这很可能是因为我使用的JVM在8字节字边界上强制了对象对齐。
其他容器也很昂贵：
在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大小为10个字符或更少的非空字符，相对于有用的有效负载而言，增加的开销成本（每个字符2个字节，长度4个字节）相对于100％到400％。
考虑以下示例对象：
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字节。
602392714
清零编程群