A list is an ordered collection that grows as you add items, like a shopping list you keep adding to. An array is a fixed-size row of numbered slots, and Java's ArrayList is a list built on top of one: you call add() to append an item and get(i) to read the item at position i. The reason to want a list is that you often don't know in advance how many items you will have, and a plain array can't grow. Behind the scenes, an ArrayList swaps in a bigger array when it runs out of room. "Pre-sizing" means telling it up front how many slots to reserve.

The usual advice is to pre-size your lists. Before building one, I measured what that advice buys.

The test adds 500,000 references to a list, once with new ArrayList<>() and once with new ArrayList<>(500_000). Setup: OpenJDK 25.0.2, a 512 MB heap, an Intel Core i9-9880H, 200 warm-up rounds, then the median of 301 runs:

default   median 3.95 ms   p90 5.35 ms
presized  median 4.04 ms   p90 4.81 ms

A few terms from that setup. The heap is the memory area where Java objects live. Warm-up rounds run the code first so Java's optimizer has settled before timing starts. The median is the middle result when all the runs are sorted from fastest to slowest. The p90 is the value that 90 percent of the runs were at or below, so it shows the slower runs.

Same speed. The presized list came out a hair slower, which is within the run-to-run noise. In time, the resizing costs almost nothing. Time here means how long the loop took to run. The next measurement looks at memory instead.

It costs memory. I measured allocated bytes for the same two loops:

default   6.48 MB
presized  2.00 MB

That's 3.2 times the allocation for an identical list. Every array except the last one is dead the moment its contents are copied, and the garbage collector has to reclaim it. The garbage collector is the part of Java that automatically frees memory held by objects nothing refers to any more. I measured allocated bytes here, not GC time, so I can't tell you what that costs in your service.

The rest of this article builds the thing that produces those numbers.

The problem a plain array has

Think of an array as a row of numbered lockers (0, 1, 2, ...). You choose how many when you buy the row, and you can't bolt more on later.

Create an array of 10 and add an 11th element, and Java throws ArrayIndexOutOfBoundsException. Throwing an exception means Java stops the program with an error message unless the code handles it. The length is locked at creation.

You could allocate a million slots up front and never worry. With compressed references that's about 4 MB per list, whether it holds a million elements or three. A reference is a slot's pointer to an object, and compressed references let the JVM (the program that runs Java code) store each one in 4 bytes instead of 8.

ArrayList is the compromise: a normal array inside, replaced by a bigger one when it fills. Replacing means making a brand-new, larger array, copying every item from the old one into it, and using the new one from then on. The old array is abandoned.

What's inside

Think of a row of numbered mailboxes with a sticky note saying how many have mail. The row is the array and the note is the count. Two fields do all the work:

1. Object[] elementData holds the elements. Object[] is an array whose slots can each hold a reference, meaning a pointer to an object that lives elsewhere in memory, to any kind of Java object.
2. int size counts how many you've added.

In the picture below, null means "this slot points at nothing". Capacity is the number of slots in the array. Size is how many of them hold real items.

After adding "A" and "B" to a list with capacity 4:

elementData:  [ "A" | "B" | null | null ]
size:         2
capacity:     4   (elementData.length)

size is what the caller sees. elementData.length is how much room exists before the next resize. They are different numbers, and the code below keeps them apart.

Growing the array

Picture moving house when your boxes no longer fit in the van: you hire a bigger van, move everything across, and give the old one back. The list does the same with arrays.

When size == elementData.length the buffer (the internal array) is full, and the next add() does three things: allocate a bigger array, copy the old elements across with System.arraycopy(), and point elementData at the new one. System.arraycopy() is a built-in Java method that copies a range of slots from one array to another, or within the same array, in one call.

BEFORE (full, capacity 4):
[ 10 | 20 | 30 | 40 ]

AFTER (capacity 6 = 4 + 4/2), then 50 goes in the first free slot:
[ 10 | 20 | 30 | 40 | 50 | null ]

The JDK grows by 1.5 times:

$$\text{newCapacity} = \text{oldCapacity} + (\text{oldCapacity} \gg 1)$$

Computers store whole numbers in binary (base 2). Shifting right by one bit moves every binary digit one place to the right, which halves the number without a division and drops any remainder. For example, 10 >> 1 is 5 (binary 1010 becomes 101), and 5 >> 1 is 2. So with an old capacity of 10, the new capacity is 10 + 5 = 15.

A bigger factor means fewer copies but more empty slots after each jump. At 1.5, a list that has just resized is about a third empty, and that is the worst case. For example, a full list of 1,000 slots grows to 1,500. Once the 1,001st item is in, 499 slots are empty, and 499 of 1,500 is about a third.

One difference from the real class: new ArrayList<>() doesn't allocate 10 slots. In the OpenJDK source it starts with a shared empty array and only grows to 10 on the first add(). The version below allocates 10 eagerly because that's easier to read.

The implementation

A few pieces of Java syntax show up below. MyArrayList<T> uses <T> as a placeholder for the element type, so MyArrayList<String> holds strings and MyArrayList<Integer> holds integers. private means only code inside this class can touch a field, and static final makes a constant shared by the whole class. this refers to the object being built or used. The array stores plain Objects, so (T) is a cast that tells the compiler to treat a value as type T, and @SuppressWarnings("unchecked") silences the compiler's warning that it cannot verify that cast. Arrays.copyOf(a, n) returns a new array of length n holding a's items, padded with null if n is larger. An index is an item's position number, starting at 0.

import java.util.Arrays;

public class MyArrayList<T> {
    private static final int DEFAULT_CAPACITY = 10;
    private Object[] elementData;
    private int size;

    public MyArrayList() {
        this.elementData = new Object[DEFAULT_CAPACITY];
        this.size = 0;
    }

    public MyArrayList(int initialCapacity) {
        if (initialCapacity < 0) {
            throw new IllegalArgumentException("Capacity cannot be negative: " + initialCapacity);
        }
        this.elementData = new Object[initialCapacity];
        this.size = 0;
    }

    public void add(T element) {
        ensureCapacity(size + 1);
        elementData[size++] = element;
    }

    @SuppressWarnings("unchecked")
    public T get(int index) {
        checkBounds(index);
        return (T) elementData[index];
    }

    @SuppressWarnings("unchecked")
    public T remove(int index) {
        checkBounds(index);
        T oldValue = (T) elementData[index];

        int numMoved = size - index - 1;
        if (numMoved > 0) {
            System.arraycopy(elementData, index + 1, elementData, index, numMoved);
        }

        elementData[--size] = null; // clear the vacated slot
        return oldValue;
    }

    public int size() {
        return size;
    }

    private void ensureCapacity(int minCapacity) {
        if (minCapacity > elementData.length) {
            int oldCapacity = elementData.length;
            int newCapacity = oldCapacity + (oldCapacity >> 1); // 1.5x growth
            if (newCapacity < minCapacity) {
                newCapacity = minCapacity;
            }
            elementData = Arrays.copyOf(elementData, newCapacity);
        }
    }

    private void checkBounds(int index) {
        if (index < 0 || index >= size) {
            throw new IndexOutOfBoundsException("Index: " + index + ", Size: " + size);
        }
    }
}

Walking through it

Start with list.add("A") on a new list. ensureCapacity(1) sees that 1 is not more than the 10 slots, so it does nothing. Then elementData[size++] = element stores "A" in slot 0 and bumps size from 0 to 1. The ++ after size means "use the current value as the index, then add 1", so storing the element and updating the count happen in one line.

Now suppose the list holds 10 items and you add an 11th. ensureCapacity(11) finds that 11 is more than 10, so newCapacity becomes 10 + (10 >> 1) = 15. Arrays.copyOf builds a new 15-slot array holding the old 10 items, with null in the rest, and elementData now points at it. The old array has nothing pointing at it any more. Then the 11th item goes into slot 10.

Now remove(1) on [A, B, C, D], where size is 4. checkBounds(1) passes because 1 is at least 0 and less than 4. oldValue is "B". Then numMoved = 4 - 1 - 1 = 2, the two items after the gap:

before:  [ A | B | C | D ]
copy C, D one slot left (from index 2 into index 1):
after:   [ A | C | D | D ]
then --size makes size 3 and nulls slot 3:
final:   [ A | C | D | null ]

If you ask for get(3) now, checkBounds throws IndexOutOfBoundsException, because 3 is not less than size.

The line that stops a leak

Imagine you take a book off a library shelf but leave its card in the catalogue. The library still believes the book is in use, so it never clears the space. A leftover slot in the array does the same thing to the garbage collector.

Look at the last statement in remove():

elementData[--size] = null;

Here --size subtracts 1 from size first and uses the new value as the index. After removing "B" from [A, B, C, D] and shifting, the array is [A, C, D, D] and size is 4. The statement makes size 3 and sets slot 3 (the stale second "D") to null, giving [A, C, D, null].

Drop the = null and keep only the --size, and the array still holds a reference to the removed object. No public method can reach it. The garbage collector can't know that; it sees a live reference and keeps the object alive. Objects kept alive this way are called loitering objects.

Why add() is still O(1)

Big-O notation describes how the work grows as the number of items grows. $O(1)$ means the work stays about the same however many items there are. $O(N)$ means it grows in proportion to $N$, the number of items. Think of paying a small bill every day versus a huge bill once a year: the yearly bill is big, but spread over 365 days it is a small daily cost.

One resize copies the whole array, which is $O(N)$. So how can add() be constant time?

Because resizes get rarer as the list grows. I simulated the JDK's growth rule from 10 slots up to 500,000 elements and counted: 27 resizes, 1,080,430 element copies in total. That's 2.16 copies per insert, spread over half a million inserts.

It's no accident that the number sits near 2. Each resize copies the old size, and with a 1.5 factor those old sizes form a geometric series:

$$\frac{N}{1.5} + \frac{N}{1.5^2} + \frac{N}{1.5^3} + \dots \approx 2N$$

Each term is the previous one divided by 1.5, so the terms shrink quickly. A series like that adds up to its first term divided by $(1 - 1/1.5)$. The first term is $N/1.5$ and $1 - 1/1.5$ is $1/3$, so the total is $(N/1.5) \div (1/3) = 2N$. For example, with $N = 600$ the copies are 400, then 267, then 178, and so on, and the running total creeps toward 1,200.

Total copying is bounded by about $2N$ for $N$ inserts. The cost per insert is a constant, which is what amortized $O(1)$ means. Amortized means averaged over a long run of operations: a few add() calls are expensive, but the average cost per call stays constant. Individual calls can still be slow; the average can't.

What I'd do with this

If you know the final size, pre-size. In my benchmark it didn't speed up the loop, but it cut allocation from 6.48 MB to 2.00 MB. If you don't know the size, leave it alone; the growth rule handles it.

And if you write your own list, put the null in remove().

Quick summary

• A size field and a flat array make a list. Everything else is bookkeeping.
• Full means resize by 1.5 times with Arrays.copyOf(). 27 resizes take it from 10 slots to 500,000 elements.
• Resizing barely moved the timing; it tripled the memory allocated.
• remove() shifts elements left, then nulls the last slot so nothing loiters.

Suppose it's 2:00 AM on a Friday. Your phone alerts you to a production incident: logged-in users cannot access their subscription accounts. ("Production" means the live system that real users are using right now.)

Your authentication service uses a custom UserSession object as a key inside a HashMap to fetch user roles.

A HashMap is a Java lookup table that stores pairs: you hand it a key and it gives back the value saved for that key, like looking up a name in a phone book to get a number. A key is the item you look something up by (here, a session), and a value is the thing stored under it (here, the user's role). Putting a pair in is called put, and looking a value up by its key is called get. In plain terms, when a user logs in the program stores their role in the map, and later requests ask the map for it.

The logs show that when a user logs in, the service creates a UserSession(userId=981) key and stores their role. One millisecond later, when the user requests their profile page, the server constructs another UserSession(userId=981) key and queries the map.

The result? map.get(session) returns null. The user gets logged out immediately.

Why does HashMap claim the session key does not exist when both key objects contain identical data?

The answer lies in the contract between equals() and hashCode().

Identity (==) vs Value Equality (equals)

Picture two printed copies of the same form. They say the same thing, but they are still two separate sheets of paper. Asking "is this the very same sheet?" is what == does. Asking "do these say the same thing?" is what equals does.

In Java, a variable that holds an object really holds a reference, which is the address of where the object lives in memory. The heap is the area of memory where Java stores objects. The == operator compares memory addresses when applied to object references. It returns true only if both variables point to the exact same heap allocation (the same block of memory).

User userA = new User(101, "Alex");
User userB = new User(101, "Alex");

boolean sameAddress = (userA == userB); // false! Separate heap allocations.

HEAP
+-----------------------------------+
| User Object 0x1A8F                |
| id: 101, name: "Alex"             |  <--- userA
+-----------------------------------+

+-----------------------------------+
| User Object 0x2B90                |
| id: 101, name: "Alex"             |  <--- userB
+-----------------------------------+

To compare the fields you care about (here the user ID and name) rather than memory locations, Java provides the equals(Object obj) method on java.lang.Object.

Every Java class automatically inherits from the built-in class java.lang.Object. Inheriting means your class gets the methods Object already has, including equals, without you writing them. To override a method means to write your own version of it in your class, which replaces the inherited one.

By default, Object.equals() simply performs this == obj. You must override it to enforce value-based equality, meaning two objects count as equal when their fields match.

The Rules equals() Must Follow

Think of "equals" the way you think of "is the same age as": it has to behave sensibly. If Ana is the same age as Ben, then Ben is the same age as Ana.

The Java standard library requires any equals() override to fulfill five mathematical properties. A contract here means a rule that the Java libraries rely on and trust you to follow. The compiler does not check it.

1. Reflexive: x.equals(x) must return true. (Everything equals itself.)
2. Symmetric: x.equals(y) must return true if and only if y.equals(x) returns true. (If A says it equals B, B must say it equals A.)
3. Transitive: If x.equals(y) is true and y.equals(z) is true, then x.equals(z) must return true. (If A equals B and B equals C, then A equals C.)
4. Consistent: Multiple invocations return identical results unless fields mutated. (Mutated means changed after creation. The answer may change only if a field used in the comparison changed.)
5. Null comparison: x.equals(null) must always return false. (null means "no object", and a real object is never equal to it.)

The Hash Code Integer

Think of a coat check. You hand over your coat and get a numbered ticket, and the attendant hangs the coat on the rack that matches the number. When you come back, the ticket tells the attendant which rack to look at, so nobody searches every rack. A hash code works like that ticket: it is a number that acts as a short label for an object, and it tells the map which shelf to look on.

Formally, a hash code is a 32-bit signed integer (int, a whole number that can be negative) computed from an object's internal fields.

Hash-based collections use this integer to pick a spot in an array. HashMap stores key and value pairs, HashSet stores a set of unique items, and LinkedHashMap is a HashMap variant that also remembers the order items were added. An array here is a numbered row of slots, and each slot is called a bucket. Because the map jumps straight to one bucket instead of checking every entry, a lookup takes about the same time no matter how many entries the map holds. This is written $O(1)$ and read as "constant time".

The real HashMap source code (OpenJDK, java.util.HashMap) computes the bucket index in two steps. First it mixes the high bits of the hash code into the low bits, then it keeps only the low bits that fit the array:

int h = key.hashCode();
int hash = h ^ (h >>> 16);          // spread: mix the top 16 bits into the bottom 16
int bucketIndex = (n - 1) & hash;   // n is the array length, always a power of two

Here >>> shifts the bits of a number to the right, ^ combines two numbers bit by bit (XOR), and & keeps only the bits set in both numbers. Because n is a power of two (the default is 16), (n - 1) & hash gives a number from 0 up to n - 1, so it always lands inside the array.

If two objects have different hash codes, a hash collection immediately knows they cannot be equal. It skips the expensive field-by-field equals() check. This works because of the contract described below: equal objects must have equal hash codes, so different hash codes prove the objects are not equal.

How put and get use the hash code, step by step

Putting an entry in with put(key, value):

1. The map calls key.hashCode() to get a number.
2. It spreads that number with h ^ (h >>> 16) and keeps the low bits with (n - 1) & hash to get a bucket index.
3. If that bucket is empty, the map stores the entry there and is done.
4. If the bucket already holds entries, the map compares the new key with each stored key using equals(). If one is equal, it replaces that entry's value. If none is equal, it adds the new entry to the bucket.

Looking a value up with get(key):

1. The map calls key.hashCode() and computes the bucket index the same way.
2. It goes straight to that bucket. Nothing else is searched.
3. Inside the bucket, it checks the stored keys with equals() (the real code also compares the stored hash first as a quick filter). When one matches, it returns that entry's value. If none matches, it returns null.

A tiny worked example with made-up numbers, using a map with 16 buckets:

• Suppose a key has hash code 1012. Since 1012 >>> 16 is 0, spreading changes nothing: 1012 ^ 0 is 1012. In binary, 1012 ends in 0100, so 15 & 1012 is 4. The entry goes in bucket 4.
• Later, get is called with a second key that equals() the first and so, following the rule, also has hash code 1012. It computes bucket 4, finds the stored key there, equals() says yes, and the value comes back.
• Now suppose the second key broke the rule and had hash code 100000. Here 100000 >>> 16 is 1, spreading gives 100000 ^ 1, which is 100001, and 15 & 100001 is 1. The map looks in bucket 1, finds nothing, and returns null. It never gets to call equals(), because it never looked in bucket 4.

That last case is exactly the bug in this article.

The Unbreakable Contract Relationship

Besides the five rules above, equals() and hashCode() share one more rule. This is the contract that HashMap depends on:

If two objects are equal according to equals(Object), they MUST produce the exact same integer result from hashCode().

The reverse is not required: two unequal objects CAN produce identical hash codes. That scenario is called a hash collision. Two unequal objects that collide end up in the same bucket, and the map then uses equals() to tell them apart.

               +----------------------------------+
               |         Equal Objects            |
               |     (userA.equals(userB) == true)|
               +----------------------------------+
                                |
                                | MUST HAVE
                                v
               +----------------------------------+
               |       Identical Hash Codes       |
               | (userA.hashCode() == userB.hashCode())
               +----------------------------------+

Production Horror Story: The Missing hashCode() Bug

A bug like this can slip through because the code compiles, runs without errors, and only returns the wrong answer. Here is code that reproduces the problem from the opening scenario. Read the notes after the listing if any line is unfamiliar:

import java.util.HashMap;
import java.util.Map;
import java.util.Objects;

class UserSession {
    private final int userId;

    public UserSession(int userId) {
        this.userId = userId;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        UserSession session = (UserSession) o;
        return userId == session.userId;
    }

    // MISSING HASHCODE OVERRIDE!
}

public class IncidentDemo {
    public static void main(String[] args) {
        Map<UserSession, String> roles = new HashMap<>();
        
        UserSession loginSession = new UserSession(981);
        roles.put(loginSession, "ADMIN");

        UserSession requestSession = new UserSession(981);
        
        // loginSession.equals(requestSession) is TRUE, but hashCodes almost certainly differ!
        System.out.println("Role found? " + roles.get(requestSession)); // Prints NULL!
    }
}

How to read the listing:

• private final int userId declares a field that only this class can see (private) and that cannot be reassigned after the constructor sets it (final).
• @Override is a note to the compiler that the method below replaces one inherited from Object. If the method name or parameters do not match an inherited method, the compiler reports an error.
• getClass() != o.getClass() compares the exact types of the two objects. getClass() returns the class an object was created from, so the check returns false for an object of a different type.
• (UserSession) o is a cast. It tells Java to treat o, which is declared as a plain Object, as a UserSession, so its userId can be read. The type check on the line above makes that safe.
• Map<UserSession, String> uses generics, the angle-bracket notation that says what a collection holds. Here the keys are UserSession objects and the values are Strings. The new HashMap<>() on the right lets Java fill in the same types.

What happens when main runs:

1. roles.put(loginSession, "ADMIN") hashes loginSession and stores "ADMIN" in the bucket that hash code picks.
2. requestSession is a second, separate object with the same userId. equals() would say it matches loginSession.
3. roles.get(requestSession) hashes requestSession. Without a hashCode() override, that number is almost certainly different, so the map looks in a different bucket, finds nothing, and returns null.

Because hashCode() was omitted, loginSession and requestSession inherited the default identity hash code from java.lang.Object. Identity means it is tied to the object itself, not to its field values. The Java documentation says only that Object.hashCode() returns distinct integers for distinct objects as far as is reasonably practical. It does not promise that the number is the memory address, so do not rely on that. The result is that two separate objects get different hash codes in practice.

roles.get(requestSession) hashed requestSession, computed a completely different bucket index (very likely, though not guaranteed), inspected an empty array slot, and returned null. It never reached equals().

Correct Implementation Pattern

Always override both methods together using the exact same fields. If equals() compares userId, then hashCode() must be built from userId too, so any two objects that equals() calls the same get the same number. Objects.hash(...) is a ready-made helper that combines the fields you give it into one hash code:

@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (o == null || getClass() != o.getClass()) return false;
    UserSession session = (UserSession) o;
    return userId == session.userId;
}

@Override
public int hashCode() {
    return Objects.hash(userId);
}

Quick Summary

• == checks reference addresses. equals() checks business value equality (equal in the sense your program cares about, such as the same user ID).
• Equal objects must return identical hashCode() values.
• Omitting hashCode() causes hash collections to inspect wrong bucket indices, triggering silent lookup failures in production.

Java hides memory addresses by default. Most of the time, that's a blessing: you instantiate an array (create it), append items, pass it to a method, and never think about pointers (variables that hold the memory address of something, like a street address instead of the house) or memory offsets (how far past the start of something a piece of data sits).

Until you scale throughput (how much work your program finishes per second) or inspect a heap dump (a snapshot file listing every object in memory).

Then you notice something baffling: an array holding one million Integer wrappers takes about 20 megabytes of heap, while an array holding one million primitive int values takes 4 (measured on OpenJDK 25 with default settings).

Two terms there need a plain definition. A primitive such as int stores just the number itself. An Integer is an object that wraps one number inside it, and Java converts between the two automatically, which is called boxing. The heap is the large area of memory where Java keeps every object you create with new. That is a five-to-one gap, and the section called The Numbers in Practice, further down, shows where every byte goes.

To understand why custom data structures perform well or fail under memory pressure, you have to look past the Java syntax and see how the HotSpot JVM actually organizes bytes in RAM. The JVM (Java Virtual Machine) is the program that runs your compiled Java code and manages its memory, HotSpot is the most common JVM implementation, and RAM is the computer's working memory.

Stack Frames vs The JVM Heap

Think of the stack as a sticky note on your desk: you jot down what you need for the current task and throw the note away when the task ends. The heap is a warehouse: bigger items are stored there and found later by a shelf address.

In Java terms, a thread is one line of execution in a running program. Each time a thread calls a method, the JVM sets aside a small block of memory for that call, called a stack frame, and the frames pile up in order on the thread's call stack. When a thread executes a Java method, the JVM divides working memory between two distinct regions, the stack (the frames) and the heap (the shared warehouse of objects):

  THREAD STACK (Local execution)             JVM HEAP (Shared Objects)
+-----------------------------+          +----------------------------------+
| process() frame             |          | int[] Object Allocation          |
|                             |          |                                  |
| primitiveVal = 42           |          | Header (Mark Word + Klass Word)  |
| numbersRef -----[0x7A4F00]---------->  | Length: 4                        |
|                             |          | [ 10 | 20 | 30 | 40 ]            |
+-----------------------------+          +----------------------------------+

Local primitive variables (int, double, boolean) live directly inside the stack frame slot. When the method returns, the frame pops off the call stack (is removed from the top of the pile) and that memory is immediately reclaimed without any garbage collection involvement. Garbage collection is the JVM's automatic cleanup that finds heap objects nothing uses any more and frees their memory.

Reference variables (int[], String, custom objects) hold a memory address. A reference is Java's word for a pointer. An address is normally 8 bytes (64 bits), but by default the JVM shrinks it to 4 bytes (32 bits) using a feature called Compressed OOPs (compressed ordinary object pointers), which works while the heap stays below roughly 32 gigabytes. This article assumes that default, so every reference below is 4 bytes. That address points to a block of memory allocated inside the shared JVM heap.

Reading the diagram above: primitiveVal is a local variable, so the number 42 sits right in the frame. numbersRef is also a local variable, but it holds only the address 0x7A4F00 (the 0x prefix means the number is written in hexadecimal, base 16). The array itself, including its length, sits in the heap at that address. When the method returns, both locals vanish from the stack, but the array stays in the heap until the garbage collector finds that nothing points to it.

Contiguous Memory: The Primitive Array Layout

A primitive array is like a row of numbered lockers, all the same size, built side by side. Contiguous means exactly that: back to back with no gaps, like seats in one row of a theater.

When you run:

int[] numbers = new int[4];

The HotSpot JVM allocates a single contiguous slice of bytes on the heap (a byte is the unit memory is counted in, and an int takes 4 of them):

Memory Offset   | Field / Content
----------------|----------------------------------------------
0x00 - 0x07     | Mark Word (8 bytes: GC metadata, locks, hash)
0x08 - 0x0B     | Klass Word (4 bytes under Compressed OOPs)
0x0C - 0x0F     | Array Length = 4 (4 bytes)
0x10 - 0x13     | numbers[0] (4 bytes)
0x14 - 0x17     | numbers[1] (4 bytes)
0x18 - 0x1B     | numbers[2] (4 bytes)
0x1C - 0x1F     | numbers[3] (4 bytes)

How to read the table: the first column is the offset, the number of bytes past the start of the object, written in hexadecimal (0x10 is 16). Every object begins with a header, a fixed block the JVM uses for its own bookkeeping. You never write to it, but it costs space. The Mark Word holds things like garbage collection information, locks, and the object's hash code. The Klass Word records which class the object belongs to. For an array the header is 8 + 4 + 4 = 16 bytes (mark word, class word, length), and the elements start right after it, at offset 0x10.

Because 32-bit integers sit right next to each other in physical RAM, reading numbers[3] doesn't require scanning through previous elements. Every element is the same size, so the address of element 3 is computed directly from the start of the array rather than found by counting up from element 0.

The CPU calculates the memory address in hardware:

$$\text{Address}(\text{numbers}[i]) = \text{BaseAddress} + 16 + (i \times 4)$$

Here BaseAddress is where the array begins, 16 is the header size from the table above, and 4 is the byte size of each int. Multiplying by the index $i$ jumps straight to element $i$. Worked example: for $i = 3$, the offset is $16 + 3 \times 4 = 28$, which is 0x1C in hexadecimal, exactly where numbers[3] sits in the table.

This is why random indexing in an array is strictly $O(1)$. O(1), or constant time, means the work does not grow as the array gets bigger: getting item 3 and item 3,000,000 takes the same number of steps.

There is a second benefit. The CPU keeps recently used memory in a small, very fast storage area called a cache, and it loads memory from RAM in fixed-size chunks called cache lines (commonly 64 bytes). When the CPU reads numbers[0], its hardware prefetcher pulls the entire 64-byte cache line into the L1 cache (the smallest and fastest level), so numbers[1], numbers[2] and the rest of that chunk are already waiting. Items stored next to each other usually arrive together, which makes sequential reads very fast.

The Indirection Trap: Object Reference Arrays

Indirection means reaching a value through a middleman, like a contact list that holds addresses instead of the people. An object array is that list: each locker holds a note saying where to find the real item, and each real item lives somewhere else.

Now contrast primitive arrays with an array of objects:

String[] names = new String[3];
names[0] = "Alice";
names[1] = "Bob";

It's tempting to think this allocates strings contiguously in RAM. It doesn't.

String[] is an array of pointers:

  STACK                                     HEAP
+----------+          +-----------------------------------------------+
| names    |--------->| String[] Array (Container)                    |
+----------+          | Length: 3                                     |
                      | [0]: 0x9B10 --------------------+             |
                      | [1]: 0x9C40 ------------------+ |             |
                      | [2]: null                     | |             |
                      +-------------------------------|-|-------------+
                                                      | |
                                                      | +--> [ String: "Alice" ]
                                                      +----> [ String: "Bob" ]

Each index in names stores only a 4-byte pointer (a reference, using the Compressed OOPs size described earlier). The actual String instances live somewhere else in heap memory, often scattered in unrelated places. null in slot [2] means that slot holds no reference yet: it points at nothing.

Walkthrough: new String[3] creates three empty slots, all null. The two assignment lines create the strings "Alice" and "Bob" elsewhere in the heap and store their addresses in slots 0 and 1. The array holds addresses only, never the text itself.

When you loop through names, the CPU has to follow each pointer to a new address, jumping across cache lines and causing CPU cache misses. A cache miss happens when the CPU needs data that is not in its cache and has to fetch it from slower main memory.

The Numbers in Practice

Start with one element. In a primitive array, each element is a 4-byte number sitting in its locker. In a boxed array, each element is a 4-byte note in the locker (the pointer) plus a separate 16-byte Integer object somewhere else. That is 4 bytes versus 4 + 16 = 20 bytes per element, a ratio of 5 to 1. Multiply by one million and you get the figures in the code below.

Here is what one million elements look like in JVM heap memory:

public class MemoryFootprint {
    public static void main(String[] args) {
        int size = 1_000_000;

        // Primitive int array:
        // 16 bytes header + (1,000,000 * 4 bytes) ≈ 4.0 MB total.
        int[] rawNumbers = new int[size];

        // Boxed Integer array:
        // 16 bytes array header + (1,000,000 * 4 bytes pointers) = 4.0 MB
        // PLUS 1,000,000 separate Integer objects (16 bytes each) = 16.0 MB
        // Total footprint: ~20.0 MB, measured with allocated-bytes counters.
        Integer[] boxedNumbers = new Integer[size];
        for (int i = 0; i < size; i++) {
            boxedNumbers[i] = i;
        }
    }
}

Walkthrough: new Integer[size] creates only the million pointer slots, all null at first. Each boxedNumbers[i] = i; line makes Java box the int (automatically convert it to an Integer), which creates a new Integer object on the heap and stores its address in slot i. Every Integer is an object, so it carries its own header (12 bytes: the 8-byte mark word and a 4-byte class word) plus the 4 bytes of the number, which makes 16 bytes. The array itself costs 16 bytes of header plus 4 million bytes of pointers, about 4 MB. The million objects add 16 million bytes, about 16 MB. Together that is about 20 MB, against about 4 MB for the int array.

That 5x memory bloat isn't just wasted RAM. With compressed references off, an Integer grows to 24 bytes and the ratio to 6x.

It also means the Garbage Collector has to track, mark, and sweep one million individual objects during a collection cycle instead of inspecting a single contiguous byte buffer. Marking means finding which objects are still in use, and sweeping means freeing the ones that are not.

What Comes Next

Understanding contiguous memory allocation and reference pointer indirection is the foundation for everything we will build in this series.

In Part 2, we dissect how the JVM calculates equals() and hashCode() contract rules, why hash collisions (terms we define in Part 2) degrade memory lookups, and how that shapes custom collection implementations.