JVM Interview Questions: Memory, Garbage Collection and Real Incidents

The opening questions look like recall. Heap versus stack, generations, what a collector does. Everybody has read this, so answering it correctly buys you nothing and answering it wrongly ends the round early.

The round is decided after that, when the interviewer asks what you would do about a service that has started pausing for two seconds every few minutes. That question has no memorised answer. It tests whether the concepts are a diagnostic tool for you or a vocabulary.

Be able to explain where objects live, what the generational hypothesis assumes, and why that assumption usually holds. State the assumption explicitly — most candidates describe the mechanism and never say why it was designed that way.

Know what actually leaves the heap and what does not. Metaspace, direct buffers, thread stacks, and the native memory a container counts but the heap does not. Interviewers like this area because it separates people who have debugged a container being killed from people who have only read about the heap.

Know what a reference type changes in practice. Weak and soft references have real uses in caching and real failure modes, and being able to name both is more convincing than defining them.

You do not need every collector. You need to explain the trade-off each one makes: throughput against pause time, and what the collector does concurrently versus what still needs the world stopped.

For a modern low-pause collector, be able to say what work moved off the pause and what that costs elsewhere, usually CPU and allocation rate headroom. That framing survives follow-ups better than any list of flags.

If you have tuned a collector in production, lead with the symptom that made you touch it. Nobody changes collector settings for fun, and the symptom is the interesting part.

Prepare one real JVM incident properly: what users saw, what you looked at first, what you ruled out, what the cause turned out to be, and what stopped it recurring.

Name the tools and what each one told you. A heap dump that showed one collection holding most of the heap. GC logs that showed the old generation growing between cycles. A flame graph that put the time somewhere nobody expected.

Include what you got wrong on the way. The engineer who says they first blamed the database and were wrong reads as someone who has genuinely debugged something, which is exactly the signal being looked for.