Garbage Collection

public void createObjects() {
    for (int i = 0; i < 1000; i++) {
        Object obj = new Object();  // allocated on the heap
    }  // once this loop iteration ends and 'obj' goes out of scope, the object becomes eligible for GC
    // No explicit free()/delete needed -- the garbage collector reclaims it automatically, eventually
}

Common follow-ups: What specifically makes an object 'eligible' for garbage collection -- reference counting, or something else?;What are the trade-offs of GC-managed memory versus manual memory management in terms of predictability and performance?

// Conceptual illustration of generational promotion (not actual code, just illustrating the process)
// 1. New objects allocated in Eden space
// 2. Eden fills up -> minor GC triggers, surviving objects move to a Survivor space
// 3. Objects surviving several minor GCs get PROMOTED to the old generation
// 4. Old generation eventually fills up -> a much more expensive major/full GC occurs

Common follow-ups: What determines how many minor GC survivals it takes before an object gets promoted to the old generation?;Why is a major/full GC typically so much more expensive than a minor GC?

# Selecting a garbage collector via JVM flags
java -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -jar app.jar        # default, general-purpose, tunable pause target
java -XX:+UseZGC -jar app.jar                                   # ultra-low latency, very large heaps
java -XX:+UseShenandoahGC -jar app.jar                           # similarly low-latency, different implementation approach

Common follow-ups: What specific architectural technique (like colored pointers in ZGC) enables these collectors to perform most work concurrently with running application threads?;What's the memory footprint and CPU overhead cost of choosing a low-latency collector over G1 for a workload that doesn't actually need sub-millisecond pauses?

// SoftReference: cache that survives unless memory is genuinely needed elsewhere
Map<String, SoftReference<byte[]>> imageCache = new HashMap<>();
imageCache.put("logo", new SoftReference<>(loadImageBytes("logo.png")));

// WeakReference: doesn't keep the referent alive on its own
WeakReference<LargeObject> weakRef = new WeakReference<>(new LargeObject());
// Once no strong references to the LargeObject remain, it CAN be collected
// even though weakRef itself still technically exists

Common follow-ups: Why does WeakHashMap use weak references specifically for its keys rather than its values?;What's the practical use case for PhantomReference given get() always returns null on it?

# Capture a heap dump from a running JVM
jmap -dump:live,format=b,file=heapdump.hprof <pid>

# Automatically capture a heap dump on OutOfMemoryError
java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof -jar app.jar

# Then analyze heapdump.hprof with Eclipse Memory Analyzer (MAT),
# looking specifically at the 'Leak Suspects' report and dominator tree

Common follow-ups: Why can a memory leak still occur in a garbage-collected language despite the GC running correctly and doing exactly what it's designed to do?;What's the specific danger of ThreadLocal usage combined with a thread pool that reuses threads across many logical tasks?

// Deprecated/removed approach -- DO NOT USE in modern code
@Deprecated
protected void finalize() throws Throwable {
    closeNativeResource();  // no guarantee of WHEN (or if) this ever actually runs
}

// Modern replacement: Cleaner, for genuine last-resort native resource cleanup
public class NativeResourceHolder implements AutoCloseable {
    private static final Cleaner cleaner = Cleaner.create();
    private final Cleaner.Cleanable cleanable;

    public NativeResourceHolder() {
        long nativeHandle = allocateNative();
        cleanable = cleaner.register(this, () -> freeNative(nativeHandle));
    }
    public void close() { cleanable.clean(); }  // still prefer explicit close() via try-with-resources
}

Common follow-ups: How does Cleaner avoid the object-resurrection problem that made finalize() unsafe?;Why is try-with-resources considered fundamentally superior to any GC-triggered cleanup mechanism for resource management?

// Conceptual illustration of what a write barrier intercepts (not actual user-visible code)
// When application code executes: blackObject.field = whiteObject;
// The JVM's inserted write barrier detects this specific black-to-white reference creation
// and takes corrective action (e.g., marking whiteObject grey) to prevent it from being
// incorrectly missed and collected as garbage despite now being reachable

Common follow-ups: What's the performance overhead cost of write barriers, and how do different collectors balance this against pause time reduction?;How does this concurrent marking challenge relate to why STW (stop-the-world) pauses are still sometimes necessary even in a 'concurrent' collector?

# Fixed heap size -- avoids resize pauses, but reserves the full 4GB from startup
java -Xms4g -Xmx4g -jar app.jar

# Dynamic heap size -- starts small, can grow up to 4GB as needed, but resize operations cause brief pauses
java -Xms512m -Xmx4g -jar app.jar

Common follow-ups: How do you determine an appropriate heap size for a given container's memory limit, accounting for non-heap JVM memory overhead?;What's the interaction between container memory limits and the JVM's default heap sizing behavior if -Xmx isn't explicitly set?

public double distance(double x1, double y1, double x2, double y2) {
    // If Point never escapes this method, the JIT's escape analysis can eliminate
    // the heap allocation entirely via scalar replacement, treating x/y as plain local variables
    Point p1 = new Point(x1, y1);
    Point p2 = new Point(x2, y2);
    return p1.distanceTo(p2);
}
// Despite 'new Point(...)' appearing in the source, the JIT may never actually heap-allocate it at runtime

Common follow-ups: What specific coding patterns tend to defeat escape analysis (like storing an object in a field, or passing it to a non-inlined method)?;How would you verify whether escape analysis is actually being applied for a specific hot method in your application?

# Ensure a heap dump is captured automatically the moment OOM occurs
java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/dumps/ -jar app.jar

# After a production OOM crash, open the resulting .hprof file in Eclipse MAT
# and run the automated "Leak Suspects Report" as the first triage step

Common follow-ups: What's the operational cost/consideration of enabling automatic heap dumps in production (dump file size, disk space)?;How would you configure alerting to notify the team immediately when a heap dump is triggered, rather than discovering the crash later?