finally vs finalize() vs final

They sound alike and have nothing to do with each other. final is a keyword that makes a class, method or variable unchangeable. finally is a block that runs after a try statement no matter how it exits. finalize() was a method on Object that the garbage collector used to call before reclaiming an object.

The detail worth knowing is that finalize() has been deprecated for removal and was scheduled for deletion. It was never reliable: the collector may or may not run it, it may run it long after the object became unreachable, and it runs on the finalizer thread rather than your own thread, so any code inside it has to be thread-safe. Two objects with finalizers also promote each other into a special queue, which costs memory and delays collection. In effect it was an attempt to give Java deterministic cleanup that never worked, and the language replaced it with better tools.

What replaced it depends on what you were trying to do. For a resource that holds an operating system handle, use try-with-resources and do not rely on finalization at all. For a cleanup that must happen regardless of how the object was discarded, implement java.lang.AutoCloseable and close it explicitly. And when you genuinely need a hook that runs when the object becomes unreachable, java.lang.ref.Cleaner gives you an explicit registration mechanism without the finalization queue.

The interview summary is short: final is about immutability, finally is about cleanup on every path, and finalize was a broken idea that has been retired.

Because it never delivered what it promised. The contract was that the collector would call finalize before reclaiming an object, so you could release resources there. In practice the collector is under no obligation to call it at all, and when it does, it can be arbitrarily long after the object became unreachable. That makes it useless for anything time-sensitive and dangerous for anything that must happen exactly once.

There are concrete failure modes. If the JVM is shut down, finalizers are not guaranteed to run at all, so a resource can leak permanently. If the finalizer throws, the exception is silently ignored. If finalize blocks, it holds up the finalizer thread and everything queued behind it. And the finalizer queue itself keeps objects alive longer than they need to be, which shows up as unexplained memory pressure.

The replacements depend on the situation. If the object holds a resource that must be released — a file handle, a socket, a database connection — implement AutoCloseable and use try-with-resources, so the close happens deterministically at a point you control. If you need a cleanup tied to the object's lifetime rather than to a scope, use java.lang.ref.Cleaner, which lets you register a cleaning action explicitly and even lets you clean up manually when you know the object is finished.

public class Main {
    public static void main(String[] args) {
        try {
            throw new IllegalStateException("boom");
        } catch (IllegalStateException e) {
            System.out.println("caught: " + e.getMessage());
        } finally {
            System.out.println("finally always runs");
        }

        // A return inside finally discards the in-flight exception.
        System.out.println("result: " + swallow());
    }

    static int swallow() {
        try {
            throw new IllegalStateException("boom");
        } finally {
            return 99;      // the exception is discarded
        }
    }
}

The output shows the two behaviours of a finally block. It runs on every path, including when the try block throws and the exception is caught. And the swallow method demonstrates why a return in finally is dangerous: the IllegalStateException is raised and then discarded, and the method returns 99 as though nothing had gone wrong.

A finally block runs when the try statement it belongs to finishes, whatever the reason. That covers four cases: the try body completed normally, it returned, it threw an exception that a catch clause handled, or it threw an exception that was not handled and is propagating out. In the last case the finally block still runs first, and the exception continues on its way afterwards unless the finally block itself does something abrupt.

A return inside finally is the problem case. It overrides the pending outcome completely. If the try block had thrown, that exception is discarded — it never reaches the caller and never appears in a log. If the try block was about to return a value, the value from finally is the one the caller receives. The JVM does this because the finally block completes abruptly, and an abrupt completion in finally overrides the abrupt completion of the try block.

So a return in finally turns a failure into a success, silently. A caller that expected a specific exception type now gets a normal return value instead, and any code that was relying on the exception for control flow never sees it.

public class Main {
    public static void main(String[] args) {
        // finally runs on every exit path.
        System.out.println("normal  : " + normal());
        System.out.println("thrown  : " + thrown());
        System.out.println("returned: " + swallows());
    }

    static int normal() {
        try {
            return 1;
        } finally {
            System.out.println("  finally after a normal return");
        }
    }

    static int thrown() {
        try {
            throw new IllegalStateException("boom");
        } catch (IllegalStateException e) {
            return 2;
        } finally {
            System.out.println("  finally after a caught exception");
        }
    }

    static int swallows() {
        try {
            throw new IllegalStateException("boom");
        } finally {
            return 99;   // the in-flight exception is discarded
        }
    }
}

The safe alternatives. If you need a value out of a try whose finally does cleanup, assign the value to a local variable inside the try and return it after the whole statement. If you need to suppress an exception deliberately, catch it explicitly and decide what to do, rather than hiding it in a finally block. And if the cleanup is closing a resource, use try-with-resources, where the compiler generates the correct behaviour and a return cannot defeat it.

A return inside finally swallows the exception, because the finally block completes normally and discards the in-flight throw: