Hello user_name!
Knowledge of how GC and JVM work is essential for every Java developer. Proper resource management directly affects application performance and stability.
Automatic Memory Management
When a new object is created in Java, the JVM automatically allocates the necessary amount of memory for it in the heap. The size of memory allocated for each object is determined by its structure: what fields it has, what data types are used, and so on.
While an object is actively used (there are references to it in the program), it remains in memory. Objects can be accessible in various heap memory areas, such as Young Generation, Old Generation, and PermGen (in older JVM versions) or Metaspace (in newer versions).
The Garbage Collector (GC) works in the background and periodically checks which objects in memory are no longer accessible to the application. This is achieved by tracking references to objects. An object is considered "garbage" if there are no active references to it.
Once an object is identified as unreachable, the GC frees the memory occupied by that object. This releases resources and makes memory available for new objects.
In addition to freeing memory, the GC can also participate in optimizing memory allocation, for example, by compacting the remaining heap to prevent memory fragmentation.
Although memory management is automated, understanding its working principles is important for optimizing performance and avoiding problems such as delays due to long garbage collection operations. Inefficient memory usage and improper object handling can lead to excessive load on the garbage collector, which in turn can cause performance issues.
The GC periodically checks memory for objects that are no longer accessible (have no active strong references). This process can be initiated automatically or manually (through calling System.gc(), although its use is not recommended).
After detecting unreachable objects, the GC frees the memory occupied by these objects, making it available for new objects.
Types of GC in JVM
Serial Garbage Collector
Serial GC operates in single-threaded mode, which means that during garbage collection, all other application threads are suspended (Stop-The-World pause). This is the simplest and most basic garbage collector in JVM, without additional complexities of multi-threaded processing or parallel garbage collection.
When Serial GC begins the garbage collection process, it stops all other threads in the application. This means that application execution is completely suspended for the duration of garbage collection.
Parallel Garbage Collector (Throughput Collector)
Parallel GC uses multiple threads to perform GC tasks, allowing efficient use of multiprocessor systems. The main goal is to maximize application throughput, that is, the maximum amount of work the application can perform per unit of time.
Like Serial GC, Parallel GC also initiates Stop-The-World pauses. During these pauses, all application threads are suspended to perform GC tasks.
G1 Garbage Collector
G1 (Garbage-First) Garbage Collector differs from traditional approaches such as CMS or Parallel GC in its ability to manage system resources more efficiently.
G1 GC divides the heap into many small areas (regions), allowing for more flexible memory management. These regions can be of various types, including Eden, Survivor, and Old. G1 GC prioritizes garbage collection in those regions where it is most effective, based on the amount of garbage and the cost of cleaning it.
Like in CMS, G1 begins with a short Stop-The-World pause to mark root objects. This includes objects that are directly accessible from application threads, static objects, etc.
Z Garbage Collector (ZGC) and Shenandoah
Z Garbage Collector (ZGC) and Shenandoah are designed to minimize Stop-The-World (STW) pauses, which is a must-have for applications with low latency requirements.
ZGC
ZGC divides the heap into a set of small regions. This allows garbage collection in each region independently, reducing STW pause time. ZGC begins with a concurrent marking phase that occurs in parallel with application work, minimizing delays.
One of the key features of ZGC is its ability for concurrent object relocation. This means it can move objects while the application is running, reducing the need for long STW pauses.
Shenandoah
Shenandoah strives to minimize STW pauses required for certain garbage collection tasks. Shenandoah uses execution path barriers to track object access and movement, allowing the application to continue working during garbage collection.
Like ZGC, Shenandoah actively manages heap fragmentation, regularly compacting space for efficient memory allocation.
In conclusion, proper application of GC in JVM can significantly improve application performance, reduce latency, prevent memory leaks, and improve overall resource management. Ultimately, this leads to creating more reliable, efficient, and high-performance applications capable of meeting the most diverse requirements and operating conditions.
Please support my friend Irina! Irina is a great AI developer and the best Python engineer I've ever seen! https://buymeacoffee.com/techwithirina