Deep Dive into JVM: Memory Areas, Class Loading, Object Creation, Garbage Collection and Tuning

What is the main role of the JVM?

JVM (Java Virtual Machine) abstracts operating‑system specifics so that Java programs compile to bytecode that can run on any platform with a JVM.

Please describe Java's memory areas

During execution the JVM divides memory into several regions, some thread‑private and some shared, collectively called the runtime data areas:

Java Virtual Machine Stack : thread‑private, stores local variables and stack frames.

Native Method Stack : thread‑private, stores frames for native methods.

Program Counter : thread‑private, holds the address of the next instruction.

Method Area : shared, stores class metadata, constants, static variables and JIT‑compiled code.

Heap : shared, the largest region, holds all object instances. Since JDK 7 the string constant pool resides in the heap.

Runtime Constant Pool : part of the method area, holds constants and symbolic references.

Please describe Java's class‑loading mechanism

The JVM loads class data from .class files into memory, then performs verification, preparation, resolution and initialization – the five fixed stages of class loading.

Loading

The JVM obtains the binary byte stream of a class by its fully qualified name, converts it into the internal data structures of the method area, and creates a Class object as an entry point.

Read from a ZIP/JAR/EAR file.

Download from the network (e.g., Web Applet).

Generate at runtime (dynamic proxies).

Generate from other files (e.g., JSP).

Read from a database.

Read from encrypted files (anti‑decompilation).

Verification

Ensures that the class file conforms to the JVM specification, checking file format, metadata, bytecode and symbolic references.

Preparation

Allocates memory for static variables in the method area and sets default values; constants with a ConstantValue attribute are initialized directly.

public
static
final
int
value =
"666"
;

Resolution

Transforms symbolic references in the constant pool into direct references.

Initialization

Executes the class’s <init> methods and static initializers after the previous stages are complete.

How are objects created in the JVM?

When the new bytecode is executed, the JVM checks that the class is loaded, resolved and initialized, then allocates memory in the heap (often via a thread‑local allocation buffer), zero‑fills it, sets the object header, and finally invokes the class’s constructor.

Memory allocation strategies

If the heap is contiguous, the JVM uses the "bump‑the‑pointer" technique; otherwise it falls back to a free‑list that tracks free blocks.

Object memory layout

In HotSpot an object consists of three parts: Header (MarkWord + Klass Pointer), Instance Data, and Padding to align to an 8‑byte boundary.

Header

Contains MarkWord (hashcode, lock state, age, etc.) and a Klass Pointer that identifies the object's class.

Instance Data

Stores the actual fields defined by the class (e.g., int , byte , object references).

Padding

Ensures the object size is a multiple of 8 bytes for alignment.

Object access methods

Objects can be accessed via handles (indirect pointers stored in a handle pool) or direct pointers (reference points straight to the instance data). Handles simplify object movement during GC, while direct pointers are faster.

How does the JVM determine that an object is dead?

Two main techniques are used: reference‑counting (rare in HotSpot) and reachability analysis from GC Roots (the standard approach). The latter traverses strong, soft, weak and phantom references to find unreachable objects.

When is a class considered unused and eligible for unloading?

All instances of the class have been reclaimed.

The class loader that loaded the class is itself unreachable.

The Class object is no longer referenced.

Generational garbage‑collection theory

HotSpot assumes most objects die young (strong generational hypothesis) and that objects surviving many collections become harder to reclaim (weak generational hypothesis). This leads to a division of the heap into Young and Old generations, with a Remembered Set tracking cross‑generation references.

Garbage‑collection algorithms

Mark‑Sweep : marks reachable objects then sweeps the rest; suffers from fragmentation.

Mark‑Copy : copies live objects to a survivor space; eliminates fragmentation but halves usable space.

Mark‑Compact : moves live objects to one end of the heap and compacts the free space.

Common HotSpot collectors

Serial (young generation, single‑thread, stop‑the‑world).

ParNew (multithreaded version of Serial).

Parallel Scavenge (throughput‑oriented young collector).

Serial Old (single‑threaded old‑generation, mark‑compact).

Parallel Old (multithreaded old‑generation, mark‑compact).

CMS (Concurrent Mark‑Sweep, low‑pause old collector).

G1 (region‑based collector, mixed collections, aims for predictable pauses).

Frequently used JVM commands

jps : lists JVM processes.

jstat : displays runtime statistics.

jinfo : shows or changes JVM configuration.

jmap : creates heap dumps.

jhat : analyzes heap dumps.

jstack : prints thread stack traces.

Parent‑delegation model

JVM uses a hierarchy of class loaders: Bootstrap (loads $JAVA_HOME/lib ), Extension (loads $JAVA_HOME/lib/ext ), and Application (loads classpath). A child loader first delegates to its parent; only if the parent cannot find the class does the child attempt loading.

Drawbacks of the parent‑delegation model

It cannot load Service Provider Interface (SPI) implementations that reside outside the core libraries, leading to the need for a thread‑context class loader.

Three times the model was broken

Before JDK 1.2, custom loaders used findClass directly.

Thread‑context class loader was introduced to allow user code to be visible to core libraries.

Frameworks like OSGi introduced custom loading strategies that bypass strict delegation for hot‑deployment.

Common JVM tuning parameters

-Xms and -Xmx : initial and maximum heap size.

-Xmn : size of the young generation.

-XX:+PrintGCDetails : prints detailed GC logs.

-XX:+HeapDumpOnOutOfMemoryError : dumps heap on OOM.

-XX:NewRatio , -XX:SurvivorRatio : tune generation proportions.

-XX:+UseSerialGC , -XX:+UseParallelGC , -XX:+UseConcMarkSweepGC , -XX:+UseG1GC : select collectors.

Postscript

This is the second edition of a JVM interview guide, expanded with many new sections; reading it fully takes about an hour.