Java · Advanced interview

The heap holds all objects and is shared across threads and GC-managed, split into young and old generations. Each thread has its own stack of frames for method calls and local variables/primitives. The Metaspace (native memory, post-Java 8) holds class metadata. There's also the program counter per thread and native method stacks. Most tuning and leaks concern the heap.

Class loaders load classes lazily on first use, following the parent-delegation model: a loader asks its parent before loading itself, so core classes come from the bootstrap loader and can't be overridden. The process is load → link (verify, prepare, resolve) → initialize (run static initializers). Custom class loaders enable plugins, hot reloading, and isolation (e.g. in app servers), but delegation prevents tampering with core classes.

The JVM starts by interpreting bytecode, and the Just-In-Time compiler compiles hot methods to native code at runtime, applying optimizations (inlining, escape analysis, loop optimizations) based on actual execution profiles. Tiered compilation balances fast startup with peak performance. This is why Java 'warms up' — performance improves after the JIT optimizes hot paths, and why micro-benchmarks must account for warmup.

The heap is split into a young generation (where new objects are allocated and most die quickly) and an old generation. Minor GCs collect the young gen cheaply, promoting survivors to old; major/full GCs collect the old gen less often but more expensively. This generational hypothesis — most objects die young — makes collection efficient. Modern collectors like G1 and ZGC add region-based, mostly-concurrent collection for low pause times.

Strong references (normal) keep objects alive. Soft references are cleared only under memory pressure — good for caches. Weak references are cleared at the next GC once no strong refs remain — used by WeakHashMap for canonicalizing maps/metadata. Phantom references are for cleanup actions after collection. They let you build memory-sensitive structures that cooperate with GC instead of leaking.

The JMM defines when one thread's writes become visible to another. The happens-before relation orders actions so that if A happens-before B, A's effects are visible to B. It's established by synchronization: unlocking a monitor happens-before locking it, a volatile write happens-before subsequent reads, thread start/join, and final-field publication. Without these, the compiler/CPU may reorder or cache, so reasoning about correctness means establishing happens-before edges.

Instead of locking the whole map like Hashtable, ConcurrentHashMap allows concurrent reads with no locking and locks only individual bins/nodes (via CAS and synchronized on bin heads) for writes, so multiple threads update different buckets in parallel. This gives high concurrency. Its iterators are weakly consistent (no ConcurrentModificationException), and operations like computeIfAbsent are atomic per key.

A Future only lets you block for a result; CompletableFuture lets you compose asynchronous pipelines — chaining with thenApply/thenCompose, combining with thenCombine/allOf, and handling errors with exceptionally/handle — without blocking. You can run stages on specific executors and build non-blocking, callback-style flows. It's Java's tool for composable async, akin to promises.

synchronized is simple and sufficient for most mutual exclusion. ReentrantLock and ReadWriteLock add capabilities: tryLock with timeout, interruptible locking, fairness policies, multiple condition variables, and a read-write split so many readers proceed concurrently while writers are exclusive. You reach for them when you need those features or finer control; otherwise synchronized is cleaner and now performs comparably.

Profile with tools like async-profiler, JFR (Java Flight Recorder), or VisualVM to find CPU hotspots, allocation pressure, lock contention, and GC behaviour before changing anything. Tune by choosing/sizing the right collector (G1/ZGC), setting heap sizes, and reducing allocations; analyze GC logs for pause times and frequency. The discipline is measure → change one thing → re-measure, not speculative flag-twiddling.

Strings are immutable, so concatenation in a loop creates many temporary objects — use StringBuilder for building strings incrementally. The String pool interns string literals so identical literals share one instance (another reason == is unreliable for content). Be mindful that substring and heavy string work allocate; for hot paths consider char arrays or avoiding unnecessary conversions between String and byte[].

Autoboxing in hot loops creating garbage, excessive object allocation pressuring GC, unbounded caches or listener lists leaking memory, using the wrong collection (LinkedList where ArrayList fits, or not sizing collections), over-synchronization causing contention, and N+1 patterns in data access. Many show up as GC pressure or lock contention in a profile — the fix is reducing allocations, right-sizing data structures, and narrowing critical sections.