HOW THE JVM HANDLES
CLASS LOADING
AND GARBAGE COLLECTION

As Java developers, we often focus on writing features, optimizing APIs, or fixing bugs. All while relying on the JVM to quietly do the heavy lifting underneath. Two of the most crucial mechanisms running behind the scenes are Class Loading and Garbage Collection (GC). These subsystems define how your code enters the runtime and how memory is managed once it’s running.

I’ll break them down in a way that aligns with everyday Java development.

The JVM Class Loading Mechanism

How your .class files come alive

Class loading is the process of taking your compiled bytecode (.class files) and making them available for execution inside the JVM. It’s handled by the ClassLoader subsystem, which works in three main phases:

Phase 1: Loading

The JVM locates the .class file and loads its binary data into memory.
Where do these classes come from?

• check_circle Local file system
• check_circle JARs inside your project
• check_circle Network (yes, possible)
• check_circle Runtime-generated bytecode (e.g., proxies)

Custom ClassLoaders can even load classes from databases, REST APIs, or encrypted sources. This is how frameworks like Spring dynamically generate proxies or enhanced classes.

Phase 2: Linking

This phase prepares the class for execution. It includes three sub-steps:

a. Verification

Checks whether the bytecode is valid and safe.
This prevents malformed or malicious bytecode from crashing the JVM.

b. Preparation

static int counter; // now exists in memory, default = 0

Allocates memory for:

• check_circle Static variables
• check_circle Default values (default int = 0, boolean = false, object references = null)

c. Resolution

Converts symbolic references (e.g., method names, field names) into real memory addresses.

Phase 3: Initialization

Now the static initializers and static blocks run:

static {
    System.out.println("Class loaded!");
}

This is the moment developers usually notice ClassLoader behavior when logs print unexpectedly early.

The ClassLoader Hierarchy

Here's the thing nobody tells you early in your Java journey: ClassLoaders are not equal. They’re hierarchical.
Just like a family, the JVM asks the parents first before doing anything itself.

• check_circle Bootstrap ClassLoader. The ancestor. Loads core JDK classes.
• check_circle Extension ClassLoader. Loads extension libraries.
• check_circle Application ClassLoader. Loads your application’s classes and libraries.

This hierarchy prevents dangerous overrides. You cannot define your own java.lang.String.
Your ClassLoader will ask the parent, the parent asks its parent, and so on and the JDK classes win every time.

In Java, class loading follows a parent-delegation model.
This means: whenever a ClassLoader wants to load a class, it first asks its parent ClassLoader to try loading it. Only if the parent cannot load it, the child tries.

Because of that rule:

• check_circle The Bootstrap ClassLoader (the top parent) loads all core JDK classes e.g., java.lang.String, java.util.List, java.io.File, etc.
• check_circle Since the Bootstrap ClassLoader loads these classes first, your custom ClassLoader can never override them, because the parent will always answer with the official JDK version.

This prevents someone from writing a malicious version like:

// NOT POSSIBLE
package java.lang;

public class String {
    // your own fake implementation
}

Even if you put a file like this in your app’s classpath, your ClassLoader will ask the parent first:

• check_circle AppClassLoader → check parent (PlatformClassLoader)
• check_circle PlatformClassLoader → check parent (Bootstrap)
• check_circle Bootstrap → "I already have java.lang.String loaded."
• check_circle Result → Your version is ignored.

This mechanism ensures security and stability, so core Java behavior cannot be modified or hijacked.

JVM Garbage Collection

How Java manages memory so you don’t manually free it.
The JVM heap is where objects live. Over time, unused objects pile up and this is where the Garbage Collector steps in.

JVM Memory Spaces

How the JVM Decides Who Lives and Who Dies

The Minor GC

Modern Garbage Collectors

How Does the JVM Decide When to Run GC?

Final Thoughts Mechanism

JVM Class Loading and Garbage Collection are invisible engines quiet, powerful, and often underappreciated. As Java developers, understanding them gives us superpowers.
It helps us debug smarter, design cleaner systems, and build applications that scale gracefully.
If you're building high-performance services, diving deeper into GC tuning, classloader isolation, and bytecode generation is worth every minute.