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字节。
