Java Garbage Collection

Garbage collection is a crucial process that can help any Java development company. This powerful feature in programming languages deftly manages memory allocation and deallocation, preventing memory leaks and optimizing resource utilization. Acting as a steadfast janitor, it diligently cleans up unused objects, saving us from being swamped by unnecessary digital clutter. As a Java development company, we often encounter this challenge in our coding endeavors, and garbage collection provides an elegant solution to it. Let’s delve deeper into this sophisticated mechanism.

GC, the unsung hero of Java programming, not only cleans up after us but also makes Java memory efficient. It’s crucial because we as coders need to manage memory well by freeing up resources, especially unreferenced objects, and we often forget about it in our quest for new ideas (and sometimes due to laziness).

How Java Garbage Collection Works

Let’s examine the specifics of how this quiet cleaner functions in Java.

Garbage collection in Java is a process that automatically manages memory by reclaiming unused objects that are no longer in use.

Memory Structure

In Java, memory is divided into stack memory, heap memory, and metaspace. Let’s take a closer look.

Stack Memory

Stack memory is a region of memory that stores local variables, object references, method parameters, and other method-specific data during the execution of a method. The size of the stack memory is fixed.

Heap Memory

Heap memory is a region of memory that is used to store the actual objects. Its size is fixed, and it can grow or shrink dynamically as needed.

Here’s an example.

Integer num = new Integer(12);

This creates a “num” variable in the stack memory and a new Integer object in the heap memory. The “num” variable in the stack memory stores a reference to the original object.

Metaspace

Metaspace is a part of the native memory used by the Java Virtual Machine (JVM) to store metadata about classes and static methods. It replaced the Permanent Generation heap memory, which was part of the heap memory.

In earlier versions of Java, PermGen was used to store metadata about classes and static methods. But it had a few limitations. One of them was the fact that they had a fixed size. Another issue was that the PermGen space was garbage collected along with the rest of the heap, which led to performance issues.

The Metaspace is dynamically resizable and is garbage collected separately. It allows for the sharing of class metadata across multiple JVM instances, which can reduce memory usage and improve performance.

Eligibility for Garbage Collection

Live reachable objects are those that are being referenced by some part of the program while dead or unreachable objects are those that are not referenced by any part of the program. For example:

Integer num = new Integer(12);

num = null;

As discussed, the first line creates a new Integer object in the heap’s memory and a variable in the stack memory, which stores a reference to the original object.

Then, in the next line, we are changing the reference of “num”, which means “num” is not referring to the Integer object we created previously. In fact, that Integer object is not being referenced by any part of our program. Hence, it’s an unreachable or dead object. Dead objects can be garbage collected.

Objects become unreachable when:

All variables referencing that object do not reference it anymore (they are either set to null or set to a different value).
Objects created inside a method will become unreachable when that method is released from the stack memory.

Islands of Isolation

An island of isolation refers to a group of objects that reference each other but are no longer referenced by any objects in the program. In the example given below, both “a” and “b” are referencing each other but are not referenced by any other object.

class Node {

Node next;

Node prev;

}

Node a = new Node();

Node b = new Node();

a.next = b;

b.prev = a;

In order to break the island of isolation, we need to change the references of the objects. Here, they can be garbage collected only after changing the references of “a” and “b” (eg, setting a and b to null).

Parts of the Heap Memory

As discussed previously, the heap memory is the part of the memory responsible for storing the objects. It is divided into the Young Generation Space and the Old Generation Space.

Young Generation

In Java, the young generation heap memory is where new objects are created. This segment of memory is further divided into two sections: the Eden space and the Survivor spaces.

Eden Space

Eden space is the part of the young generational space where new objects are allocated.

Survivor Spaces

Objects in the Eden space that survive one round of garbage collection are promoted to the survivor spaces.

The number of Survivor Spaces in the Java Garbage Collector depends on the specific collector being used. The number of Survivor Spaces depends on the specific collector being used. In the Parallel Collector and the CMS Collector, there are multiple survivor spaces. The Parallel Collector divides the survivor space into multiple regions, while the CMS Collector uses multiple survivor spaces. We will take a closer look at the different Java garbage collectors below).

Old Generation

Objects that survive a certain number of garbage collection are promoted to the old generation. Objects in the old generation are more long-lived. They are not eligible for minor GC and are only cleared up during a major garbage collection.

The old generation is also called the tenured generation.

Steps Involved in Garbage Collection

Java garbage collection works by continuously monitoring the heap memory of the Java Virtual Machine to identify objects that are no longer in use.

Java garbage collection is performed in the following steps:

Marking: The GC first identifies all the live objects in the heap and marks them.

Sweeping: Once all the live objects have been identified and marked, the GC sweeps through the heap and frees up memory that is no longer in use. The memory is then available to be allocated to new objects.

Compacting: In some Java garbage collection algorithms, after sweeping, the remaining objects are compacted, meaning that they are moved to one end of the heap, making it easier for the JVM to allocate new objects.

Minor Garbage Collector

Minor garbage collection is the process of identifying and collecting garbage from the young generation, keeping it free of garbage and reducing the frequency of major Java garbage collection cycles.

Minor Java garbage collection works on a smaller heap size and is therefore considerably faster than major garbage collection.

Here’s how minor garbage collection works:

Eden Space Filling: As new objects are allocated in the Eden space, it eventually fills up. When the Eden space becomes full, the garbage collector begins a minor GC cycle.

Initial Marking: The garbage collector begins the minor garbage collection cycle by performing an initial marking phase. During this phase, the garbage collector identifies all live objects in the Eden space and the survivor spaces. The garbage collector marks these live objects to indicate that they should not be collected.

Copying Collection: After the initial marking phase is complete, the garbage collector performs a copying collection phase. During this phase, the garbage collector copies all live objects from the Eden space and one of the survivor spaces to the other survivor space.

Clearing Unused Space: After copying the live objects to the survivor space, the garbage collector clears the Eden space and the survivor space that was not used during the current garbage collection cycle. Any objects that were not copied to the survivor space are considered garbage and are reclaimed by the garbage collector.

Promotion of Objects: Objects that have survived a certain number of garbage collection cycles are eventually promoted to the old generation (also known as the tenured generation), where they will be managed by a different garbage collection algorithm that is optimized for longer-lived objects.

Multiple Cycles: If the survivor space that was used during the current Java garbage collection cycle becomes full, the collector will perform additional minor garbage collection cycles until enough objects have been promoted to the old generation or the survivor space becomes empty again.

Major Garbage Collector

When the old generational space is filled, the major garbage collector hits. It’s called “major” because it works on the entire heap and is invoked less frequently than the minor garbage collector. It is typically more time-consuming and resource-intensive.

The steps involved in major garbage collection are very similar to that described above.

Types of Garbage Collectors in Java

Java offers a few different types of garbage collectors. Here is a list of all the garbage collectors along with their working and the advantages.

Serial Collector or Stop and Copy

The Serial Garbage Collector is a type of GCr in Java that uses a single thread to perform the Java garbage collection process. It is primarily used in basic applications that have relatively simple memory usage patterns.

As you may have guessed, the Serial Garbage Collector works sequentially, meaning it stops all the threads in the application while performing the Java garbage collection process. This pause in the application’s execution is sometimes referred to as a “stop the world” event.

To use Serial Collector, pass in -XX:UseSerialCollector as argument.

Example, java -XX:UseSerialCollector YourProgram

Advantages of Serial Collector:

Simplicity: This is the simplest and most straightforward garbage collector in Java. It has a small footprint and requires minimal tuning.
Predictability: Because it uses a single thread, its behavior is predictable and easy to understand. This makes it useful for applications that require a predictable memory usage pattern.
Very Low Overhead: This makes it useful for small applications where performance is critical.

Disadvantages of Serial Collector:

Not Designed to Scale: It is not designed to scale with the size of the heap or the number of processors available on the system.
Poor Memory Usage: Provides poor utilization of available memory.
Long Pause Times: Due to its design long pause times are baked into the process.

Parallel Collector

The Parallel Garbage Collector, serving as the default garbage collector in Java, is a method that utilizes multiple threads to boost the performance of garbage collection. It is particularly effective for larger applications with intricate memory usage patterns.

By subdividing the heap into smaller segments, the Parallel Garbage Collector utilizes several threads to execute the garbage collection process concurrently. Similar to the serial collector, the Parallel Collector also causes a temporary pause in the application’s execution during garbage collection.

To use Parallel Collector, pass in -XX:+UseParallelGC as argument.

Advantages of Parallel Collector:

Faster: Offers improved performance compared to serial collectors due to its utilization of multiple threads, allowing for faster garbage collection operations.
Better Scalability: Designed to scale effectively with the size of the heap, making it suitable for applications with larger memory requirements.

Disadvantages of Parallel Collector:

Longer Pause Times: The Parallel Garbage Collector stops the application during the garbage collection process, which can result in longer pause times compared to other garbage collectors.
Higher CPU Overhead: The Parallel Garbage Collector uses multiple threads, which can result in higher overhead and increased memory usage.

Concurrent Mark Sweep Collector

The CMS (Concurrent Mark and Sweep) Collector is another type of garbage collector. It works concurrently with the application to perform the garbage collection process or to put it another way, it uses multiple garbage collector threads. It’s designed to minimize the pause times in the application and reduce the performance impact of Java garbage collection.

To use CMSCollector, pass in -XX:+UseConcMarkSweepGC as argument.

Advantages of CMS:

Low Pause Times: CMS minimizes pause times during garbage collection, providing a smoother experience for latency-sensitive applications.
Predictable: CMS offers more predictable garbage collection pauses, which can be crucial for real-time systems or applications with stringent performance requirements.
Suitable for Larger Heaps: CMS maintains its performance even as heap size increases, making it a viable option for applications with substantial memory demands.

Disadvantages of CMS:

Higher CPU Overhead: CMS consumes more CPU resources due to its concurrent nature, which may impact the overall performance of the application.
Risk of Fragmentation: CMS is not the ideal choice for long-running applications, as the heap can become fragmented over time. This fragmentation can lead to increased memory usage and diminished performance.

G1 Collector

The Garbage-First (G1) collector is a garbage collection algorithm introduced in Java 7, designed to address the limitations of traditional garbage collectors, such as the Parallel Collector and the CMS Collector. G1 is designed to be a low-pause, throughput-oriented collector that can handle very large heaps.

To use G1 Collector, pass in the argument:

-XX:+UseG1GC

Advantages of G1 Collector:

Low Pause Times: G1 is designed to minimize the pause times, which can make it suitable for real-time applications.
Scalability: G1 is scalable, which makes it suitable for large applications with varying heap sizes.

Disadvantages of G1 Collector:

Overhead: G1 consumes more CPU resources compared to other garbage collectors, leading to increased CPU overhead.
High Initial Marking Time: The initial marking phase can take longer in G1, particularly for large heap sizes, which may negatively impact application performance.
Not suitable for Small Heaps: G1 Collector is not ideal for applications with small heap sizes because its benefits are best realized in larger memory environments.

ZGC

The Z Garbage Collector (ZGC) is a Java garbage collector specifically designed to manage extremely large heaps (up to 16TB) while maintaining minimal pause times. Its primary objective is to minimize the duration of garbage collection processes, thereby maximizing the throughput of the application.

Advantages of ZGC:

Low Pause Times: It’s designed to minimize pause times, making it suitable for real-time or latency-sensitive applications.
Scalability: It’s engineered to scale with both the size of the heap and the number of available processors.
High Performance: It is optimized for high performance, achieving substantial throughput while minimizing the impact of Java garbage collection on the application’s performance.

Disadvantages of ZGC:

High Memory Overhead: The ZGC requires a significant amount of memory to function efficiently.
Limited Compatibility: The ZGC is only available on certain platforms, including Linux/x64, and requires a minimum of JDK 11.
Higher CPU Utilisation: Due to its advanced capabilities, ZGC may consume more CPU resources compared to other garbage collectors, potentially affecting overall application performance.

Shenandoah Collector

Shenandoah is a Java garbage collector designed to deliver ultra-low pause times while maintaining high throughput. As a concurrent garbage collector, it operates in parallel with the application, making it suitable for latency-sensitive applications.

To use Shenandoah Collector, pass in the argument:

-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC

Advantages of Shenandoah:

Ultra-low pause times: Provides minimal pause times, making it ideal for real-time or latency-sensitive applications.
Low memory overhead: Manages memory efficiently, leading to reduced memory overhead.
High throughput: Despite its focus on low pause times, Shenandoah still maintains high throughput, ensuring optimal application performance.

Disadvantages of Shenandoah:

Limited Compatibility: Shenandoah is only available on certain platforms, including Linux/x64, and requires a minimum of JDK 8u40.
Increased CPU Utilisation: This may consume more CPU resources compared to other garbage collectors, potentially affecting overall application performance.

System.gc()

Runtime.getRuntime().gc() or System.gc() are methods that ask the JVM to perform garbage collection to free up some memory–emphasis on the word “suggests,” as this is exactly what it does.

You cannot force garbage collection to happen. If you are getting “java.lang.OutOfMemoryError”, calling System,gc() will not fix the issue because JVM usually tries to run a garbage collector before throwing “java.lang.OutOfMemoryError.” Possible fixes can be using a different GC or increasing the heap size.

In general, it is recommended that developers avoid calling System.gc() directly and instead rely on the automatic garbage collection provided by the JVM.

Common Issues with Garbage Collection and How to Resolve Them

Here are some issues one might face:

Out of Memory Errors:

This error occurs when the JVM runs out of memory. To resolve this issue, developers can increase the heap size or optimize the application to use less memory.

-Xmx: sets the maximum heap size for your application.
-Xms: sets the initial heap size for your application.

For example, to set the maximum heap size to 2 gigabytes and the initial heap size to 512 megabytes, you can use the following command:

java -Xmx2g -Xms512m YourProgram

Long Pause Times:

Long pause times during garbage collection can cause the application to become unresponsive. To resolve this issue, you can choose a garbage collector that is designed for low pause times or tune the garbage collector parameters.

Memory Leaks:

Memory leaks occur when objects are not properly released from memory, leading to increased memory usage over time. To resolve this issue, developers can use tools such as profilers to identify memory leaks and fix them.

Best Practices for Managing Memory in Java

To avoid common issues with garbage collection and to manage memory efficiently, here’s some best practices:

Set reference to null: Always set reference to null when you no longer need an object.
Avoid creating unnecessary objects: Creating unnecessary objects can increase memory usage and cause more frequent garbage collection. You should avoid creating unnecessary objects and reuse existing objects when possible.
Using Anonymous Object: This is when you don’t store the reference to the object.

Example, createUser(new User()).

Release resources when they are no longer needed: Objects that use external resources such as file handles or database connections should be released when they are no longer needed to avoid memory leaks.

Conclusion

Understanding the mechanics of Java garbage collection is a must, whether you’re developing in-house or deciding to outsource Java development, particularly if you want to improve your Java application performance. We took a detailed look at this important part of Java programming, from the basics of how garbage collection works and the different types of garbage collectors to the finer points of memory management. Remember, even when you outsource Java development, choosing the right Java garbage collection type and managing memory efficiently will make a big difference in the speed of your application. Keep exploring, keep coding, and remember that every bit of efficiency can contribute to a smoother, faster application. Happy coding!

If you enjoyed this, be sure to check out one of our other Java articles:

FAQ

How can developers identify and diagnose memory leaks or inefficiencies in their Java applications?

Developers can identify and diagnose memory leaks or inefficiencies in their Java applications by:

Monitoring the application’s memory usage and GC logs using tools like JConsole, VisualVM, or Java Flight Recorder.
Analyzing heap dumps to identify objects that are taking up an excessive amount of memory.
Using profiling tools like YourKit, JProfiler, or Java Mission Control to identify hotspots and memory usage patterns.
Writing and running performance tests that simulate real-world usage scenarios.
Inspecting code and reviewing best practices for memory management, such as avoiding unnecessary object creation, minimizing object retention, and using appropriate data structures.

What are the trade-offs between throughput, latency, and memory overhead when selecting and configuring a garbage collector for a Java application?

When choosing and configuring a garbage collector that Java uses for an application, developers must weigh the trade-offs among throughput, latency, and memory overhead:

Throughput: This refers to the application’s ability to process workloads efficiently. Garbage collectors that emphasize high throughput may experience longer pauses during garbage collection, affecting application latency.
Latency: This is the time required for an application to respond to a request. Garbage collectors that focus on low latency may consume more memory to minimize the frequency of garbage collection pauses, resulting in increased memory overhead.
Memory overhead: This represents the amount of memory the GC uses to manage the application’s memory. Garbage collectors that require less memory might need more frequent garbage collection pauses, which can impact both throughput and latency.

Developers must carefully evaluate these trade-offs when selecting and configuring a garbage collector for their Java application, taking into account the unique requirements and constraints of their specific use case.