Java Runtime Memory Areas, Object Creation, and Common Interview Questions

Java developers rely on the JVM's automatic memory management, but understanding how the virtual machine uses memory is crucial for diagnosing leaks and out‑of‑memory errors, especially during technical interviews.

The JVM divides memory into several runtime data areas. Before JDK 1.8 the layout differs from later versions; the article shows diagrams for both and separates thread‑private regions (program counter, JVM stack, native method stack) from thread‑shared regions (heap, method area, direct memory).

Program Counter : a small per‑thread memory slot that records the current bytecode line, enabling the interpreter to select the next instruction and allowing thread‑specific execution state.

JVM Stack : also thread‑private, it stores stack frames for each method call, including the local variable table, operand stack, dynamic linking, and method exit information. It can throw StackOverflowError or OutOfMemoryError depending on whether the stack size is fixed or expandable.

Native Method Stack : serves native (JNI) methods; in HotSpot it is merged with the JVM stack.

Heap : the largest shared memory area where all object instances and arrays reside. It is managed by the garbage collector and divided into the young generation (Eden, Survivor spaces) and the old generation. Objects are promoted based on age, which can be tuned with -XX:MaxTenuringThreshold .

Method Area / Metaspace : stores class metadata, constants, static variables, and JIT‑compiled code. In JDK 1.8 the traditional “PermGen” was removed and replaced by Metaspace, which uses native memory and can be sized with -XX:MetaspaceSize .

Runtime Constant Pool : a part of the method area (or Metaspace) that holds literals and symbolic references. When it cannot allocate more memory, an OutOfMemoryError is thrown.

Direct Memory : memory outside the JVM heap, allocated via NIO's ByteBuffer . It improves performance by avoiding heap‑to‑native copies but is limited by the host's physical memory.

HotSpot Object Creation Process (five steps): Class loading check – verify and load the class if necessary. Memory allocation – reserve space in the heap using either pointer‑bumping or free‑list strategies, chosen based on heap regularity. Zero‑value initialization – clear the allocated memory to zero. Object header setup – store class pointer, hash code, GC age, lock flags, etc. Execute <init> – run the constructor to finish initialization.

Object Memory Layout : consists of the object header, instance data, and optional alignment padding to ensure 8‑byte alignment.

Object Access : Java can use either a handle (indirect reference via a handle pool) or a direct pointer. Handles simplify object movement during GC, while direct pointers offer faster access.

String Class and Constant Pool : String str1 = "abcd"; String str2 = new String("abcd"); System.out.println(str1 == str2); // false The first form stores the literal in the constant pool; the second creates a new heap object. The intern() method can move a heap string into the pool. String s1 = new String("计算机"); String s2 = s1.intern(); String s3 = "计算机"; System.out.println(s1 == s2); // false System.out.println(s3 == s2); // true

Wrapper Classes and Constant Pool : Integer i1 = 33; Integer i2 = 33; System.out.println(i1 == i2); // true (cached) Integer i11 = 333; Integer i22 = 333; System.out.println(i11 == i22); // false (outside cache) The source of the Integer.valueOf cache is shown, illustrating the -128 to 127 range.

References include "Deep Understanding of Java Virtual Machine" (2nd edition), "Practical Java Virtual Machine", and several online blog posts.