Java Interview Questions for 5 Years Experience

Why interviewers ask JVM and judgment questions at 5 years

A 5-year hire is the person others escalate to, so the interview simulates escalations: a latency spike at 2 a.m., an OutOfMemoryError that only appears on Fridays, a junior's PR that "works" but will not survive load. The questions test whether you can reason from symptom to cause using the JVM's actual mechanics.

The second axis is judgment. Several answers here have no single correct choice — G1 or ZGC, library or in-house. Interviewers want to watch you weigh trade-offs, commit to a position, and name the conditions that would reverse it.

Expect four clusters: garbage collection and memory, concurrency internals, modern platform changes (virtual threads, JIT), and engineering leadership — reviews, standards, technical debt.

How to answer in an interview

Anchor every answer in a production incident or decision, using the template symptom → diagnosis → mechanism → decision → result: "p99 spiked every 40 seconds; GC logs showed full GCs; the cause was humongous allocations in G1; we batched the report generation and raised the region size; spikes disappeared."

Quantify where you honestly can (heap sizes, pause targets, thread counts), and admit uncertainty crisply — "I'd confirm with a heap dump first" is a senior sentence. When asked about leadership, describe systems you built (review checklists, CI gates), not personalities.

Q1. How do you choose and tune a garbage collector for a service?

Start from the requirement: G1 (the default) balances throughput and pause times for most heaps; ZGC for sub-millisecond pauses on large heaps; Parallel GC when raw batch throughput beats pause concerns. Tune by setting a pause goal and heap bounds first — other flags follow from GC log evidence, not folklore.

The workflow: enable GC logging, run realistic load, and read pause distribution, allocation rate and old-gen growth. Set -Xms equal to -Xmx in containers to avoid resize stalls, give G1 a pause target, and only then consider deeper flags.

-Xms4g -Xmx4g -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -Xlog:gc*:file=gc.log

One G1-specific behavior shows depth: objects larger than half a region become "humongous" allocations — a classic cause of mysterious full GCs.

Interview note: Trap: "would you just increase the heap to fix long pauses?" Often the opposite — a bigger heap can mean longer collections. Pause time correlates with live-set size and GC choice, not free memory.

Q2. Walk me through diagnosing a memory leak in production.

Confirm the pattern first: old-gen usage climbing across full GCs means a true leak, not just a big working set. Then capture a heap dump (jcmd <pid> GC.heap_dump), open it in Eclipse MAT, and follow the dominator tree and "path to GC roots" from the biggest retained objects to the reference that should not exist.

The usual suspects, in the order I check them: unbounded caches and static Maps, listeners never deregistered, ThreadLocals in pooled threads, and ClassLoader leaks after redeploys. Two dumps beat one: diff the retained sizes between an early dump and a post-growth dump — the leaking type is the one that grew. In containers, also set -XX:+HeapDumpOnOutOfMemoryError so a crash leaves evidence behind.

Interview note: Follow-up: "heap keeps growing but no OutOfMemoryError — leak?" Not necessarily. The JVM may simply not need to collect yet. Only growth that survives repeated full GCs is a leak.

Q3. What is the Java Memory Model's happens-before relationship, and why should a senior care?

Happens-before is the JMM's guarantee that if action A happens-before action B, then B sees all of A's writes. Without an edge — synchronization, volatile, thread start/join, final-field freeze — the JVM and CPU are free to reorder and cache, and a thread may legally see stale or half-constructed state.

This is the theory underneath every "it only fails on the loadtest box" bug. The edges to know cold: unlock happens-before subsequent lock of the same monitor; a volatile write happens-before subsequent volatile reads; Thread.start() happens-before everything in the started thread; everything in a thread happens-before join() returning.

The senior connection is safe publication: double-checked locking is broken without volatile precisely because, absent the edge, another thread can observe the reference before the constructor's writes. Data races are not "unlikely timing issues" — they are programs with undefined reads.

Interview note: Trap: "if I only read from multiple threads after writing once, am I safe?" Only if publication itself crossed a happens-before edge — e.g., final fields, a volatile reference, or handing the object to the thread before start().

Q4. Explain CAS, atomic classes, and the ABA problem.

Compare-and-swap is a hardware instruction: atomically set a value only if it still equals the expected value, else fail and retry. AtomicInteger, AtomicReference and friends build lock-free updates on it — no blocking, no context switch, but a retry loop under contention.

public long nextId() {
    long current, next;
    do {
        current = counter.get();
        next = current + step;
    } while (!counter.compareAndSet(current, next));  // retry on interference
    return next;
}

ABA: a CAS succeeds because the value is back to A after changing A→B→A — the value matches but its history invalidates your assumption (classic in lock-free stacks reusing nodes). AtomicStampedReference adds a version stamp to detect it. For hot counters, mention LongAdder: it shards the value across cells to reduce CAS contention.

Interview note: Follow-up: "is lock-free always faster?" No — under heavy contention CAS retry storms can burn more CPU than a queue-managed lock. Measure, don't assume.

Q5. What are the pitfalls of ThreadLocal in thread pools?

Pooled threads never die, so a ThreadLocal you don't remove() outlives the request — leaking memory and, worse, leaking one user's context (tenant, auth, locale) into another user's request when the thread is reused.

The memory mechanics: values live in each thread's ThreadLocalMap, keyed weakly by the ThreadLocal object but holding the value strongly. In an application server, that chain can also pin the webapp's ClassLoader across redeploys — the classic "metaspace grows every deploy" leak.

The discipline: set and remove in a try/finally at the entry point (a filter or interceptor), never deep in business code. Flag the modern angle too: ThreadLocal scales poorly to millions of virtual threads, which is why Scoped Values were introduced as the structured replacement.

Interview note: Trap: "ThreadLocal uses weak references, so it can't leak, right?" Wrong — only the key is weak. The value stays strongly referenced until the thread ends or you call remove().

Q6. Virtual threads vs platform threads — when do they actually help?

A virtual thread is a JVM-managed thread that unmounts from its carrier OS thread whenever it blocks, so millions can run on a handful of carriers. They transform blocking-I/O-heavy workloads; they do nothing for CPU-bound work, where core count is still the limit.

The operational win is programming-model simplicity: plain blocking code scales like async code, without CompletableFuture chains. The caveats: blocking inside synchronized could pin the carrier thread (largely fixed in JDK 24 — check your target version), native calls still pin, and virtual threads are created per task, never pooled.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    List<Future<Quote>> quotes = vendors.stream()
        .map(v -> executor.submit(() -> v.fetchQuote(item)))  // blocking is fine
        .toList();
}

Each blocking call parks the virtual thread, not the OS thread — 10,000 concurrent fetches no longer need 10,000 OS threads.

Interview note: Follow-up: "so we can delete our thread pools?" Pools remain for limiting concurrency to a scarce resource (DB connections). With virtual threads you limit with a Semaphore, not by pooling threads.

Q7. How does JIT compilation affect performance, and what is escape analysis?

The JVM interprets bytecode first, profiles it, then compiles hot methods to optimized native code (tiered: C1 then C2). Because optimization is profile-driven, steady-state speed differs from warm-up speed — microbenchmarks that ignore warm-up measure nothing. Escape analysis proves an object never escapes a method and avoids heap-allocating it via scalar replacement.

Practical consequences a senior should own: performance tests need warm-up iterations (use JMH); a method can get faster minutes after deployment; and deoptimization causes post-deploy latency blips when speculative assumptions break. Escape analysis is why "allocation is expensive, reuse objects" is outdated folklore for short-lived locals — the JIT often eliminates them entirely.

Interview note: Trap: "why is the first request after deploy slow?" Interpretation plus JIT warm-up plus class loading — not necessarily GC. Candidates who blame GC by reflex reveal they never profiled startup.

Q8. Design a thread-safe in-memory cache. What are the decision points?

Start with ConcurrentHashMap plus computeIfAbsent for atomic per-key loading, then make the real decisions: bounding, eviction policy, expiry, and stampede protection. Say the senior sentence early: in production I would use Caffeine rather than hand-roll — and here is what it does that my version won't.

private final ConcurrentHashMap<String, CompletableFuture<Price>> cache =
    new ConcurrentHashMap<>();

public CompletableFuture<Price> price(String sku) {
    return cache.computeIfAbsent(sku,
        k -> CompletableFuture.supplyAsync(() -> loader.load(k), pool)
                 .whenComplete((v, ex) -> { if (ex != null) cache.remove(k); }));
}

Caching the future rather than the value gives stampede protection — concurrent requesters for a key share one in-flight load — and the whenComplete removal prevents negative caching of failures. An unbounded map is a Q2-style leak, so bound it; precise LRU needs a global lock, the contention-vs-precision trade-off libraries solve with approximate policies.

Interview note: Follow-up: "why not synchronized on the whole get-or-load method?" It serializes all keys behind one lock and holds it during the load — one slow key blocks the entire cache.

Q9. What causes ClassLoader and metaspace leaks?

Metaspace holds class metadata and is reclaimed only when the defining ClassLoader is collected. Anything referencing a "disposable" ClassLoader from a long-lived scope — a shutdown hook, a static in a shared library, an un-removed ThreadLocal, an unstopped thread — pins every class it loaded, and metaspace grows until OutOfMemoryError.

The two production scenarios: application servers redeploying webapps (each redeploy leaks a full copy of the app's classes), and frameworks generating classes faster than their loaders can be collected. Diagnosis mirrors Q2: find the leaked ClassLoader in the heap dump and trace path-to-GC-roots to see who pins it. Prevention: unregister shutdown hooks, stop executors on undeploy, and load drivers via the container's loader.

Interview note: Trap: "does setting -XX:MaxMetaspaceSize fix it?" It converts slow growth into a faster crash. The cap is a safety valve; the fix is releasing the loader.

Q10. How do you evolve a shared API or library without breaking consumers?

Treat compatibility as three separate contracts — source, binary, and behavioral — and version accordingly. Add, don't change: new overloads and default methods extend safely; changing signatures, narrowing return types, or altering semantics under the same signature breaks consumers who will not recompile on your schedule.

Binary compatibility is the one that surprises teams: changing a method's return type breaks callers at link time even if the source "still compiles". Default methods exist for interface evolution — but a default inherited with wrong semantics is a behavioral break, the hardest kind to detect.

Tools worth naming: @Deprecated(forRemoval = true) with a documented removal horizon, sealed interfaces to keep the implementation set closed, and japicmp or Revapi in CI to fail builds on accidental breaks. Semantic versioning is the communication layer on top.

Interview note: Follow-up: "a teammate wants to rename a public method for clarity — approve?" Not directly: add the new name, delegate the old one to it, deprecate with a removal version, and communicate. Clarity is not worth a silent break.

Q11. How do you enforce code quality across a team without becoming a bottleneck?

Automate the objective, review the subjective. Formatting, static analysis (Error Prone, SonarQube, SpotBugs), dependency and coverage gates run in CI where they are non-negotiable and nobody argues with a robot. Human review time then goes to what machines can't judge: design, naming, concurrency reasoning, and test quality.

The mechanics that scale: a written review checklist (thread-safety of shared state, resource cleanup, error paths, API shape), small-PR norms, and review SLAs so quality doesn't tax velocity. Mentoring happens in reviews — a comment should teach the rule, not just fix the instance. The trade-off to acknowledge: gates calibrated too aggressively teach people to game metrics. Measure outcomes — escaped defects, incident recurrence — not vanity numbers.

Interview note: Follow-up: "a strong developer keeps bypassing the process — what do you do?" Wrong answer: escalate immediately. Expected answer: understand which friction they're avoiding, fix the process if it's genuinely slow, and hold the line on the parts that protect production.

Q12. Build vs buy: when do you write it in-house instead of using a library?

Default to the library for solved problems — caching, resilience, JSON — because you inherit years of edge-case fixes and security patches. Build in-house only when the problem is core to your differentiation, the library's abstraction fights your requirements, or the dependency's risk profile is worse than owning the code.

The evaluation checklist worth reciting: maintenance activity and bus factor, license compatibility, transitive dependency weight, security track record, and how hard it is to exit — a library used behind your own interface can be replaced; one woven through every class cannot. Give the honest failure mode from both sides: in-house frameworks that become "legacy nobody dares touch", and abandoned dependencies that block a JDK upgrade. A senior has usually lived through one of each — tell that story.

Interview note: Trap: "we could write that in a weekend." The weekend buys the happy path. Retries, edge cases, observability and upgrades are the other 90% — that is the argument interviewers want you to make.

Q13. How do you approach a sudden latency spike in a Java service?

Triage in order of cheapness: recent deploys and traffic shape, then JVM signals — GC logs for pause correlation, thread dumps for lock convoys or pool exhaustion — then downstream dependencies. Take three thread dumps 5–10 seconds apart; a thread stuck at the same frame across dumps is your smoking gun.

The discipline is correlating, not guessing: p99 spikes aligned with full GCs mean memory pressure (Q1/Q2); threads piled up WAITING on a connection pool mean the database or pool sizing; pegged CPU with deep RUNNABLE stacks means profile with async-profiler. Lock contention shows as many threads BLOCKED on one monitor — the deadlock and contention patterns are readable straight from the dump. Close with prevention: the real fix is the dashboard and alert that would have caught it earlier, not "restart it".

Interview note: Follow-up: "the spike vanished before you got a dump — now what?" Continuous profiling or flight recorder (JFR) running always-on with low overhead. Seniors design for the next incident, not just the current one.

How to prepare

Rebuild your incident portfolio first: three production stories — one memory/GC, one concurrency, one process/leadership — each told in the symptom → diagnosis → mechanism → decision → result shape. These stories are the answers to half the questions above.

Refresh hands-on: capture a heap dump from a deliberately leaky toy app and walk MAT's dominator tree; take thread dumps of a contended lock; run a JMH benchmark and watch warm-up move the numbers. The JVM memory management and JVM architecture guides cover the underlying mechanics.

Finally, calibrate one level down: interviewers often open with 3-year-level questions, and stumbling there costs more than acing the JVM round gains. A timed mock interview with a reviewer who pushes follow-ups is the highest-return hour you can spend.