Understanding Java Class Loading, ClassLoaders, and the JVM's Parent Delegation Model

The article provides a comprehensive overview of Java's class loading process, starting with an overview of the JVM memory layout and the role of the method area for storing class metadata.

It then dives into the class loader subsystem, describing how class loaders are responsible for loading .class files from the file system or network, and how loaded class information is stored in the method area along with runtime constant pool data.

Key phases of class loading are explained:

Loading : obtaining the binary byte stream of a class and creating a java.lang.Class object in the method area.

Linking : verification, preparation (allocating memory for static variables), and resolution (converting symbolic references to direct references).

Initialization : executing the class constructor method <clinit>() and static initializers.

Examples illustrate these phases, such as the simple loader program:

public class HelloLoader {
    public static void main(String[] args) {
        System.out.println("hi classloader");
    }
}

The article categorizes the built‑in class loaders:

Bootstrap ClassLoader : implemented in C/C++, loads core Java libraries from rt.jar and has no parent.

Extension ClassLoader : written in Java, loads classes from java.ext.dirs and delegates to the bootstrap loader.

Application (System) ClassLoader : also written in Java, loads classes from the classpath and delegates to the extension loader.

It explains how to retrieve these loaders via ClassLoader.getSystemClassLoader() , Thread.currentThread().getContextClassLoader() , and Class.forName(...).getClassLoader() , showing sample output.

Custom class loaders can be created by extending java.lang.ClassLoader and overriding findClass . A sample implementation is provided:

public class CustomClassLoader extends ClassLoader {
    @Override
    protected Class
findClass(String name) throws ClassNotFoundException {
        byte[] bytes = getClassFromCustomPath(name);
        if (bytes == null) throw new FileNotFoundException();
        return defineClass(name, bytes, 0, bytes.length);
    }
    private byte[] getClassFromCustomPath(String name) { return null; }
    public static void main(String[] args) throws Exception {
        CustomClassLoader loader = new CustomClassLoader();
        Class
clazz = Class.forName("one", true, loader);
        Object instance = clazz.newInstance();
        System.out.println(instance.getClass().getClassLoader());
    }
}

The parent‑delegation model is described: a class loader first delegates the loading request to its parent, ultimately reaching the bootstrap loader; only if the parent cannot find the class does the child attempt to load it. This prevents duplicate loading and protects core API classes.

Examples demonstrate the delegation mechanism, such as attempting to define a custom java.lang.String class, which is blocked by the bootstrap loader, and the security sandbox that prevents user‑defined classes in the java.lang package.

Finally, the article discusses how the JVM determines class identity (same fully qualified name and same defining class loader) and distinguishes active versus passive class usage, listing the seven active usage scenarios that trigger class initialization.