Java JVM Interview Questions — Practice Real Interview Problems

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 JVM zeroes out all instance fields during object construction. For the primitive type int, that zero value is the integer literal 0. null is the default for object references, 0.0 is the default for double/float, and no Java primitive type defaults to a negative value.

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 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.

Java's Integer autoboxing uses a built-in cache for values in the range [-128, 127] (JLS §5.1.7). When you assign 100 to both a and b, each gets the same cached Integer object, so a == b compares identical references and prints true. The value 200 falls outside the cache range, so c and d are each backed by separate newly-constructed Integer objects; reference comparison via == therefore yields false. Note that .equals() would return true in both cases because Integer.equals compares the underlying int value, not object identity.

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.

Java is always pass-by-value, with no exceptions. For object types, the value that is copied is the reference itself, not the object — so the parameter and the caller's variable initially point at the same object. Mutating that shared object's state (e.g. list.add(x) or obj.setName(...)) is visible to the caller, which is why people mistakenly call it 'pass-by-reference'. But reassigning the parameter (obj = new Thing()) only rebinds the local copy of the reference; the caller's variable still points at the original object. The tell that it is pass-by-value: a method cannot swap two of the caller's variables or make the caller's variable point somewhere new.

Class loading follows a fixed sequence: Loading reads the bytecode and produces the Class object; Linking then runs as Verification (bytecode safety checks), Preparation (static fields get memory and default zero values, NOT their declared values yet), and Resolution (constant-pool symbolic references become direct references); finally Initialization runs static initializer blocks and assigns static fields their actual values. The key distinction interviewers probe is Preparation vs Initialization — a static int x = 5 is set to 0 in Preparation and only becomes 5 in Initialization, which is why static state is observable as its zero value during early bootstrapping. Initialization is lazy: it happens on first active use (instantiation, a static access, etc.), not at JVM startup.

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.

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.

When Main.main is invoked, Main is loaded and initialized first (it has no static block), so System.out.println(7) runs first. Then new Child() triggers initialization of Child. Per JLS 12.4.1, a class's superclass is initialized before the class itself, so Parent's static block runs first (1), then Child's static block (4). For instance creation (JLS 12.5), the Child constructor implicitly calls super() before its body, which runs Parent's instance initializer (2) and then the Parent constructor body (3). Control returns to Child, whose instance initializer runs (5), followed by the Child constructor body (6). Finally, main prints 8. The output is therefore 7, 1, 4, 2, 3, 5, 6, 8, one per line.

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.

Escape analysis is performed by the HotSpot JIT compiler (the C2 compiler). It tracks whether a reference to a newly allocated object can leave the allocating method or be seen by another thread. If the object is classified as 'no escape' (or 'scalar replaceable'), the JIT can avoid heap allocation via scalar replacement and can also elide synchronization (lock elision) since no other thread can ever observe the object. These two optimizations, scalar replacement and lock elision, are the primary concrete benefits the HotSpot JVM derives from escape analysis.

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.