Expected Answer (Java 26)

In Java, deterministic resource management is handled via the AutoCloseable interface and the try-with-resources statement.

1. AutoCloseable: An interface with a single close() method.
2. try-with-resources: Automatically calls close() on any resource that implements AutoCloseable when the block exits.
3. Finalizers vs. Cleaners: Java 9+ deprecated Finalizers in favor of java.lang.ref.Cleaner, which provides a safer way to perform cleanup when the GC reclaims an object.

Why It Matters

The Garbage Collector manages memory, but it does not manage external resources like file handles, database connections, or network sockets. Failing to close these resources leads to “Resource Leaks,” which can crash an application or prevent other processes from accessing the OS resources.

Code Example

// try-with-resources (Automatic Cleanup)
try (var fileStream = new FileInputStream("data.txt");
     var scanner = new Scanner(fileStream)) {
    while (scanner.hasNextLine()) {
        System.out.println(scanner.nextLine());
    }
} catch (IOException e) {
    e.printStackTrace();
}
// Both scanner and fileStream are closed here automatically

Common Mistakes

• Manual Closing: Closing resources in a finally block is prone to errors (e.g., if close() itself throws an exception, it might suppress the original exception).
• Forgetting to implement AutoCloseable: When creating custom classes that wrap native resources, developers often forget to implement AutoCloseable, making it impossible to use them with try-with-resources.

Follow-up Questions

• Closeable vs AutoCloseable? (Answer: Closeable is older and restricted to IOException; AutoCloseable is more general and can throw any Exception).
• What happens if multiple resources throw exceptions during close? (Answer: The first exception is thrown, and subsequent exceptions from other close() calls are added as “Suppressed Exceptions”).

Expected Answer (PHP 8.5)

In PHP, resource management is handled via reference counting and the Garbage Collector, with a specific focus on the request lifecycle.

1. Destructors (__destruct): Automatically called when there are no more references to an object, or during the script shutdown.
2. Explicit Cleanup: Because PHP scripts are usually short-lived (one request), most resources (memory, DB connections) are automatically freed at the end of the request.
3. RAII Pattern: Using the destructor to close file handles or network sockets.

Why It Matters

In long-running CLI scripts or environments like RoadRunner/Swoole, failing to explicitly manage resources can lead to memory leaks and exhausted file descriptors, as the process does not exit after every request.

Code Example

class FileManager
{
    private $handle;

    public function __construct($filename)
    {
        $this->handle = fopen($filename, 'w');
    }

    public function __destruct()
    {
        if ($this->handle) {
            fclose($this->handle);
        }
    }
}

Common Mistakes

• Relying on __destruct for critical timing: You cannot guarantee exactly when __destruct will be called in a complex object graph with circular references.
• Circular References: Before PHP 5.3, circular references caused memory leaks. Modern PHP handles this with a cycle collector, but it still has a performance cost.

Follow-up Questions

• What is the ‘gc_collect_cycles’ function? (Answer: It forces the collection of any existing garbage cycles).
• How does PHP handle DB connections at the end of a script? (Answer: Standard PDO connections are closed automatically when the script ends, unless persistent connections are used).

Expected Answer (Python 3.14)

A context manager encapsulates setup and cleanup around a with block. Python calls __enter__() before the block and __exit__(exc_type, exc, traceback) when it leaves, including when an exception is raised. Returning a truthy value from __exit__ suppresses that exception, so this should be done deliberately.

class Transaction:
    def __enter__(self):
        print("begin")
        return self

    def __exit__(self, exc_type, exc, traceback):
        if exc_type is None:
            print("commit")
        else:
            print("rollback")
        return False  # Propagate any exception.

with Transaction():
    pass

The same pattern safely handles files, database transactions, locks, and temporary resources. It is often clearer and safer than relying on callers to remember a later cleanup call.

Why It Matters

Reliable cleanup prevents resource leaks, locked files, unreturned database connections, and locks left held after an error. The with form makes the resource lifetime obvious in code review.

Common Mistakes

• Calling close() only on the happy path: An exception before that call can leak the resource.
• Returning True from __exit__ unintentionally: This swallows an exception and can conceal a failure.
• Confusing __enter__’s return value with the manager: The value returned by __enter__ is what as value receives.

Follow-up Questions

• How do you compose multiple resources? (Answer: Put multiple managers in one with statement or nest the blocks.)
• What does contextlib.contextmanager require? (Answer: A generator with one yield separating setup from cleanup.)

Expected Answer (Rust 1.97.1)

Rust applies RAII: a resource is acquired by an owning value and released when that value is dropped. When an owned local leaves scope, Rust calls its destructor deterministically. A type can implement Drop for cleanup such as closing a file, returning a connection, or releasing a lock.

To release a resource earlier, pass it to std::mem::drop. Rust prevents directly calling Drop::drop, which would otherwise risk running cleanup twice when the value later leaves scope.

struct AuditGuard(&'static str);

impl Drop for AuditGuard {
    fn drop(&mut self) {
        println!("released {}", self.0);
    }
}

fn main() {
    let guard = AuditGuard("connection");
    println!("using connection");
    std::mem::drop(guard);
    println!("connection is already released");
}

Ownership moves transfer cleanup responsibility to the new owner, so a value is cleaned up exactly once unless intentionally leaked through specialized APIs.

Why It Matters

RAII prevents resource leaks across early returns and error paths without requiring a garbage collector. It is the foundation of safe files, locks, transactions, and scoped guards in Rust.

Common Mistakes

• Expecting a value to be dropped immediately after its last use: The compiler may keep it alive to the end of scope; call std::mem::drop when early release is required.
• Calling Drop::drop directly: Rust disallows this because the value would be dropped again later.
• Performing fallible work in Drop: Cleanup cannot return an error to the caller, so critical fallible work should use an explicit method first.

Follow-up Questions

• In what order are local variables dropped? (Answer: Reverse order of their creation.)
• Why are mutex guards often bound to a local variable? (Answer: The guard releases the lock automatically when it is dropped.)

Expected Answer (C++23)

C++ uses RAII (Resource Acquisition Is Initialization): a resource is acquired by an object’s constructor and released by its destructor when the object leaves scope. This makes cleanup deterministic across normal returns and exceptions, and applies to files, locks, sockets, transactions, and heap ownership.

Avoid manually pairing new/delete or lock/unlock in application code. Encapsulate the resource in a standard RAII type such as std::unique_ptr, std::lock_guard, or a dedicated wrapper.

#include <mutex>

std::mutex cache_mutex;

void update_cache() {
    std::lock_guard<std::mutex> lock(cache_mutex);
    // The mutex is released automatically, including if this block throws.
}

Why It Matters

RAII prevents leaks and forgotten cleanup on every exit path without requiring garbage collection. It is one of C++‘s core reliability mechanisms and a foundation of exception-safe code.

Common Mistakes

• Managing resources with raw new and delete: Manual ownership is error-prone; use an owning RAII wrapper.
• Assuming destructors can safely throw during unwinding: A second exception during stack unwinding calls std::terminate.
• Calling release() on a smart pointer without assigning ownership elsewhere: This discards automatic cleanup and can leak the resource.

Follow-up Questions

• Why do destructors run during exception unwinding? (Answer: To release objects whose scopes are being exited.)
• What is the purpose of std::lock_guard? (Answer: It locks a mutex on construction and unlocks it on destruction.)