Array vs ArrayList in Java

An array is a fixed-size, strongly typed block of memory created with new. Its length is part of its type at runtime and can never change: an int[3] holds three ints forever. An ArrayList is a class in the Collections Framework that implements the List interface and holds a growable array behind the scenes. When you add beyond its capacity it allocates a bigger array and copies the contents across.

That single difference cascades into everything else. An array is faster — it has no per-element method dispatch, no bounds-check indirection beyond the length field, and no wrapper allocation. An ArrayList gives you generics, so it holds real Integer objects rather than raw values, and it gives you the whole List interface: add, remove, indexOf, iterators, subList, and the stream API.

import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        int[] numbers = {1, 2, 3};
        List<Integer> list = new ArrayList<>(Arrays.asList(1, 2, 3));

        System.out.println("array size    : " + numbers.length);
        System.out.println("list size     : " + list.size());

        list.add(4);                       // ArrayList can grow
        System.out.println("list after add: " + list);

        // An array cannot grow. This is a copy into a new, longer array.
        int[] bigger = Arrays.copyOf(numbers, 5);
        System.out.println("copied array  : " + Arrays.toString(bigger));

        list.set(0, 100);
        System.out.println("list after set: " + list);
        System.out.println("get(0) as int : " + list.get(0));
    }
}

The boxing line is worth noticing: list.get(0) returns an Integer, and assigning it to an int unboxes it. An ArrayList of primitives costs one wrapper object per element — except for the small values the Integer cache covers, which is why a list of small integers is far cheaper than it looks.

The last difference is mutability of size: because an array's length is fixed, inserting into the middle means allocating a new array and copying, whereas an ArrayList shifts elements in place.

Choose an ArrayList when the size is not known up front, when you need to insert or remove elements, when you want to pass a collection to an API, or when you want to use the stream and functional operations. Choose a plain array when the size is fixed and known, when you are storing primitives and memory matters, when the code is a tight numeric loop, or when you need a primitive array to avoid boxing altogether.

There is a middle option people forget: Arrays.asList gives you a List view backed by an existing array. It costs almost nothing and it reads like a collection, but it is fixed-size — add and remove throw UnsupportedOperationException — and set still works, which silently changes the backing array. It is a good fit when you want to hand a method a list view of data you already hold in an array.

Two performance points that interviewers like. An ArrayList holds references, so a list of a million ints allocates a million Integer objects unless the values fall inside the cache range; a primitive int array allocates one contiguous block of memory and is dramatically more cache-friendly. And because an ArrayList wraps an array, growth is amortised but not free: adding beyond capacity copies the whole backing array, which is why code that knows the final size can call ensureCapacity or construct with an initial capacity.

The trap worth naming: List.of and Arrays.asList both return unmodifiable or fixed-size lists, and calling add on either throws. If you need to mutate, copy into a new ArrayList first.

Java's iterators are fail-fast. Each collection implementation keeps a modification counter that is incremented every time the collection is structurally changed. The iterator remembers the counter value from when it was created, and every call to next compares the two. If they differ, the iterator throws ConcurrentModificationException rather than letting you continue iterating over a collection whose structure has shifted underneath it.

The important detail is when the exception is thrown. It is not thrown by the modification itself. The removal succeeds, and the exception fires on the next call to next, when the iterator notices the counter moved. So the collection is left in a partially modified state, which is one reason this pattern is so unpleasant to debug.

import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        List<String> names = new ArrayList<>();
        names.add("Ada");
        names.add("Grace");
        names.add("Alan");
        names.add("Katherine");

        try {
            for (String name : names) {
                if (name.startsWith("A")) {
                    names.remove(name);
                }
            }
        } catch (java.util.ConcurrentModificationException e) {
            System.out.println("ConcurrentModificationException caught");
        }

        // The safe way: remove through the iterator itself.
        Iterator<String> it = names.iterator();
        while (it.hasNext()) {
            if (it.next().startsWith("A")) {
                it.remove();
            }
        }
        System.out.println("after removal : " + names);
    }
}

The output shows the sequence precisely. The for-each loop removed Ada and then blew up on the next iteration, leaving Grace, Alan and Katherine behind. The iterator-based loop then removed Alan through the iterator, which updates the modification counter correctly, and the final list holds Grace and Katherine.

Two other safe routes exist. You can use removeIf, which is the modern idiom and takes a lambda, or you can copy the collection into a new one and iterate over the copy while mutating the original. The copy approach is simple and occasionally the most readable, but it is O(n) in extra memory and easy to forget, so the iterator or removeIf is usually the better answer in a code review.