Constructors & Lifecycle - Learning Module

Loading content...

0/246

Object Destruction and Cleanup

The Art of Dying Gracefully

Objects are born through constructors. They live, performing their duties, being called upon by the system. And eventually, inevitably, they must die. But how an object dies matters enormously.

An object that simply disappears—abandoning open files, unreleased database connections, unfreed memory, or locked resources—poisons the system it leaves behind. Resource leaks accumulate silently until the system crashes, runs out of connections, or corrupts data. The cleanup phase of an object's lifecycle is every bit as critical as its construction.

What You Will Learn

By the end of this page, you will understand why explicit cleanup is necessary even in garbage-collected languages, how destructors and finalizers work (and why to avoid them), and modern patterns like try-with-resources that ensure clean object death. You'll learn to design objects that release resources reliably.

Why Object Cleanup Matters

Many developers, especially those who learned on garbage-collected languages, have a dangerous misconception: "The garbage collector handles cleanup; I don't need to worry about it."

This is only partially true—and the false part can destroy your system.

What garbage collectors DO handle:

Reclaiming memory of unreachable objects
Managing heap allocation

What garbage collectors DON'T handle:

File handles
Database connections
Network sockets
Locks and synchronization primitives
Native memory (allocated outside JVM/Runtime)
Temporary files
GPU resources
Any external system resource

Resources Requiring Explicit Cleanup
Resource Type	Consequence of Not Cleaning	Typical Limit
File handles	OS refuses to open new files	~65,000 per process (Linux)
Database connections	Connection pool exhausted; DB overloaded	~100-500 per pool
Network sockets	Port exhaustion; connection failures	~65,000 per host
Memory-mapped files	Address space exhaustion	Limited by virtual memory
Thread handles	Cannot create new threads	OS-dependent (thousands)
Locks/Mutexes	Deadlocks; resource starvation	Logical limit: 1 holder

The Resource Leak Death Spiral

Resource leaks are insidious because they don't cause immediate failure. The system works fine for days or weeks. Then, suddenly, it crashes—but not near the leaking code. The crash happens wherever the exhausted resource is next requested, making diagnosis extremely difficult.

The fundamental rule:

If you acquire a resource, you are responsible for releasing it. The garbage collector only handles memory. Everything else is on you.

This is why understanding object cleanup is essential, even in modern, garbage-collected languages.

Destructors: Deterministic Cleanup

In languages without garbage collection (C++) or with deterministic cleanup (Rust), destructors provide automatic, predictable cleanup when objects go out of scope.

Key characteristics of destructors:

Automatic invocation — Called automatically when object goes out of scope
Deterministic timing — Exact moment of cleanup is known and predictable
LIFO order — Objects destroyed in reverse order of construction
Exception-safe — Destructors still run even if exceptions occur

Destructor Pattern (C++)
C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
class FileHandler {
private:
    FILE* file_;
    std::string path_;
 
public:
    // Constructor acquires resource
    FileHandler(const std::string& path) : path_(path) {
        file_ = fopen(path.c_str(), "r");
        if (!file_) {
            throw std::runtime_error("Cannot open file: " + path);
        }
        std::cout << "Opened: " << path << std::endl;
    }
    
    // Destructor releases resource
    ~FileHandler() {
        if (file_) {
            fclose(file_);
            std::cout << "Closed: " << path_ << std::endl;
        }
    }
    
    // Prevent copying (or implement deep copy)
    FileHandler(const FileHandler&) = delete;
    FileHandler& operator=(const FileHandler&) = delete;
    
    std::string readLine() {
        // ... read from file_ ...
    }
};
 
void processFile(const std::string& path) {
    FileHandler file(path);  // Constructor opens file
    
    // Use the file...
    std::string line = file.readLine();
    
    // Even if an exception occurs here, destructor runs!
    process(line);
    
}  // <-- Destructor automatically called here, file closed
 
// This pattern is called RAII: Resource Acquisition Is Initialization

RAII (Resource Acquisition Is Initialization):

This C++ pattern ties resource lifetime to object lifetime:

Constructor acquires the resource
Destructor releases the resource
Resource is valid for exactly as long as the object exists

RAII is considered the gold standard for resource management because it's automatic, exception-safe, and deterministic.

Why Java/Python Don't Have True Destructors

Garbage-collected languages can't have true destructors because the GC runs at unpredictable times. You might create an object, lose all references to it, but it could linger in memory for seconds, minutes, or hours before the GC collects it. For resources that must be released promptly, this unpredictability is unacceptable.

Finalizers: The Dangerous Alternative

Java and other GC languages offer finalizers (or similar mechanisms like Python's __del__)—methods called when the garbage collector decides to reclaim an object. These might seem like destructors, but they are fundamentally different and dangerous.

Why finalizers are problematic:

Finalizer Problems

•No timing guarantee — Finalizer might run milliseconds after object becomes unreachable, or never at all.
•No ordering guarantee — Finalizers may run in any order, even if objects have dependencies.
•Performance penalty — Objects with finalizers require extra GC work; they survive longer.
•Exception vulnerability — Exceptions in finalizers are ignored; resources may leak anyway.
•Resurrection risk — Finalizers can accidentally make objects reachable again, creating zombies.
•Security concerns — Malicious subclasses can exploit finalizers to resurrect partially-constructed objects.
•Deprecated in Java 9+ — The finalize() method is officially deprecated, signaling you shouldn't use it.

Finalizer Problems Demo
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// ❌ BAD: Using finalizers for resource cleanup
public class ResourceHolder {
    private Connection connection;
    
    public ResourceHolder() {
        this.connection = Database.connect();
    }
    
    // DON'T DO THIS
    @Override
    protected void finalize() throws Throwable {
        try {
            if (connection != null) {
                connection.close();  // Might never be called!
            }
        } finally {
            super.finalize();
        }
    }
}
 
// Problems:
// 1. Under heavy load, GC might not run for minutes/hours
// 2. Database connection pool exhausted before finalizers run
// 3. System crashes, but finalizers for leaked resources show no issue
// 4. Post-mortem: "All finalizers were written correctly..."
 
// What happens in practice:
void createResources() {
    for (int i = 0; i < 1000; i++) {
        new ResourceHolder();  // Connections opened
        // Objects unreachable, but finalizers haven't run!
        // 1000 connections open, pool exhausted
    }
    // Program proceeds normally, unaware of the leak
    // Later: "Connection pool exhausted" in unrelated code
}

The No-Finalizer Rule

In modern Java development, the rule is simple: DON'T USE FINALIZERS. They are deprecated, unreliable, and dangerous. The only legitimate use (as a safety net for native resources) is better handled by Cleaner. Use try-with-resources and explicit close() methods instead.

The Disposable/Closeable Pattern

Since finalizers are unreliable, garbage-collected languages use the Disposable pattern: objects that hold resources implement an interface declaring a cleanup method that users must call explicitly.

Common interfaces:

Language	Interface	Method
Java	`AutoCloseable` / `Closeable`	`close()`
C#	`IDisposable`	`Dispose()`
Python	Context Manager	`__exit__()`
Go	(convention)	`Close()`
Rust	`Drop` trait	`drop()` (automatic)

Implementing AutoCloseable
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
// A properly implemented auto-closeable resource
public class DatabaseSession implements AutoCloseable {
    private final Connection connection;
    private final String sessionId;
    private boolean closed = false;
    
    public DatabaseSession(String connectionUrl) throws SQLException {
        this.sessionId = UUID.randomUUID().toString();
        this.connection = DriverManager.getConnection(connectionUrl);
        this.connection.setAutoCommit(false);
        
        System.out.println("Session " + sessionId + " opened");
    }
    
    public ResultSet query(String sql) throws SQLException {
        checkNotClosed();
        return connection.createStatement().executeQuery(sql);
    }
    
    public void commit() throws SQLException {
        checkNotClosed();
        connection.commit();
    }
    
    public void rollback() throws SQLException {
        checkNotClosed();
        connection.rollback();
    }
    
    private void checkNotClosed() {
        if (closed) {
            throw new IllegalStateException(
                "Session " + sessionId + " is already closed"
            );
        }
    }
    
    @Override
    public void close() throws SQLException {
        if (!closed) {
            closed = true;
            
            try {
                // Rollback any uncommitted transaction
                if (!connection.getAutoCommit()) {
                    connection.rollback();
                }
            } finally {
                connection.close();
                System.out.println("Session " + sessionId + " closed");
            }
        }
        // Multiple close() calls are safe - idempotent
    }
}

Design Notes for AutoCloseable

Make close() idempotent—safe to call multiple times. 2. Check for already-closed state in other methods. 3. Prefer throwing IllegalStateException on use-after-close. 4. Document what happens if close() isn't called. 5. Consider implementing a safety-net finalizer that logs a warning (but don't rely on it).

Try-With-Resources: Automatic Cleanup

The Disposable pattern requires manual calling of close(). This is still error-prone—developers forget, exception paths skip cleanup, code gets complex. Try-with-resources (Java) and with statements (Python) solve this by automatically calling cleanup methods.

This pattern ensures resources are cleaned up even if exceptions occur, without complex try-finally blocks.

Without TWR
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// ❌ Manual cleanup - verbose, error-prone
Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
 
try {
    conn = getConnection();
    stmt = conn.createStatement();
    rs = stmt.executeQuery(sql);
    
    while (rs.next()) {
        process(rs);
    }
} catch (SQLException e) {
    log.error("Query failed", e);
} finally {
    // Must close in reverse order
    // Must handle each close exception
    if (rs != null) {
        try {
            rs.close();
        } catch (SQLException e) {
            log.warn("Failed to close ResultSet", e);
        }
    }
    if (stmt != null) {
        try {
            stmt.close();
        } catch (SQLException e) {
            log.warn("Failed to close Statement", e);
        }
    }
    if (conn != null) {
        try {
            conn.close();
        } catch (SQLException e) {
            log.warn("Failed to close Connection", e);
        }
    }
}

With TWR
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// ✅ Try-with-resources - clean, safe
try (
    Connection conn = getConnection();
    Statement stmt = conn.createStatement();
    ResultSet rs = stmt.executeQuery(sql)
) {
    while (rs.next()) {
        process(rs);
    }
} catch (SQLException e) {
    log.error("Query failed", e);
}
 
// close() called automatically on:
// - rs (first)
// - stmt (second)
// - conn (last)
// Even if exceptions occur inside the try block
// Even if close() throws an exception
 
// Exceptions from close() are "suppressed"
// and attached to the primary exception

Python Context Manager
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# Python's 'with' statement provides the same guarantee
with open('data.txt', 'r') as file:
    content = file.read()
    process(content)
# file.close() called automatically when exiting the 'with' block
 
# Multiple resources
with open('input.txt') as infile, open('output.txt', 'w') as outfile:
    for line in infile:
        outfile.write(transform(line))
# Both files closed automatically
 
# Works with any context manager
with DatabaseSession(url) as session:
    results = session.query("SELECT * FROM users")
    for row in results:
        process(row)
    session.commit()
# session.close() called automatically

Always Use Try-With-Resources

For any resource that implements AutoCloseable or Closeable, always use try-with-resources. There is no reason to manually manage resource cleanup in modern Java. The same applies to Python's 'with' statement for context managers.

Handling Complex Cleanup Scenarios

Real-world cleanup often involves complications: resources with dependencies, partial initialization, cleanup that can itself fail, and resources that must be cleaned up in specific orders.

Complex Cleanup Patterns
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
// Pattern: Composite resource with ordered cleanup
public class TransactionContext implements AutoCloseable {
    private final Connection connection;
    private final Session session;
    private final Lock lock;
    private boolean committed = false;
    
    public TransactionContext(String dbUrl, String sessionId, Lock lock) 
            throws SQLException {
        // Acquire resources in order, tracking progress for rollback
        Connection conn = null;
        Session sess = null;
        boolean lockAcquired = false;
        
        try {
            // Step 1: Acquire lock
            lock.lock();
            lockAcquired = true;
            
            // Step 2: Open connection
            conn = DriverManager.getConnection(dbUrl);
            conn.setAutoCommit(false);
            
            // Step 3: Create session
            sess = new Session(conn, sessionId);
            
            // All resources acquired successfully
            this.connection = conn;
            this.session = sess;
            this.lock = lock;
            
        } catch (Exception e) {
            // Cleanup in reverse order of what we acquired
            if (sess != null) {
                try { sess.close(); } catch (Exception ignored) {}
            }
            if (conn != null) {
                try { conn.close(); } catch (Exception ignored) {}
            }
            if (lockAcquired) {
                lock.unlock();
            }
            throw e;
        }
    }
    
    public void commit() throws SQLException {
        connection.commit();
        committed = true;
    }
    
    @Override
    public void close() throws SQLException {
        SQLException suppressed = null;
        
        try {
            // Step 1: Handle transaction state
            if (!committed) {
                try {
                    connection.rollback();
                } catch (SQLException e) {
                    suppressed = e;
                }
            }
        } finally {
            try {
                // Step 2: Close session
                session.close();
            } catch (SQLException e) {
                if (suppressed != null) {
                    e.addSuppressed(suppressed);
                }
                suppressed = e;
            } finally {
                try {
                    // Step 3: Close connection
                    connection.close();
                } catch (SQLException e) {
                    if (suppressed != null) {
                        e.addSuppressed(suppressed);
                    }
                    suppressed = e;
                } finally {
                    // Step 4: Release lock (always, no matter what)
                    lock.unlock();
                }
            }
        }
        
        if (suppressed != null) {
            throw suppressed;
        }
    }
}
 
// Usage - despite complexity inside, usage is simple
try (TransactionContext ctx = new TransactionContext(url, id, lock)) {
    doWork(ctx);
    ctx.commit();
}

Cleanup Must Not Fail Silently

When cleanup fails, you must either throw an exception or log a prominent warning. Silent failure during cleanup leads to resource leaks that are extremely difficult to diagnose. Use suppressed exceptions to avoid losing error information.

The Cleaner API: A Safety Net

Java 9 introduced java.lang.ref.Cleaner as a replacement for finalizers. It provides a safer (though still unreliable) way to clean up resources when an object becomes phantom-reachable.

When to use Cleaner:

As a safety net backup when try-with-resources isn't used
For native resources that must eventually be freed
Never as the primary cleanup mechanism

Cleaner As Safety Net
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
public class NativeResource implements AutoCloseable {
    // Shared Cleaner instance
    private static final Cleaner CLEANER = Cleaner.create();
    
    // The actual resource handle
    private final long nativeHandle;
    
    // The cleanable registered with the Cleaner
    private final Cleaner.Cleanable cleanable;
    
    // State held separately for the cleaning action
    // IMPORTANT: This must NOT reference the NativeResource instance!
    private static class CleaningAction implements Runnable {
        private long handle;
        
        CleaningAction(long handle) {
            this.handle = handle;
        }
        
        @Override
        public void run() {
            if (handle != 0) {
                freeNativeResource(handle);  // Native call
                handle = 0;
                System.out.println("Safety net: cleaned native resource");
            }
        }
    }
    
    public NativeResource() {
        this.nativeHandle = allocateNativeResource();  // Native call
        
        // Register cleaning action as safety net
        CleaningAction action = new CleaningAction(nativeHandle);
        this.cleanable = CLEANER.register(this, action);
    }
    
    // Public methods use nativeHandle...
    
    @Override
    public void close() {
        // Explicit cleanup - this is the preferred path
        cleanable.clean();  // Runs the CleaningAction and deregisters
        System.out.println("Explicitly closed native resource");
    }
    
    // Native methods (would be implemented in C/C++)
    private static native long allocateNativeResource();
    private static native void freeNativeResource(long handle);
}
 
// Preferred usage: try-with-resources
try (NativeResource resource = new NativeResource()) {
    useResource(resource);
}  // close() called, native resource freed immediately
 
// If someone forgets try-with-resources, Cleaner eventually runs
// (but with unpredictable timing - this is the safety net, not the plan)

Cleaner Best Practices

The cleaning action must not reference the object being cleaned (would prevent GC). 2. Use a static nested class or lambda that captures only the resource handle. 3. Share a single Cleaner instance per class. 4. Always provide a close() method as the primary cleanup path. 5. Make close() call cleanable.clean() to deregister the safety net.

Summary: Complete Lifecycle Management

We've completed our journey through the object lifecycle—from construction through cleanup. Let's consolidate the key principles:

Key Takeaways

•GC handles memory, not resources — You are responsible for files, connections, sockets, locks, and all external resources.
•Finalizers are dangerous and deprecated — Never rely on them; their timing and execution are unpredictable.
•Implement AutoCloseable for resource holders — Provide explicit close() methods and make them idempotent.
•Always use try-with-resources — It's cleaner, safer, and handles exceptions correctly.
•Use Cleaner as a safety net only — For native resources, Cleaner can catch forgotten cleanup, but it's not the primary mechanism.
•Design for the full lifecycle — Objects should be born valid, live correctly, and die gracefully.

What's next:

With constructors and object lifecycle mastered, we're now prepared to explore access modifiers and visibility—how we control what parts of our objects are exposed to the outside world and protect encapsulation.

Module Complete

You have completed the Constructors and Object Lifecycle module. You now understand how to design objects that are born valid through proper constructor design and die gracefully through disciplined resource cleanup. This foundation is essential for building robust, professional-quality software.