Is the memory space consumed by one object with 100 attributes the same as that of 100 objects, with one attribute each?
How much memory is allocated for an object?
How much additional space is used when adding an attribute?
Mindprod points out that this is not a straightforward question to answer:
A JVM is free to store data any way it pleases internally, big or little endian, with any amount of padding or overhead, though primitives must behave as if they had the official sizes.
For example, the JVM or native compiler might decide to store aboolean[]
in 64-bit long chunks like aBitSet
. It does not have to tell you, so long as the program gives the same answers.
- It might allocate some temporary Objects on the stack.
- It may optimize some variables or method calls totally out of existence replacing them with constants.
- It might version methods or loops, i.e. compile two versions of a method, each optimized for a certain situation, then decide up front which one to call.
Then of course the hardware and OS have multilayer caches, on chip-cache, SRAM cache, DRAM cache, ordinary RAM working set and backing store on disk. Your data may be duplicated at every cache level. All this complexity means you can only very roughly predict RAM consumption.
You can use Instrumentation.getObjectSize()
to obtain an estimate of the storage consumed by an object.
To visualize the actual object layout, footprint, and references, you can use the JOL (Java Object Layout) tool.
In a modern 64-bit JDK, an object has a 12-byte header, padded to a multiple of 8 bytes, so the minimum object size is 16 bytes. For 32-bit JVMs, the overhead is 8 bytes, padded to a multiple of 4 bytes. (From Dmitry Spikhalskiy's answer, Jayen's answer, and JavaWorld.)
Typically, references are 4 bytes on 32bit platforms or on 64bit platforms up to -Xmx32G
; and 8 bytes above 32Gb (-Xmx32G
). (See compressed object references.)
As a result, a 64-bit JVM would typically require 30-50% more heap space. (Should I use a 32- or a 64-bit JVM?, 2012, JDK 1.7)
Boxed wrappers have overhead compared to primitive types (from JavaWorld):
Integer
: The 16-byte result is a little worse than I expected because anint
value can fit into just 4 extra bytes. Using anInteger
costs me a 300 percent memory overhead compared to when I can store the value as a primitive type
Long
: 16 bytes also: Clearly, actual object size on the heap is subject to low-level memory alignment done by a particular JVM implementation for a particular CPU type. It looks like aLong
is 8 bytes of Object overhead, plus 8 bytes more for the actual long value. In contrast,Integer
had an unused 4-byte hole, most likely because the JVM I use forces object alignment on an 8-byte word boundary.
Other containers are costly too:
Multidimensional arrays: it offers another surprise.
Developers commonly employ constructs likeint[dim1][dim2]
in numerical and scientific computing.In an
int[dim1][dim2]
array instance, every nestedint[dim2]
array is anObject
in its own right. Each adds the usual 16-byte array overhead. When I don't need a triangular or ragged array, that represents pure overhead. The impact grows when array dimensions greatly differ.For example, a
int[128][2]
instance takes 3,600 bytes. Compared to the 1,040 bytes anint[256]
instance uses (which has the same capacity), 3,600 bytes represent a 246 percent overhead. In the extreme case ofbyte[256][1]
, the overhead factor is almost 19! Compare that to the C/C++ situation in which the same syntax does not add any storage overhead.
String
: aString
's memory growth tracks its internal char array's growth. However, theString
class adds another 24 bytes of overhead.For a nonempty
String
of size 10 characters or less, the added overhead cost relative to useful payload (2 bytes for each char plus 4 bytes for the length), ranges from 100 to 400 percent.
Consider this example object:
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
}
A naïve sum would suggest that an instance of X
would use 17 bytes. However, due to alignment (also called padding), the JVM allocates the memory in multiples of 8 bytes, so instead of 17 bytes it would allocate 24 bytes.