Deep copy vs shallow copy in Java

For this lesson, we'll focus on the three levels of "copy" (reference, shallow, deep), what Object.clone() really does and why most senior engineers avoid it, the copy techniques you should use instead, and the cases interviewers love: 2D arrays, unmodifiable views and cyclic graphs. This question comes up because it quietly tests whether you can picture references in memory. If you can draw the boxes and arrows, the rest follows.

01Picture it first: photocopying a folder

Imagine a client folder with a cover sheet and three paper-clipped documents inside. Handing a colleague the same folder is a reference copy: you both write on the same pages. Photocopying the cover sheet and writing "see the original documents in drawer 4" on it is a shallow copy: the cover is yours, but any change to the documents is seen by both of you. Photocopying the cover and every document inside is a deep copy: a completely separate folder.

The diagram below shows the three cases for a Customer that holds an Address and a list of tags.

Fig. 1

Reference copy: two variables point to one Customer; shallow copy: two Customer objects share one Address and one tags list; deep copy: two Customers each with their own Address and tags list

Notice the "for mutable parts". String, Integer, LocalDate and records of immutable fields can be shared safely, so a deep copy doesn't need to duplicate them. Deep copying an immutable object is wasted work.

02Object.clone() under the hood

Object.clone() is a protected native method. When you call it, HotSpot allocates a new object of the same runtime class and copies the raw field bytes from the original, then gives the copy a fresh header, so no identity hash, lock state or GC age carries over. No constructor runs. That's the whole implementation: a memory copy, which is exactly why it's shallow. A reference field is 4 bytes (with compressed oops) holding a pointer, and copying the pointer doesn't copy what it points to.

To use it, a class must implement Cloneable, a marker interface with no methods. Object.clone() checks for it at runtime and throws CloneNotSupportedException if it's missing.

Here's the whole path a clone() call takes, from your override into the JVM and back.

Fig. 2

Your public clone override calls super.clone; the native Object.clone checks Cloneable and throws if it is missing, allocates the same runtime class without running a constructor, copies the field bits, and returns a shallow copy that your override then deepens by replacing mutable fields

class Address implements Cloneable {
    String city;
    Address(String city) { this.city = city; }
}

class Customer implements Cloneable {
    String name;
    Address address;
    List<String> tags = new ArrayList<>();

    Customer(String name, Address address) { this.name = name; this.address = address; }

    @Override
    public Customer clone() {                       // covariant return, public
        try {
            return (Customer) super.clone();       // field-by-field copy
        } catch (CloneNotSupportedException e) {
            throw new AssertionError(e);           // can't happen: we implement Cloneable
        }
    }
}

Customer original = new Customer("Asha", new Address("Pune"));
Customer copy = original.clone();
copy.name = "Ravi";
copy.address.city = "Delhi";

System.out.println(original.name);                   // Asha
System.out.println(original.address.city);           // Delhi  (shared Address)
System.out.println(original.tags == copy.tags);      // true   (shared list)

Notice three things:

• Reassigning copy.name doesn't affect the original. The copy has its own name field; it now points to a different String.
• Mutating copy.address.city does affect the original, because both address fields point to one Address object.
• To make it deep, clone() must also do c.address = address.clone(); c.tags = new ArrayList<>(tags);. Every class in the graph has to cooperate.

Why clone is broken (Effective Java, Item 13)

Joshua Bloch's verdict is that Cloneable is a flawed mechanism, and I agree in practice. The problems stack up:

1. Cloneable has no methods. It changes the behaviour of a protected method in another class (Object). Having Cloneable in a type doesn't let you call clone() on it.
2. No constructor runs. Invariants your constructor enforces, counters it increments, or registrations it performs are skipped.
3. It fights final. To deep-copy a final List<String> tags field you need to assign a new list in clone(), but final fields can't be reassigned after construction. You have to drop final to make cloning work.
4. A checked exception for a case that can't happen once you implement the interface, so every override has the same try/catch noise.
5. Subclass fragility. If any superclass's clone() doesn't call super.clone() (and uses new instead), every subclass clone returns the wrong type.

03The copy you should write: constructors and factories