devkuma – JVM

JVM Memory Structure

kc@example.com (kc kim) — Thu, 20 Jan 2022 07:48:00 +0900

Understanding the memory model used by Java is very helpful when writing Java programs.

JVM(Java Virtual Machine)

A Java process runs on a virtual system called the JVM. This structure allows compiled Java class files (bytecode) to run in many operating system environments.

Java bytecode

Java bytecode means Java source code converted into a language that the Java Virtual Machine can understand. It is called Java bytecode because the instructions generated by the Java compiler are 1 byte in size. The extension of Java bytecode is `.class`. Java bytecode can run on any operating system as long as a Java Virtual Machine is installed.

Java Memory Area Structure

Every Java program runs through the Java Virtual Machine (JVM). When a Java program starts, the JVM receives the memory it needs from the operating system to run that program.

To use the allocated memory efficiently, the JVM divides and manages memory space by purpose as follows.

The Runtime Data Area is the memory area allocated by the operating system, and it stores the data used when running a Java application.
It can be broadly divided into the Method Area, Heap Area, Stack Area, PC Register, and Native Method Stack.

Method Area / Static Area

The method area stores information about classes used in a Java program, along with class variables (static variables).
When a specific class is used in a Java program, the JVM reads the class file (*.class), which is Java bytecode, and stores the runtime constant pool, member variables (fields), class variables (static variables), constructors, and methods for the loaded class and interfaces.

The contents stored in this area are loaded before the program starts and are destroyed when the program ends.
The runtime constant pool contains various constants, from numeric literals known at compile time to method and field references that must be resolved at runtime.

In computer science, a literal means a fixed value. A constant is a variable that does not change, while a literal is a value (data) that does not change.

Heap Area

The heap area stores all class object (instance) variables used by a Java program. It is an area dynamically allocated at runtime to store data in the program managed by the JVM.

Data that changes dynamically while the process runs is basically allocated here. In other words, when an instance is created with the new operator in a Java program, the JVM stores the instance information in the heap area.
The heap area is allocated from lower memory addresses toward higher addresses.

If a variable in the stack area references an instance in the heap area and later no longer references it, the instance is removed by garbage collection in the Java Virtual Machine.

Garbage collection is not executed every time an instance is no longer referenced. If it were, the program would consume many resources just by invoking garbage collection, degrading performance. Therefore, it runs according to the garbage collection algorithm.

The lifetime and thread-sharing scope of the heap area are as follows.

When an object is no longer used or is explicitly declared as null
Target of GC (Garbage Collection)
The configuration method or GC method may differ by JVM vendor.
Shared by all threads.

For applications that run as the same process for a long time, optimizing memory use in this heap area is important. Options for specifying the allocation size are as follows.

-Xms20m -Xmx100m

With the settings above, the configuration is as follows.

Initial size of memory allocated to the heap area: 20MB
Maximum size of memory allocated to the heap area: 100MB

Stack Area

The stack area stores a method’s stack frame when a method is called in a Java program.

When a method is called in a Java program, the JVM stores local variables and parameters related to the method call in the stack area. The stack area is allocated when a method is called and disappears when the method call completes. The method call information stored in the stack area is called a stack frame.

The stack area inputs data with Push and outputs data with Pop. Because this stack works in LIFO (Last-In First-Out) order, the data stored last comes out first.

The stack area is allocated from higher memory addresses toward lower addresses.

PC Register

Holds the address of the JVM instruction currently being executed. It can be said to play the same role as the CPU’s PC.
Program execution performs instructions on the CPU.
While the CPU executes instructions, it stores required information in registers, which are storage devices inside the CPU.
A storage device inside the CPU that stores operation results before sending them to memory. (Usually, while the CPU processes instructions, it stores the information needed during execution in CPU-internal storage called registers. This is inevitably dependent on the CPU. To realize Java’s philosophy, the role of CPU registers is implemented as a logical memory area on the JVM.)

Native Method Stack Area

This is a stack for native code written in languages other than Java.
In other words, it is the stack used to execute code such as C or C++ called through JNI (Java Native Interface).
It stores native method parameters, local variables, and so on as bytecode.

References

JVM Heap Memory

kc@example.com (kc kim) — Thu, 20 Jan 2022 07:48:00 +0900

What Is Heap Memory?

Heap memory is the space where objects dynamically created while a Java program runs (objects or instances created with the new operator) are stored.
Objects created here can be referenced by fields of other objects or by methods that exist on the stack. If the referencing variable disappears, the object is considered unnecessary and is deallocated by the Garbage Collector.

Role of the Heap Memory Area

The heap area has several functions, so it is divided into multiple parts. It is managed by separating the space where objects are first created from the space where objects are moved after not being used for a certain time so that garbage collection can be performed.

Java 7 HotSpot JVM

Java 8 HotSpot JVM

Young Generation

This is the space in heap memory where newly created objects are first placed.

The Young Generation is divided as follows.

Eden
- This is the memory area allocated immediately after a Java object is created. In other words, newly created objects made with the new operator are placed here.
Survivor1, Survivor2
- When each area becomes full, surviving objects move to the empty Survivor area.
- At this time, objects without references are collected by Minor GC.

Old Generation

Objects that survive garbage collection to the end in the Young Generation come to the Old Generation. In other words, this is the area where old data is stored.
Major GC occurs here, and it happens less frequently than Minor GC.

Permanent Generation

Permanent Generation is the area where class or method code is stored. PermGen belongs to the Heap area.
PermGen, short for Permanent Generation, is a special heap space separate from the main Java heap that the JVM uses to track metadata for loaded classes.
Permanent Generation stores data that is more or less guaranteed not to change, such as information about loaded classes.

It has a limited default size. (32-bit JVM: 64MB, 64-bit JVM: 82MB)

JVM Argument

-XX:PermSize=N      --> Set the default PermGen size.
-XX:MaxPermSize=N   --> Set the maximum PermGen size.

Metaspace Generation

With the release of Java 8, there was a change in the JVM area. Among the JVM memory areas, the Permanent Generation memory area disappeared and the Metaspace area was introduced. Metaspace replaces the Perm area from before Java 8 and is the area where class and method metadata is stored.

Metaspace is the space where metadata for classes loaded so far by Java’s Classloader is stored.
The important point is that it is located in native memory, not the Heap area.
It does not have a limited default size. Therefore, it continues to grow as needed.
Starting with Java 8, JVM options related to PermGen are ignored.

JVM Argument

-XX:MetaspaceSize=N
-XX:MaxMetaspaceSize=N

MetaspaceSize: Sets the default Metaspace size.
- This setting is used to change the amount of native memory used by the JVM.
- Use this option if you are confident that the system will use more memory than the default provided by the system.
MaxMetaspaceSize: Sets the maximum Metaspace size.
- This setting is used to change the maximum amount of memory for metaspace.
- Use it when you want to tune the memory area while running an application on a server or when you want to prevent a memory leak from consuming the entire system’s native memory.
- If native memory is full but the application still requests more memory, java.lang.OutOfMemoryError: Metadata space occurs.
- If no setting is specified, no limit is applied.

Permanent and Metaspace

In Java 8, PermGen was renamed to Metaspace, although there are some differences. The important point is that Metaspace has no default maximum size. By contrast, PermGen in Java 7 and earlier has a default maximum size of 64MB on 32-bit JVMs and 82MB on 64-bit versions. Of course, this is not the same as the initial size. Java 7 and earlier start with roughly 12-21MB of initial PermGen space.

The comparison of default limited sizes for Permanent and Metaspace is as follows.

JVM	Default maximum PermGen size (MB)	Default maximum Metaspace size
32-bit client JVM	64	unlimited
32-bit server JVM	64	unlimited
64-bit JVM	82	unlimited

Before Java 7, interned strings were stored in PermGen. This caused the following well-known serious error.

java.lang.OutOfMemoryError: PermGen space

Whenever the size of PermGen/Metaspace must be adjusted, the JVM adjusts it like the standard heap. Adjusting the size of this space requires a full GC, which is always expensive. This is commonly observed during startup when many classes are loaded, especially when an application depends on many external libraries. If many Full GCs occur during startup, this is often the reason. In such cases, increasing the initial size can improve startup performance.

The advantages and disadvantages of the change from PermGen to Metaspace are as follows.

Advantages

Because the PermGen area was removed, the memory available to the heap area increased.
Several complex pieces of code that existed to remove the PermGen area were removed, and the time spent scanning the PermGen area decreased, improving GC performance.

Disadvantages

Although PermGen space can no longer be exhausted (because PermGen no longer exists), excessive native memory can be consumed, increasing the overall process size.
The problem is that if an application loads many classes or strings, it can actually bring down not only the application but also the entire server. This is because native memory is limited only by the operating system. In other words, it can consume all memory on the server.

Managing Memory Through Java Code

Let’s analyze Java code and look at how memory is managed here.

class Person {
    int id;
    String name;

    public Person(int id, String name) {
        this.id = id;
        this.name = name;
    }
}

public class PersonBuilder {
    private static Person buildPerson(int id, String name) {
        return new Person(id, name);
    }

    public static void main(String[] args) {
        int id = 23;
        String name = "John";
        Person person = null;
        person = buildPerson(id, name);
    }
}

When the main() method is entered, space is created in stack memory to store the method’s primitives and references.
- Stack memory directly stores the primitive value of the integer id.
- The reference variable person of type Person is also created in stack memory and points to the actual object in the heap.
The call from main() to the parameterized constructor Person(int, String) allocates additional memory on top of the previous stack. This stores:
- The this object reference of the called object in stack memory
- The primitive value id in stack memory
- The reference variable for the string argument name, which points to the actual string in the string pool in heap memory
The main method additionally calls the static method buildPerson(), and an additional allocation occurs in stack memory on top of the previous method for this method. This stores variables again in the manner described above.
However, heap memory stores all instance variables for the newly created object person of type Person.

This allocation is shown in the diagram below.

Source: https://www.baeldung.com/java-stack-heap

JVM Garbage Collection

kc@example.com (kc kim) — Thu, 20 Jan 2022 07:48:00 +0900

What Is Garbage Collection?

Garbage collection (GC) is a JVM task that automatically releases memory no longer used by a Java process.

Objects stored in the heap area at Java runtime continue to accumulate if they are not cleaned up, which can cause an OutOfMemoryError (OOME). To prevent this, the JVM periodically collects and cleans up unused objects through GC.

In languages such as C, memory must be allocated and released manually with functions such as malloc() and free(). Java removes this inconvenience by using GC technology to release memory automatically, freeing developers from manual memory management.

Java code does not explicitly specify and release memory. Some developers set objects to null or call the System.gc() method. Setting an object to null is not a major problem, but calling System.gc() can have a very large impact on system performance, so the System.gc() method should never be used.

To understand JVM GC, you first need to understand the JVM memory structure. For the JVM memory structure, refer to this page.

Unnecessary Memory Areas

If an application is built without considering memory usage, unused garbage data is created.

For example, suppose there is a class like the following.

class TreeNode {
    public TreeNode left, right;
    public int data;
    TreeNode(TreeNode l, TreeNode r, int d) {
        left = l; right = r; data = d;
    }
    public void setLeft(TreeNode l) { left = l;}
    public void setRight(TreeNode r) {right = r;}
}

Create TreeNode objects with the following processing.

TreeNode left = new TreeNode(null, null, 13);
TreeNode right = new TreeNode(null, null, 19);
TreeNode root = new TreeNode(left, right, 17);

In this state, the root node references the left node and the right node.

Now suppose processing is added to replace the right node.

root.setRight(new TreeNode(null, null, 21));

Then the node with value 19 that was originally in the right node is no longer referenced by anything, resulting in the state shown below.

In this state, the TreeNode instance with data=19 is an object that is not referenced from anywhere. In other words, it becomes an unreachable object and therefore garbage.

If unused data continues to be created, unnecessary memory accumulates and eventually reaches the capacity limit. To prevent this in advance, GC (garbage collection), a mechanism that automatically releases unnecessary memory in the heap area, became necessary.

GC and the Role of the Heap Area

As mentioned earlier, GC is a mechanism that releases memory that is no longer needed.
It examines data in memory. If there is a reference, the data remains as valid data; if there is no reference, it is judged unnecessary and released. However, checking all memory space in a simple way is inefficient, so memory is internally divided and managed according to how long data exists.

Newer data is called Young Generation, older data is called Old Generation, and data judged in advance to be difficult to change is called Permanent Generation.

Basically, memory allocation occurs frequently, but most data is assumed to become unreferenced, so it is divided into short-lived data (Young Generation) and long-lived data (Old Generation). This allows GC to efficiently check only the data included in the Young Generation.

There is also an area called Permanent Generation, which stores data that is more or less guaranteed not to change, such as information about loaded classes.

The Permanent Generation memory area disappeared with Java 8, and the Metaspace area was introduced. For details about the Metaspace area, refer to this page.

Reference: OpenJDK documentation

GC Cycle

The heap area used by an application is broadly divided by GC execution area into the Young area (Eden, Survivor1, Survivor2) and the Old (Tenured) area.

The Young area of the heap is divided into Eden and Survivor as shown below, and GC is performed by using each area appropriately.

Each area has the following role.

Eden
- The memory area allocated immediately after a Java object is created.
- Objects that survive regular garbage collection move to Survivor.
Survivor1, Survivor2
- Data that is not released after GC and does not go to Old. There are two areas for convenience, simply named 1 and 2.
Tenured
- Data that survives a specified number of GCs is moved to Old.

GC is divided into Minor GC and Major GC (Full GC) depending on the area where GC is performed.

GC in the Young area is called Minor GC.
GC in the Old area is called Full GC (or Major GC).

When Full GC occurs, stop-the-world happens, momentarily stopping the Java application. Because it is relatively slow, it can have a major impact on performance and stability.

STW(Stop the world)

What is stop the world? It means that, in order for GC to find and remove objects that are no longer needed, all threads except the thread running GC are stopped. When stop-the-world occurs, every thread except the GC thread stops its work. After the GC work completes, processing starts again. Because the application stops while STW occurs, it can lead to failures. In most cases, GC tuning means reducing stop-the-world time.

Minor GC

GC that targets only the Young Generation is called Minor GC. It has the following characteristics.

Processing time is short.
It occurs when Eden becomes full.
If an object becomes a GC target a certain number of times, it moves to Old.
During GC, process execution stops (Stop the world).

Since diagrams are easier than text for this topic, it will be explained with diagrams.

When newly allocated memory fills the Eden area, Minor GC occurs.
Data without references is deleted, but valid data is copied to the Survivor area. The Eden area then becomes empty.

Then, if the Eden area becomes full again in this state, another Minor GC occurs and the result is as shown below.

This time, after GC, all surviving data entered the Survivor2 area. Survivor data is copied to whichever Survivor area is empty, moving back and forth between 1 and 2. Therefore, one of Survivor1 and Survivor2 is always kept empty.
Also, as with the Eden area, data in the Survivor area that is no longer referenced is deleted.

Next is promotion to the Old area. Each time GC occurs, the count is recorded for data in the Young area, and when it exceeds a certain number, it moves to Old.

As GC is repeated several times like this, movement from the Young area to the Old area occurs. This count can be specified with an option, and the frequency of moving to the Old area can be controlled with the option below.

-XX:MaxTenuringThreshold=N

Full GC

We have now seen the structure where data moves from the Young area to the Old area. If this were all, the capacity of the Old area would always increase and eventually reach its limit. At that point, Full GC occurs. Full GC occurs when allocation to the Old area fails, and it cleans memory including both the Old area and the Young area.

This secures space that is no longer needed in the Old area and makes it possible to copy data from the Survivor area.

As with Minor GC, the application stops during Full GC. Because the pause time becomes longer in proportion to the amount of data in the Old area, it is important to release memory as much as possible in the Young area and minimize Full GC occurrences.

GC Cycle Summary

The GC cycle can be summarized as follows.

When the Eden area becomes full, Minor GC occurs.
Minor GC releases the Young area, and objects are promoted to Old if they satisfy the conditions.
When the Old area becomes full, Full GC occurs.
Full GC releases the Old area and secures space for promotion.

Automatic Garbage Collection

Let’s look at the garbage collection process.

Automatic Garbage Collection is the process of identifying which objects in heap memory are in use and which are not, then removing unused objects. An object in use or referenced means that some part of the program still maintains a pointer to that object.

In programming languages such as C, memory must be manually allocated or released, but in Java, memory is automatically released by the Garbage Collector. Let’s look at the basic process of Automatic GC.

Step 1: Marking

Marking is the process of identifying memory in pieces.

The garbage collector checks referenced objects (reachable/live objects) in memory and marks which objects are unreferenced (unreachable objects).

Referenced objects are shown in blue, and the rest are shown in orange. Every object is scanned during the marking process to make this decision. This process is time-consuming because every object in the system must be scanned.

Step 2: Normal Deletion

Normal Deletion is the process of deleting unreferenced objects.

The garbage collector deletes unreferenced objects (unreachable objects).

After deleting unreferenced objects, it leaves pointers to referenced objects and free space. The memory allocator keeps references to free space for newly allocated objects.

Step 2a: Deletion with Compacting

To improve deletion performance, this process deletes unreferenced objects and also compacts the remaining spaces.

Some garbage collectors delete unreferenced objects (unreachable objects) while also performing compaction to use memory more effectively.

By gathering objects in one place, new memory allocation becomes easier and faster. The Memory Allocator only needs to keep the start address of free space. New objects are then allocated sequentially.

Source: Oracle official documentation: Java Garbage Collection Basics

GC Algorithms

There are several GC algorithms. The four representative ones are as follows.

Serial GC
Parallel GC
CMS (Concurrent Mark & Sweep) GC
Garbage First GC (G1GC)

GC algorithms are classified by considering throughput and responsiveness.

Application-stop type
- Serial GC, Parallel GC
- Default GC for single-core and multi-core environments
- Focuses on throughput, but because the time stopped by GC can become long, it may not satisfy response time requirements.
Concurrent processing type in parallel with the application
- CMS, G1GC
- Chosen in multi-core environments when Parallel GC cannot satisfy response time requirements
- Throughput may decrease.

There is a method of dividing GC into two stages and suppressing maximum application pauses.

A stage where GC runs concurrently with the application
A stage where the application stops and GC runs

Serial GC

As the word “Serial” suggests, Serial GC is a sequential GC method.
It was the default garbage collector in Java SE 5 and 6, and it mainly runs as a single thread on 32-bit JVMs.
Mark-sweep and compaction are executed with a single thread.
It was used in single-core environments.

As shown in the image below, because the GC thread performs GC as a single thread, execution time is long.

In other words, while the GC thread is running, the Stop-the-World (Pause) duration is long.

The Serial GC-related option is as follows.

-XX:+UseSerialGC

Mark-Sweep-Compaction

Mark-Sweep-Compaction is an algorithm used by various different GCs. It can be thought of as the basic GC process. Because GC removes unused objects from memory, it identifies GC target objects, removes them, and fills fragmented memory areas from the front. - Identifying unused objects (Mark) - Removing unused objects (Sweep) - Filling fragmented memory areas from the front (Compaction) The Compaction step can be understood by thinking of disk defragmentation in Windows.

Parallel GC

Parallel GC works on the same principle as Serial GC, but differs in that the Young area GC process is performed with multiple threads.
Therefore, GC thread execution time is relatively shorter than Serial GC, and Stop-the-World (Pause) occurs for a shorter time.

It works quickly by specifying the number of threads and using multiple threads at the same time to perform GC.
It is the default in multi-core environments and performs mark-sweep and compaction with multiple threads.

There are Low-pause and Throughput methods.

Low-pause: Focuses on minimizing the momentary pause of application execution rather than executing GC quickly.
Throughput: Focuses on quickly executing Minor GC, and uses only the Mark & Compact algorithm for Full GC.

Parallel GC-related options are as follows.

-XX:+UseParallelGC
- This CLI option enables a multi-threaded young generation collector and a single-threaded old generation collector.
-XX:ParallelGCThreads=<desired number>
- By default, on a host with N CPUs, parallel GC uses N GC threads. The number of threads can be controlled with the CLI.

Parallel Old GC(Parallel Compacting GC)

Parallel Old GC is a GC method provided since Java 5 update 6. Compared with the Parallel GC described above, only the GC algorithm for the Old area is different. This method goes through Mark-Summary-Compaction.
The Summary step differs from the Sweep step of the Mark-Sweep-Compaction algorithm in that it separately identifies live objects in the area where GC was previously performed, and it goes through a slightly more complex process.

The Parallel Old GC-related option is as follows.

-XX:+UseParallelOldGC
- This CLI option enables a multi-threaded collector in both the young generation and old generation. In addition, the compacting collector also runs with multiple threads.

CMS (Concurrent Mark & Sweep) GC

CMS GC aims to minimize application stops (stop-the-world) caused by GC by performing GC work concurrently with application threads. Because it does not perform compaction, it uses more memory.

Because CPU resources are used for cooperation between threads and related processing, application throughput is expected to decrease, but the overall application stop time becomes shorter. As a result, GC has less impact on response time.

If CPU usage is high, performance may degrade; in that case, Parallel GC is used.
Its disadvantages are high CPU resource usage and possible memory fragmentation.

In the Initial Mark stage, objects in a referenced state are marked in a short time. Then, without stopping everything, the Concurrent Mark stage checks referenced objects.
In the Remark stage, changed or newly added objects are checked. In the Concurrent Sweep stage, unreferenced objects are cleaned up.

The CMS GC-related option is as follows.

-XX:+UseConcMarkSweepGC

G1(Garbage First) GC

G1 GC was created to replace CMS. It is not divided into the existing Young and Old areas; instead, it manages the heap by dividing it into small areas called “regions”. It copies objects from one or more regions and moves them to other regions. Unlike CMS, it removes memory fragmentation through the Compaction step. It was officially added in Java 7.

It is intended to use effective GC on multiple CPUs and very large memory. According to Oracle documentation, when the heap size is larger than 6GB, GC latency can be reduced below 0.5sec. According to Oracle G1 GC documentation, Java 9 uses it as the default GC. (Previously, Parallel GC was the default.)

G1 GC is named Garbage First because it first collects regions that contain only garbage.

The G1 GC-related option is as follows.

-XX:+UseG1GC

History of GC

Before Java 6
- Serial GC, Parallel GC, CMS GC
Java 8
- Serial GC and Parallel GC are the defaults.
Java 7
- G1 GC was added.
Java 9
- G1 GC is the default.

References

Java String Constant Pool

kc@example.com (kc kim) — Thu, 20 Jan 2022 07:48:00 +0900

How String Values Are Stored in Memory

There are two ways to create a String in Java.

Using the new operator
Using a literal

The differences between the two declaration methods are as follows.

	`new` declaration	Literal declaration
Storage location	Stored in the “Heap” area	Stored in the “String constant pool”
Speed	Slower than literal declaration	Faster than `new` declaration
Comparing identical strings	Must use the `.equals` method to get the same result	Can be compared with the `==` operator

If the string exists in the “String constant pool”, its address value is returned. If it does not exist, it is stored and a new address value is returned. The string constant pool exists in the Perm area, but its location changed starting with Java 7.

If the same string is created in the two ways above and compared with the == operator and .equals(), the following result is produced.

public static void main(String[] args) {
    String a = "apple";
    String b = "apple";
    String c = new String("apple");
    
    System.out.println(a == b); // true
    System.out.println(a == c); // false
    
    System.out.println(a.equals(b)); // true
    System.out.println(a.equals(c)); // true
}

Change in String Constant Pool Location

Until Java 6, the String constant pool was located in the Perm area. In Java 7, it was moved from the Perm area to the Heap area. The reason was the OutOfMemoryException problem.

The Perm area has a fixed size and does not expand at runtime. Although the size of the Perm area can be increased, its size still does not change at runtime. Therefore, until Java 6, calling the String intern() method could cause an OutOfMemoryException, and there was no way to control that part, so it was generally better not to use it.

For this reason, Oracle engineers moved the string constant pool in Java 7 from the Perm area to the Heap area. What benefit does this provide? Every string in the string constant pool can now become a GC target.

The size of the String constant pool can be specified with the -xx:StringTableSize option. This should be set to a prime number such as 1,000,003, not a number like 1,000,000. It is related to hashCode performance, and the Java Performance Tuning Guide article explains the details.

If you actively use the intern() method, you should set -xx:StringTableSize higher than the default value (1009). Otherwise, performance can degrade to the level of a linked list.

Reference

Thoughts on Java String Memory

Java ClassLoader

kc@example.com (kc kim) — Sat, 09 Dec 2023 23:56:00 +0900

What Is a ClassLoader?

The JVM uses something called a Class Loader to load classes. There is not just one Class Loader. In addition to the multiple class loaders used by the JVM for different purposes, J2EE containers also define additional class loaders hierarchically, and users can define their own class loaders as well.

A Class Loader loads classes into memory. In other words, it dynamically loads compiled classes (.class) into memory. Dynamic loading means that when a class file is needed and executed at runtime, rather than compile time, it is loaded into memory.

Basic Behavior of ClassLoader

There are three class loaders defined in J2SE.

Bootstrap Class Loader
- Initial class loader
- Class loader for core packages and so on (rt.jar, i18n.jar)
Extension Class Loader
- Class loader for installed optional extension packages (lib/ext)
- Up to Java 8: inherits URLClassLoader and loads classes in jre/lib/ext and folders specified by the java.ext.dirs environment variable.
- From Java 9 onward: no longer supports jre/lib/ext or java.ext.dirs, and loads all Java SE classes and classes of modules standardized by the JCP (Java Community Process).
  - It inherits BuiltinClassLoader, is implemented as an internal static class of ClassLoader, and has been changed to PlatformClassLoader.
User-defined Class Loader (System Class Loader, Application Class Loader)
- classpath class loader

Class loaders have parent-child relationships. A parent class loader does not know its child class loaders, but a child class loader knows its parent. When a child class loader receives a class loading request, it delegates to the parent and loads the first class found. If the target class belongs to the responsibility range of a child class loader rather than the class loader that received the request, the class is not found and loading fails.

A class loader receives a class loading request. loadClass()
It checks whether the class is already loaded. findLoadedClass
If it is not loaded, processing is delegated to the parent class loader, or to the bootstrap class loader (findBootstrapClassOrNull()) if there is no parent. parent.loadClass(name, false)
If it is still not loaded, it searches for and tries to load it. findClass()

Specifically, the loadClass(..) method of java.lang.ClassLoader shows this behavior.

    protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // First, check if the class has already been loaded
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    if (parent != null) {
                        c = parent.loadClass(name, false);
                    } else {
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                    // ClassNotFoundException thrown if class not found
                    // from the non-null parent class loader
                }

                if (c == null) {
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    long t1 = System.nanoTime();
                    c = findClass(name);

                    // this is the defining class loader; record the stats
                    PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }

The bootstrap class loader loads core packages and similar classes, and it has no parent itself. A user-defined class loader is derived with the system class loader, which runs at boot time, as its parent.

For example, in a J2EE container, the class loader that loads an EAR utility JAR becomes the parent of the class loader that loads WAR web components, so web components can call the EAR utility JAR. Conversely, the EAR utility JAR cannot call web components inside the child WAR.

Also, fields qualified as static are executed only once when the class is loaded, so they exist as a single instance within the class loader. Integrating class loaders can make utility classes common classes, but it may cause unexpected side effects, so you need to understand and carefully inspect the behavior.

A class loader is a class that inherits from the abstract class java.lang.ClassLoader. For example, within core packages, java.security.SecureClassLoader and java.net.URLClassLoader are defined as classes that inherit from this class.

Example of Searching ClassLoaders

The following code is an example that searches class loaders.

package com.devkuma.basic.classloader;

class GetClassLoader {
    public static void main(String[] args) {
        // Bootstrap class loader
        System.out.println("- Bootstrap Class Loader");
        ClassLoader bootstrap = "".getClass().getClassLoader();
        System.out.println(bootstrap);
        if (bootstrap != null) {
            ClassLoader parent = bootstrap.getParent();
            System.out.println(parent);
        } else {
            System.out.println("No parent");
        }

        // Platform Class Loader
        System.out.println("- Platform Class Loader");
        ClassLoader extensions = GetClassLoader.class.getClassLoader().getParent();
        System.out.println(extensions);
        if (extensions != null) {
            ClassLoader parent = extensions.getParent();
            System.out.println(parent);
        } else {
            System.out.println("No parent");
        }

        // System Class Loader
        System.out.println("- System Class Loader");
        DemoClass myObj = new DemoClass();
        ClassLoader systems = myObj.getClass().getClassLoader();
        System.out.println(systems);
        if (systems != null) {
            ClassLoader parent = systems.getParent();
            System.out.println(parent);
        } else {
            System.out.println("No parent");
        }

        // Context Classloader
        System.out.println("- Context Classloader");
        ClassLoader threads = Thread.currentThread().getContextClassLoader();
        System.out.println(threads);
        if (threads != null) {
            ClassLoader parent = threads.getParent();
            System.out.println(parent);
        } else {
            System.out.println("No parent");
        }
    }
}

class DemoClass {
    String getClassName() {
        return "DemoClass";
    }
}

The output is as follows. Here, the context class loader is the class loader used to load classes within that thread.

- Bootstrap Class Loader
null
No parent
- Platform Class Loader
jdk.internal.loader.ClassLoaders$PlatformClassLoader@7dc5e7b4
null
- System Class Loader
jdk.internal.loader.ClassLoaders$AppClassLoader@799f7e29
jdk.internal.loader.ClassLoaders$PlatformClassLoader@7dc5e7b4
- Context Classloader
jdk.internal.loader.ClassLoaders$AppClassLoader@799f7e29
jdk.internal.loader.ClassLoaders$PlatformClassLoader@7dc5e7b4

JVM Memory

kc@example.com (kc kim) — Thu, 20 Jan 2022 07:48:00 +0900

JVM (Java Virtual Machine)

A computer that uses Java bytecode as its machine language is called the Java Virtual Machine.