Java JVM Garbage Collection Interview Questions

This is false. Only instance fields and static fields receive default values, assigned by the JVM during object or class initialization. Local variables live in the method's stack frame and are not initialized. The compiler enforces definite assignment, so reading a local variable before it has been assigned is a compile-time error rather than a silent zero or false.

The JVM heap is the runtime data area from which memory for all class instances and arrays is allocated. The JVM stack stores frames holding local variables and partial results, the method area stores class metadata, and the native method stack serves native (JNI) calls. The heap is shared among all threads and is the target of garbage collection, which is why it is the correct answer.

The Java compiler (javac) translates .java source files into platform-neutral bytecode stored in .class files. The JVM — which IS platform-specific — loads and executes that bytecode, so the same compiled artifact runs unchanged on Windows, Linux, macOS, or any other OS with a JVM. This is the core of Java's 'write once, run anywhere' model. The statement is true.

The JVM Heap is a single shared memory area where all object instances and arrays are allocated. Every thread in the application accesses the same heap, which is why heap objects can be passed between threads and why thread-safety mechanisms (synchronization, volatile, etc.) are needed. By contrast, the JVM Stack, the Program Counter Register, and the Native Method Stack are all created on a per-thread basis — each thread has its own private set of these areas. Therefore the Heap is the correct answer.

The javac compiler translates .java source files into .class files containing JVM bytecode. This bytecode is platform-independent; it is the JVM's job to load, verify, and execute (interpret or JIT-compile) it on the host machine.

The javac compiler does not produce machine code directly; it emits JVM bytecode (stored in .class files). The JVM's class loader and bytecode verifier process this bytecode, and the execution engine either interprets it or the JIT compiler compiles hot paths to native instructions.

The Garbage Collector periodically identifies objects that are no longer reachable from any live reference and reclaims the heap memory they occupied. The Class Loader only loads class files, the JIT Compiler optimizes bytecode into native code, and the Execution Engine interprets bytecode; none of these manage reclamation of unused objects.

This is true. The JVM's garbage collector traces object reachability from GC roots and reclaims heap memory held by objects that cannot be reached. The programmer does not call a deallocation function for each object, unlike C's free() or C++'s delete. The timing of collection is up to the JVM, but the reclamation of unreachable objects is automatic.

The JVM garbage collector finds objects that cannot be reached from any live reference (such as local variables, static fields, or active threads) and reclaims the heap memory they occupy. This frees the programmer from explicit deallocation and helps prevent leaks of forgotten objects. It does not collect objects that are still reachable, so a leak can still occur if references are kept unintentionally.

The statement is false. Java provides automatic garbage collection: the JVM's garbage collector traces object reachability and reclaims heap memory from objects that are no longer reachable. The programmer does not explicitly free individual objects, and there is no Java equivalent of calling free() or delete. Manual deallocation is the C/C++ model that Java replaces.

The heap is the runtime data area shared by all threads, where class instances and arrays are allocated. Each thread gets its own Java Virtual Machine stack, its own program counter register, and its own native method stack, which are created with the thread and destroyed when it terminates. Since only the heap is shared among the offered areas, it is the single correct answer.

Autoboxing an int uses Integer.valueOf, which returns cached objects for values from -128 to 127 by default. Both 127 values therefore refer to the same cached Integer object, so the reference comparison a == b is true. The value 128 is outside the default cache range, so each autoboxing call creates a new Integer object; c == d compares two distinct references and is false. The program prints true on the first line and false on the second.

The Java garbage collector traces from a set of GC roots (active thread stacks, static fields, local variables, etc.) and marks every object transitively reachable from those roots. Any object not found during this tracing phase is considered unreachable and is eligible for collection. Because the sentence reads 'the object is no longer ___ from any live thread or GC root', the standard term that fills the blank is 'reachable', giving 'the object is no longer reachable'.

After b = null, object Y is still strongly reachable through a.next, and X is still reachable through the local variable a. After a = null, no local variable or other GC root references X, so X is unreachable. Y's only strong reference came from X's next field, and since X is itself unreachable, nothing live reaches Y either. An object is eligible for collection when no chain of strong references from a GC root leads to it, so both X and Y are eligible. The option claiming X and Y keep each other alive is wrong because the references only run one way, from X to Y, and no reference points back from Y to X.

System.gc() is specified in the Javadoc as a hint that the programmer would like garbage collection to run. The JVM is not required to honour it: it may skip the collection, or run a partial collection that leaves some unreachable objects in place. Nothing guarantees that a particular object is reclaimed or that the call blocks until collection finishes. Some JVMs can also disable explicit GC calls with a flag such as -XX:+DisableExplicitGC. The statement is therefore false.

Because a and b are final String variables initialized with literals, a + b is a compile-time constant expression, so the compiler folds it to the literal "ab", which is interned in the string pool; s == t is therefore true. The new String("ab") call allocates a new heap object distinct from the pooled literal, so s == u is false. new String(a) + new String(b) is a runtime concatenation that produces another new heap object, so s == v is false. Finally, s.equals(v) compares character content, which is ab in both, so it prints true. The four lines therefore read true, false, false, true.

Line 2 declares instance without volatile. Under the Java Memory Model (JLS §17.4), a plain write to instance on line 9 may become visible to other threads before the writes to value performed in the constructor on line 4, because the JIT and CPU may reorder these stores. A second thread can then pass the unsynchronized null-check on line 6, skip the lock, and return an object whose value is still 0. The fix is to declare the field volatile on line 2: a volatile write happens-before any subsequent volatile read of the same field, so the constructor's writes are visible before the reference is published. The lock on line 7 alone does not fix this, because the outer null-check on line 6 reads instance without holding the lock.

G1 partitions the heap into fixed-size regions and chooses the collection set by garbage density, evacuating live objects from the regions with the most garbage first; this is the origin of the name 'Garbage-First' and is what bounds pause times. The statement about full-heap compaction on every young pause is wrong because young pauses only evacuate young regions. The claim that G1 has no remembered sets is wrong because G1 keeps a remembered set per region to track cross-region references. The claim that mixed collections evacuate the whole old generation is wrong because they evacuate only selected old regions.

The JVM's garbage collectors trace reachability starting from GC roots such as local variables on the stack, static fields, and JNI references. After both local variables a and b are set to null, no root holds a reference to object A or object B, so neither is reachable. The reference cycle between them is only a path between two unreachable objects and cannot make either one reachable from a root. Because the JVM does not use reference counting, the cycle is irrelevant, and both objects are eligible for collection, giving an answer of 2.

A safepoint is a point where the JVM can assume every application thread is in a known, stable state, so it can safely inspect or change the heap. The garbage collector and other VM operations need this consistent snapshot to traverse live objects, enumerate roots, and relocate or free memory. In JIT-compiled code, safepoint polls are placed only at specific spots such as method returns and loop back-edges, so a thread in compiled code stops only at those polls rather than at any instruction. Stop-the-world collections require all threads to reach a safepoint, and even ZGC needs brief safepoint pauses for its mark start and relocate start phases despite doing most work concurrently.

PermGen lived in a fixed-size region inside the Java heap, so the number of classes an application could hold was capped by a size set at startup. Metaspace stores class metadata in native memory outside the Java heap, obtained from the operating system, and grows on demand up to -XX:MaxMetaspaceSize, which is unlimited by default. The change therefore mainly targets the OutOfMemoryError: PermGen space failures seen when frameworks generated many classes at runtime.

G1 maintains a Remembered Set (RSet) per region that records which other regions contain references into that region. The write barrier and card tables track reference writes, and the RSets are refined concurrently and during pauses. When G1 evacuates a collection set, it scans only the RSets of those regions plus external roots, never the whole heap. A global mark bitmap tracks liveness, not inter-region references, and a reference queue is for java.lang.ref processing. A flat card table without per-region tracking would not let G1 avoid scanning all dirty cards across the entire heap, which is why per-region RSets are the key mechanism.

Colored pointers reserve high-order bits of each 64-bit reference to encode GC state (Marked0, Marked1, Remapped, Finalizable), which lets the collector track object state without separate side tables on the object header. The load barrier runs on reference loads and checks these bits; when it finds a pointer to an object that has been relocated, it remaps the pointer to the new address (self-healing). Since fixing stale references happens on access rather than in a stop-the-world phase, relocation can proceed concurrently with application threads, keeping pauses very short.

C2 compiled the call site with a monomorphic receiver guard and a direct call, and it recorded a dependency that ConcreteA is the only concrete implementor of compute(). Loading ConcreteB violates that dependency, so the JVM marks the dependent nmethod as not entrant and deoptimizes it, converting active frames back to interpreter frames. Execution continues in the interpreter, which re-profiles the site, and the method may later be recompiled with both receiver types observed. Loading a second legal implementor does not throw an IncompatibleClassChangeError, and the JVM does not rewrite the inline cache of compiled code. The option claiming the existing guard keeps the code valid is wrong because the guard is not the mechanism that protects the dependency: a ConcreteB receiver would fail the guard and hit an uncommon trap, and the dependency check is what forces invalidation.

The correct answer is that the SATB barrier guarantees any object reachable at the start of marking will be found by the end of the cycle even if its last incoming reference is overwritten during marking, at the cost of floating garbage (objects that become unreachable mid-cycle but survive until the next cycle). The barrier logs the previous value of every overwritten reference field, creating a logical snapshot of the live object graph at mark start. Without this, a mutator could overwrite the only reference to an object before the concurrent marker reached it, causing that object to be wrongly classified as unreachable and potentially reclaimed while still in use. The trade-off is that an object which becomes unreachable after its old reference was logged will still be marked live — the snapshot may contain references to objects already dead — so it survives this cycle as floating garbage and can only be reclaimed in a subsequent cycle. The mechanism does not eliminate all dead objects in a single pass; it explicitly tolerates some floating garbage to avoid stalling mutators for a full stop-the-world mark. Remembered-set (RSet) maintenance uses an entirely separate write barrier (dirty-card queues refined by concurrent refinement threads), not SATB buffers.