skip to content

What is the difference between Arrays.equals and Arrays.deepEquals (and likewise toString vs deepToString), and when must you use the deep version?

level: middleimportance: should knowfreq 50%

answer

  1. equals/toString = one level; deepEquals/deepToString = recurse
  2. Inner arrays via equals() => identity, the trap
  3. 2D array = array of arrays => use deep versions
  4. deepToString shows [[1,2],[3,4]] and guards cycles
  5. Pair deepEquals with deepHashCode

basics

~20 s

Arrays.equals compares two arrays one element at a time, but for arrays of arrays it only checks if the inner arrays are the same object. Arrays.deepEquals goes inside nested arrays and compares their contents too. Same idea for toString (one level) vs deepToString (nested).

solid answer

~40 s

Arrays.equals(a, b) walks both arrays comparing element i to element i, using == for primitives and .equals() for objects. That's perfect for flat arrays. But when the elements are themselves arrays (a 2D array, i.e. an Object[] of int[]), Arrays.equals compares those inner arrays with their .equals(), which is identity (==) — so two int[][] with identical numbers but different inner-array objects compare as not equal. Arrays.deepEquals handles this by recursing: when an element is itself an array, it compares it with the appropriate deep/array equality instead of identity. The same split exists for printing: Arrays.toString gives one level ([[I@..., [I@...]) for nested arrays, while Arrays.deepToString recurses to show [[1, 2], [3, 4]]. Rule of thumb: flat array -> equals/toString; nested (multi-dimensional or array-of-arrays) -> deepEquals/deepToString.

code

java · 11 lines
java
int[][] a = {{1, 2}, {3, 4}};
int[][] b = {{1, 2}, {3, 4}};

System.out.println(Arrays.equals(a, b));      // false  -> inner int[] compared by identity
System.out.println(Arrays.deepEquals(a, b));  // true   -> recurses into the rows

System.out.println(Arrays.toString(a));       // [[I@.., [I@..]
System.out.println(Arrays.deepToString(a));   // [[1, 2], [3, 4]]

int[] flat = {1, 2, 3};
System.out.println(Arrays.equals(flat, new int[]{1, 2, 3})); // true (flat is fine)

go deeper

for a junior

Knows == doesn't compare array contents and that Arrays.equals does, for a flat array.

for a middle

Explains why Arrays.equals fails on 2D arrays (inner identity comparison) and reaches for deepEquals/deepToString correctly.

for a senior

Connects equals/deepEquals to hashCode/deepHashCode consistency and uses the right pair in equals()/hashCode() implementations involving array fields.

for a principal

Advises on modeling choices (avoid array fields in value objects, prefer List/record components) and the maintainability cost of nested-array equality pitfalls across a codebase.

## The core problem: arrays don't have meaningful equals/toString A Java array's own `equals()` is inherited from `Object`, so it means **identity** — `a.equals(b)` (and `a == b`) is true only if they are the *same array object*, never because they hold the same values. Its `toString()` likewise prints a type-and-hash string like `[I@1b6d3586`. `java.util.Arrays` provides content-aware replacements. ## Arrays.equals — one level deep `Arrays.equals(a, b)` returns true when both arrays have the same length and, for every index i, the elements are equal: `==` for primitive element types, and `element.equals()` for object element types (with null handled). This is exactly what you want for a **flat** array like `int[]` or `String[]`. ## Why it breaks for nested arrays Consider a 2D array `int[][] m`. In Java a 2D array is really an **array of arrays**: `m` is an `int[][]` whose elements are `int[]` objects. Now `Arrays.equals(m1, m2)` treats each element (an `int[]`) as an *object* and compares it with that object's `.equals()` — which for an array is **identity**. So even if `m1[0]` and `m2[0]` contain `{1, 2}` and `{1, 2}`, they are different `int[]` objects, `.equals()` is false, and `Arrays.equals(m1, m2)` returns **false**. This surprises people constantly. ## Arrays.deepEquals — recurse into nested arrays `Arrays.deepEquals(a, b)` fixes this: when it encounters an element that is **itself an array**, it doesn't use identity — it recursively applies the right deep/array equality to that element (and recurses further for deeper nesting). So two `int[][]` with the same numbers compare **equal**. Use `deepEquals` whenever elements may themselves be arrays. (`deepEquals` takes `Object[]`; it's for reference-type arrays, including arrays of arrays.) ## The printing twins: toString vs deepToString The same split applies to printing: - `Arrays.toString(a)` formats **one level**: `[1, 2, 3]` for a flat array, but `[[I@.., [I@..]` for a nested one (each inner array still printed via its bad default `toString`). - `Arrays.deepToString(a)` recurses: `[[1, 2], [3, 4]]`. It also safely handles **cyclic references** by printing `[...]` instead of looping forever. ## Sibling: hashCode vs deepHashCode For completeness, `Arrays.hashCode` and `Arrays.deepHashCode` mirror the same one-level vs recursive distinction, so a hash code is consistent with the equality you chose. If you use `deepEquals` for your equality, use `deepHashCode` for hashing. ## Decision rule - Elements are **primitives or simple objects** (flat array) -> `Arrays.equals` / `Arrays.toString` / `Arrays.hashCode`. - Elements are **themselves arrays** (2D+, or `Object[]` holding arrays) -> `Arrays.deepEquals` / `Arrays.deepToString` / `Arrays.deepHashCode`. ## Mental model 'equals/toString' look one layer down and trust each element's own equals/toString. For arrays-of-arrays that inner trust is misplaced (identity), so the 'deep' versions recurse all the way down.

  • Does Arrays.deepToString protect against infinite loops from self-referential arrays?
    Yes. If an array (directly or indirectly) contains itself, deepToString detects the cycle and prints [...] instead of recursing forever.
  • If you override equals using Arrays.deepEquals on a field, which hashCode helper should you use?
    Arrays.deepHashCode, so equal nested arrays produce the same hash and the equals/hashCode contract holds.

saying these in an interview costs you the question

  • Using Arrays.equals on a 2D array and expecting content comparison
  • Using == to compare array contents
  • Mixing Arrays.equals with Arrays.deepHashCode (inconsistent equality/hash)
  • Believing toString recurses into nested arrays

context

resolving links…