Object Lifecycle Questions

The runtime allocates memory for the object first, then initialises it. The sequence is: memory is allocated, the fields get their default values, the instance field initialisers and the initialiser blocks run, the constructor of the superclass runs, and finally the constructor of the subclass runs. Only after all of that does the reference become usable by the caller.

public class Main {
    public static void main(String[] args) {
        Laptop laptop = new Laptop("pro", 16);
        System.out.println(laptop.describe());
    }
}

class Device {
    protected final String model;
    Device(String model) {
        this.model = model;
        System.out.println("device ready: " + model);
    }
}

class Laptop extends Device {
    private final int ram;
    Laptop(String model, int ram) {
        super(model);
        this.ram = ram;
        System.out.println("laptop ready: " + model + " with " + ram + "GB");
    }
    String describe() { return model + "/" + ram; }
}

The output confirms the order. The device constructor runs first and prints that the device is ready, and only afterwards does the laptop constructor run and print its own message. That ordering is not a style choice; it is forced, because the subclass cannot use inherited state until the superclass has finished initialising it.

Two implications are worth drawing out. First, a subclass constructor must call the super constructor before doing anything else, and if the parent has no no-argument constructor you have to say which one you mean. Second, an overridden method called from a superclass constructor runs the subclass version, before the subclass fields are initialised, which is a classic source of surprising behaviour.

The final stage of the lifecycle is reclamation. When an object becomes unreachable the collector reclaims it, but that is only about memory. Anything else the object holds has to be released explicitly, and the try-with-resources pattern is the safe way to do that.

The correct pattern is try-with-resources. Declare the resource in the try header, and the runtime guarantees that close is called when the block finishes, on every exit path including an exception. The resource type has to implement AutoCloseable, whose single method is close.

public class Main {
    public static void main(String[] args) {
        try (Audit log = new Audit("orders")) {
            log.write("created");
            log.write("shipped");
        }
        System.out.println("audit closed");
    }
}

class Audit implements AutoCloseable {
    private final String file;
    Audit(String file) { this.file = file; }
    void write(String line) { System.out.println(file + ": " + line); }
    public void close() { System.out.println("flushing " + file); }
}

The output shows the ordering that makes this pattern useful. The two writes happen inside the block, then the flushing message appears as the block ends, and only after that does the statement following the try run. If the write method had thrown, close would still have run, and the original exception would have been preserved rather than swallowed.

For several resources, list them in the try header and they are closed in the reverse order of creation, which handles the dependency ordering automatically. If one close throws while another is already failing, the second exception is attached to the first as a suppressed exception rather than replacing it.

Beyond the syntax, the design principle is ownership. The object that opens a resource should be the object that closes it, and the interface it exposes should not let a caller forget. Passing a callback into a method that owns the resource, so the resource is opened and closed inside that method, removes the chance of a leak entirely. That pattern is worth mentioning, because it turns cleanup from a discipline into a guarantee.

An object starts as allocated memory with all its fields at their default values. Its initialisers then run, followed by the constructors from the superclass down to the concrete class. At that point the object is fully constructed, and it lives on for as long as something can reach it.

During that life it may be shared between threads, mutated through its methods, and passed around by reference. If the code stops referring to it and nothing else can reach it, it becomes eligible for collection, and the garbage collector reclaims the memory at a time of its choosing.

The word eligible matters. Java collectors are not required to run the moment an object becomes unreachable, so you cannot rely on finalisation timing for anything that has to happen promptly. That is the reason resources are released explicitly rather than by a destructor.

The lifecycle is also the reason object identity is a design topic. Two objects created from the same class have separate state but share behaviour, and a reference can outlive the code that created the object, which is why immutability is so often the safer default for values passed between threads.