finalize (Deprecated)

## What finalize() is **Java** is a *garbage-collected* language: you allocate objects with `new`, and a background subsystem called the **garbage collector (GC)** automatically frees the memory of objects that are no longer **reachable** (no live part of the program can still refer to them). You never call `free`/`delete` yourself. `finalize()` was an early attempt to bolt C++-style *destructors* onto this model. Every Java class implicitly extends `java.lang.Object`, which historically declared: ```java protected void finalize() throws Throwable { } ``` A class could **override** (provide its own version of) this method. The contract was: *just before* the GC reclaims an object that overrides `finalize()`, the JVM will invoke that method once, giving the object a final chance to release resources it owned — for example closing an open OS **file handle** or freeing **native memory** (memory allocated outside the Java heap by C/C++ code). ## How the JVM actually runs it Finalization is a multi-step, *asynchronous* dance, not a simple call: 1. The GC discovers the object is unreachable. 2. If the object overrides `finalize()`, the GC does **not** free it yet. Instead it places the object on an internal **finalization queue** and keeps it alive. 3. A separate, low-priority **finalizer thread** later pulls objects off that queue and runs their `finalize()` methods. 4. Only on a *subsequent* GC cycle, once the object is unreachable *again*, is its memory actually reclaimed. So a finalizable object needs **at least two GC cycles** to die, and its cleanup runs on a thread you don't control, at a time you can't predict. ## Why this is a problem (the four classic flaws) - **No timing guarantee.** The **JLS (Java Language Specification)** promises only that `finalize()` runs *at most once*, *before* reclamation — never *when*. The finalizer thread may be starved, the queue may back up, and crucially **if the JVM exits, pending finalizers may never run at all**. So you can't use it to flush data or close a network connection reliably. - **Performance penalty.** Keeping objects alive an extra cycle, queueing them, and running them on a single thread makes finalizable objects dramatically slower to create and collect (commonly cited as roughly an order of magnitude). They also delay reclamation, raising memory pressure. - **The resurrection problem.** Because `finalize()` runs arbitrary code with `this` in scope, it can store `this` into a static field or other live structure — making the *supposedly dead* object reachable again ("resurrected"). The object is now alive, but the JLS says `finalize()` will **never run again** for it, so a second cleanup is silently skipped. This is a footgun, not a feature. - **Reliability / exception swallowing.** If `finalize()` throws an exception, the finalizer thread simply logs nothing useful and *abandons* finalization of that object — the rest of the cleanup is skipped, often leaving the object in a corrupt state with no warning. There are also security concerns (a malicious subclass overriding `finalize()` can interfere with a half-constructed object after its constructor throws), which is why security-sensitive classes use a *finalizer guardian*. ## Deprecation timeline - **Java 9:** `Object.finalize()` was marked `@Deprecated`. - Later releases (`Java 18`, via **JEP 421**) deprecated finalization **for removal**, with flags to disable it, and it is being phased out of the platform entirely. ## What to use instead 1. **`try-with-resources` + `AutoCloseable`** — the *deterministic* solution. A class that owns a resource implements `java.lang.AutoCloseable` (or `java.io.Closeable`) and puts cleanup in `close()`. The caller wraps it in `try (var r = new Resource()) { ... }`; the compiler guarantees `close()` runs at the end of the block, exactly when you expect, even on exception. This is how every modern stream/connection should be managed. ```java try (var in = new FileInputStream("data.bin")) { // use in } // in.close() called here, deterministically ``` 2. **`java.lang.ref.Cleaner`** (Java 9+) — the *safety-net* solution for native/off-heap resources, when you also want cleanup if the caller forgets to call `close()`. You register a cleanup action (a `Runnable` that must **not** reference the owning object, to avoid keeping it alive) with a shared `Cleaner`; when the object becomes unreachable, the cleaner runs the action on its own thread. It is built on `PhantomReference` and is more predictable and less dangerous than `finalize()` — but still not a substitute for deterministic `close()`. Treat it strictly as a backstop. **Bottom line:** never write a new `finalize()`. Use `try-with-resources` for deterministic cleanup, and a `Cleaner` only as a last-resort safety net for native resources.