Advanced Interview Questions

.java ──javac──▶ .class (bytecode)
                        │
                ┌───────▼────────┐
                │ Class Loader   │  load → link (verify, prepare, resolve) → initialize
                └───────┬────────┘
   ┌────────────────────▼──────────────────────┐
   │ Runtime data areas                         │
   │  Heap | Metaspace | Stacks | PC | Native   │
   └────────────────────┬──────────────────────┘
                ┌───────▼────────┐
                │ Execution      │  interpreter + JIT compiler + garbage collector
                └────────────────┘

Up to Java 7, class metadata lived in PermGen, a fixed-size part of the heap, which often caused OutOfMemoryError: PermGen space. Java 8 replaced it with Metaspace in native memory, which grows automatically (cap it with -XX:MaxMetaspaceSize). The String pool moved to the regular heap in Java 7.

• GC frees objects that are no longer reachable from GC roots (stack locals, static fields, active threads, JNI refs).
• The heap is generational: new objects go to the Young generation (Eden + two Survivor spaces). Most die young and are cleaned by fast minor GCs.
• Objects that survive several cycles are promoted to the Old generation, which is collected less often (major/full GC).
• Basic phases: mark live objects, sweep dead ones, compact to avoid fragmentation.

Yes: GC only removes unreachable objects, so anything still referenced stays forever. Common causes:

• Static collections (caches) that only grow.
• Listeners/callbacks registered but never removed.
• ThreadLocal values not removed in thread pools.
• Unclosed resources (streams, connections).
• Keys with mutable fields or missing hashCode() in a HashMap.

Diagnose with a heap dump (-XX:+HeapDumpOnOutOfMemoryError, jmap) and analyse in Eclipse MAT or VisualVM.

Class loaders form a hierarchy: Bootstrap (core java.*) → Platform (other JDK modules) → Application (your classpath). With parent delegation, a loader first asks its parent; only if the parent cannot find the class does it load it itself. This prevents your code from replacing core classes like java.lang.String and avoids loading a class twice.

The JVM starts by interpreting bytecode. It profiles which methods and loops are "hot" and the Just-In-Time compiler (C1 quickly, then C2 with heavy optimisation) compiles them to native code. Optimisations include inlining, escape analysis (allocating objects on the stack), loop unrolling and dead-code removal. This is why Java apps get faster after a warm-up period.

1. Declare the class final (no subclass can add mutability).
2. Make all fields private final.
3. No setters.
4. Defensively copy mutable inputs in the constructor and mutable outputs in getters (e.g. List.copyOf).

// 1. Bill Pugh holder (lazy, thread-safe, no locking cost)
public class Config {
    private Config() {}
    private static class Holder { static final Config INSTANCE = new Config(); }
    public static Config getInstance() { return Holder.INSTANCE; }
}

// 2. Double-checked locking (field MUST be volatile)
public class Db {
    private static volatile Db instance;
    private Db() {}
    public static Db getInstance() {
        if (instance == null) {
            synchronized (Db.class) {
                if (instance == null) instance = new Db();
            }
        }
        return instance;
    }
}

// 3. Enum singleton: also safe against reflection and serialization
public enum Registry { INSTANCE; }