How Much Memory Does a Java Object Really Use? A Deep Dive

When writing Java code we rarely consider how large a Java object actually is in memory, focusing instead on business logic, yet unnoticed memory waste can be substantial.

How big is a Java object?

To calculate the exact memory occupied by a Java object, you first need to understand its internal structure.

Java object structure

A Java object on the heap consists of three parts:

Object Header

Class Pointer

Fields

Every ordinary Java object has an object header that stores essential state information.

On a 32‑bit JVM the layout differs from a 64‑bit JVM. For example: hash(25)+age(4)+lock(3)=32bit On a 64‑bit JVM (with compressed oops disabled) the layout is: unused(25+1)+hash(31)+age(4)+lock(3)=64bit The class pointer points to the object's superclass. Its size is 4 bytes on a 32‑bit JVM and either 4 bytes (with compressed oops) or 8 bytes on a 64‑bit JVM.

Fields refer only to instance fields; static fields are stored once per class and are not counted here.

Example: size of java.lang.Integer

Object Header (4 bytes) + Class Pointer (4 bytes) = 8 bytes. The Integer class has a single int field:

/** 
 * The value of the <code>Integer</code>. 
 * @serial 
 */ 
private final int value;

An int occupies 4 bytes, so the raw size is 8 + 4 = 12 bytes. Java objects are aligned to 8‑byte boundaries, so 4 bytes of padding are added, resulting in a total of 16 bytes.

Arrays

Arrays have an extra length field (an int). For int[] arr = new int[10]; the heap size is:

4 (object header) + 4 (pointer) + 4 (length) + 4*10 (int elements) = 52 bytes → aligned to 56 bytes

Memory‑saving principles

From the calculations we see that a java.lang.Integer consumes 16 bytes while a plain int uses only 4 bytes—a 4:1 ratio. This leads to the first rule:

(1) Prefer primitive types over wrapper classes.

When designing database tables or JavaBeans, choose the smallest type that fits the data. For example, using short, byte, or boolean instead of int or long can save significant memory when millions of objects are created.

(2) Choose the smallest adequate field type.

Consider an ArrayList that holds ten Integer objects. Its memory consumption is:

/** 
 * The array buffer into which the elements of the ArrayList are stored. 
 * The capacity of the ArrayList is the length of this array buffer. 
 */ 
private transient Object[] elementData; 

/** 
 * The size of the ArrayList (the number of elements it contains). 
 * @serial 
 */ 
private int size;

Object Header 4 bytes + Pointer 4 bytes + int size 4 bytes + elementData array (12 bytes) + 10 × 16 bytes for Integer objects = 184 bytes. Using a plain int[] would require only 56 bytes, a ratio greater than 3:1.

(3) Prefer arrays to collections when possible.

Arrays can store primitive types directly, while collections store objects, incurring additional overhead.

For cases where collections are unavoidable, the fastutil library offers more memory‑efficient implementations.

(4) Small tricks

Represent timestamps with long/int instead of Date or String.

If a short string can be enumerated or expressed as ASCII, store it as a long or int.

These tricks depend on the specific data and can be applied aggressively when memory is a bottleneck.

Conclusion

Performance and readability often conflict; sacrificing a bit of readability to reduce memory usage can be worthwhile in memory‑constrained scenarios. The principles above provide a practical guide for such optimizations.