[Java Performance] Introduction to Java Garbage collection

This series is a reading note for the Java Performance:the Definitive guide.
Overview

In the current JVM, there are mainly 4 garbage collector (garbage Collector):

• Serial recycler (Serial Collector), primarily for single-core computers
• Throughput (parallel) collector (Throughput/parallel Collector)
• Concurrency collector (concurrent/cms Collector)
• G1 Recycle Collector

Their performance characteristics vary, and are described in the next chapter. But they have some common principles and concepts, and this chapter is to explain the basics of garbage collection.

In short, the GC's task is to find objects that are no longer in use, and then release the memory they occupy. Typically, the JVM finds that they can be recycled by looking for objects that are no longer referenced. Therefore, it also means that all references to objects are saved through a counter. But it is not enough to simply use this reference count. For example, in the case of circular references, all objects will be referenced, but not actually used.

Therefore, the JVM must periodically search for heap memory to discover objects that are not in use, then reclaim them and release the memory they occupy. However, just releasing is not enough, which can result in a lot of memory fragmentation (fragmentation), so the JVM also needs to rearrange the location (compacting) of other objects in memory to eliminate those fragments.

Although the GC implementations vary and have a lot of detail, the performance of the GC depends primarily on the actions mentioned above:

• Search for objects that are not being used
• Release the memory they occupy
• Compressed heap (compacting the heap)

If the application's threads do not run while the GC is running, things can be a lot simpler. However, it is unlikely that Java applications will typically use many threads, so when the GC participates in the process, all threads can be divided into two groups:

• Application Threads
• GC Thread

When GC threads are working, because they make adjustments in-memory objects that are used by application threads, it is important to ensure that the GC thread is working, and that the application threads stop their current work. This stop is also called Stop-the-world stop, which can have a serious impact on the performance of the application, so it is critical to reduce the time to stop when tuning the GC.

Generation-based garbage collector (generational garbage collectors)

Although the GC implementations vary, they divide the heap memory into several generations. Each of them is:

• Old generation (old/tenured Generation)
• New Generation (young Generation)
  • Eden Space
  • Survivor Space

The reason for dividing memory is that, during a short period of time when the program is running, many objects may be created, used, and discarded, such as:

sum = New BigDecimal(0); for (StockPrice SP : Prices.Values()) {    BigDecimal diff = SP.Getclosingprice().Subtract(Averageprice);    diff = diff.Multiply(diff);    sum = sum.Add(diff);}

Because BigDecimal is an immutable type (immutable Class) in Java, several new BigDecimal objects are created in each cycle of the above to complete the calculation. The life cycle of these objects is very short, and immediately after the end of a cycle, it becomes a candidate for GC to be recycled.

This behavior is common in Java applications, where all newly created objects are first assigned to the Cenozoic memory area. When the Cenozoic memory area is fully occupied, the GC stops all application threads and then attempts to reclaim the Cenozoic region:

• Memory of unused objects is freed
• Objects that are still in use will be moved to another place.

This process is known as Minor GC.

Two benefits of using this design:

• The Cenozoic is only part of the entire heap memory area, so processing the region is faster and the impact on the application is smaller (because the GC works, which can cause the application to pause), but you may also notice that it causes the application to be stopped frequently because the GC is more frequent, A discussion will be made later in this article.
• Because the newly created object is allocated to Eden Space in the Cenozoic region, it accounts for most of the Cenozoic region. When the GC recycles the area, the object is either recycled or moved to a survivor Space or moved to an old Generation, which guarantees that Eden Space will be emptied when the GC is completed. It also eliminates the compacting link.

All GC algorithms will stop all application threads (Stop-the-world Pause) when recovering the Cenozoic memory area.

As the object is moved to the old Generation, the area is eventually filled. At this point the JVM needs to recycle the zone, and the implementation of the different GC algorithms varies greatly. The simplest algorithm stops all application threads, completing the three steps of recycling (looking for no objects, freeing up memory, compressing memory). This process is called full GC. It usually causes the application to stop for a longer period of time.

On the other hand, in the process of looking for a non-object, you can also implement not stopping the application thread: The CMS and the G1 collector can do it. This is also why they are referred to as the concurrent collector. At the same time, they use different algorithms when compressing old generation. However, using concurrent recyclers consumes more CPU resources because they are more complex to compute. In some scenarios, the CMS and G1 also cause the application to stop for a long time and need tuning to avoid this when using them.

Some suggestions for GC selection

• Server program: Concurrency Collector or throughput collector
• Batch program: Use the concurrent collector when CPU resources are not bottlenecks, which can cause performance degradation

Summary

1. All GC algorithms divide the heap memory into young Generation and old Generation.
2. All GC algorithms will have a stop-the-world pause when recovering young generation, but the process of recovering young generation is very rapid.

GC Algorithmserial collector (Serial garbage Collector)

It is the simplest of the four types of recyclers that are used by default when an app is running on a client-level computer (using a 32-bit JVM for Windows or a single processor).

It uses a thread to complete the heap processing, which will cause the application to stop, regardless of whether the minor GC or full GC. In the full GC, the entire old generation is compressed.

You can use: -XX:+UseSerialGC to use it (note that in many cases, it is the default choice).

Throughput Collector

It is the default choice for server-level computers (multicore UNIX and using 64-bit JVMs).

It uses multiple threads to reclaim young Generation, so the minor GC is faster than the serial collector. For old Generation, it can also take advantage of multiple threads for recycling, which is the default behavior for JDK 7u4 and later versions. Of course, before JDK 7u4, you can also -XX:+UseParallelOldGC enable this feature by:. Because it uses multiple threads, it is also called a parallel collector.

As with the serial collector, when minor GC and full GC, it also pauses all application threads and completes the compression of the entire old generation when it is complete.

To enable it, use:-XX:+UseParallelGC

CMS garbage collector

The CMS Collector is designed to address the long pause caused by the serial and throughput collector in full GC. Although the CMS collector also causes all application threads to be paused when recovering young generation, it uses different algorithms to recycle young generation.

The CMS uses one or more background threads to periodically scan the old generation to reclaim unused objects, so it does not need to stop the application thread. However, because of the presence of a background thread, the CMS increases the load on the CPU and the background thread does not compress the heap.

When there is insufficient CPU resources available or too much fragmentation in the heap memory, the CMS will resort to the serial collector, which stops all application threads, performs garbage collection, and completes the heap memory compression. Finally, the CMS will start the background thread and restore its original algorithm.

If you enable the CMS collector, use: -XX:+UseConcMarkSweepGC ,-XX:+UseParNewGC

G1 Recycle collector

The G1 Collector is designed for scenarios where heap memory is larger than 4GB, so it is better suited for server-side applications. It divides the heap memory into several areas, some of which contain young Generation. There will still be Stop-the-world Pause for the collection of young generation. Similar to the CMS collector, it also uses several background threads for recycling.

The difference is that because G1 divides the heap memory into areas, when the full GC is performed, it moves objects within one region to another to complete cleanup, as if the objects in Eden Space are moved to a survivor when the minor GC is in progress. Space or old generation, the benefit of doing so is to omit the compacting steps.

Similarly, using G1 brings additional CPU load, which can be enabled using: -XX:+UseG1GC .

about explicitly triggering garbage collection

First, it is concluded that explicitly triggering garbage collection operations is not recommended under normal circumstances.

A full GC operation can be explicitly triggered by a call in the program System.gc() . This usually does not lead to any performance improvement, because when it is called, it is quite possible that the moment is not a good time for a GC.

Of course, there are exceptions. An explicit GC may be needed when the program needs to be benchmarking, or when the memory is dumping.

In addition, you can -XX:+DisableExplicitGC suppress the explicit triggering of GC by:.

Summary

1. When there is only one available CPU, it is more appropriate to use a serial collector. Because the other GC will start multiple threads.
2. Note When using a different JVM version and OS version, the default GC is the serial and throughput recycler, and the JVM Flags are required to use the CMS or G1.
3. CMS and G1 require additional CPU resources to run background threads that periodically recycle old generation to minimize full GC.

[Java Performance] Introduction to Java Garbage collection