table of Contents
One, the performance indicators of the garbage collector
Second, the comparison of various garbage collectors
Three, garbage collector introduction
3.3 Parallel Scavenge（ParallerGC）/Parallel Old
3.4 Concurrent Mark Sweep （CMS）
3.5.1 G1 heap management method
3.5.2 G1 new generation garbage collection
3.5.3 G1 old age garbage collection
3.6.1 Main realization technology
Today I will briefly introduce you to the garbage collector of Java. If you are not doing jvm development, you can basically understand its working principle. There is no need for in-depth research, and the general interview will not ask too deeply.
Different garbage collectors have different garbage collection algorithms, and the currently used garbage collector can be displayed through the jps -v command
Currently, more JVM collectors include Serial/Serial Old, ParNew, Parallel Scavenge (ParallerGC)/Parallel Old, Concurrent Mark Sweep (CMS), and G1 garbage collector.
One, the performance indicators of the garbage collector
The garbage collector is also divided into single-threaded and multi-threaded, but also divided into parallel and concurrent. The main performance indicators of the garbage collector are garbage collection throughput and garbage collection time.
- Parallel: the simultaneous multi-threaded garbage collection.
- Concurrency: Multi-threading of garbage collection and multi-threading of application are performed simultaneously.
Note: Throughput = running user code time / (running user code time + garbage collection time)
Garbage collection time = garbage collection frequency * single garbage collection time
Single thread collection process
Multithreaded collection process
Second, the comparison of various garbage collectors
| collector |
Collection objects and algorithms |
Collector type |
| Serial |
The new generation, replication algorithm |
Single thread |
| ParNew |
The new generation, replication algorithm |
Parallel multithreaded collector |
| Parallel Scavenge |
The new generation, replication algorithm |
Parallel multithreaded collector |
| Serial Old |
In the old age, tag sorting algorithm |
Single thread |
| Parallel Old |
In the old age, tag sorting algorithm |
Parallel multithreaded collector |
| CMS |
Old age, mark removal algorithm |
Parallel and concurrent collector |
| G1 |
Cross the new generation and the old generation; mark sorting + breaking up into parts |
Parallel and concurrent collector |
Three, garbage collector introduction
3.1 Serial/Serial Old
The oldest, single-threaded, exclusive, mature, suitable for single CPU servers
-XX:+UseSerialGC Serial collectors are used in both the young and old generations
-XX:+UseParNewGC The new generation uses ParNew, the old generation uses Serial Old
-XX:+UseParallelGC The new generation uses ParallerGC, the old generation uses Serial Old
3.2 ParNew
Basically the same as Serial, the only difference: multi-threaded, multi-CPU, and the pause time is less than that of Serial
-XX:+UseParNewGC The new generation uses ParNew, the old generation uses Serial Old
In addition to performance reasons, mainly because in addition to the Serial collector, only it can work with the CMS collector.
3.3 Parallel Scavenge（ParallerGC）/Parallel Old
For garbage collectors that focus on throughput, high throughput can efficiently use CPU time and complete program calculation tasks as soon as possible. It is mainly suitable for tasks that do not require too much interaction in the background.
The so-called throughput is the ratio of the time used by the CPU to run user code to the total time consumed by the CPU, that is, throughput=time to run user code/(time to run user code+garbage collection time). The virtual machine runs for 100 minutes in total, of which garbage The collection takes 1 minute, and the throughput efficiency is 99%.
3.4 Concurrent Mark Sweep （CMS）
The collector is a collector whose goal is to obtain the shortest recovery pause time. At present, a large part of Java applications are concentrated on the server side of Internet sites or B/S systems. This type of application pays particular attention to the response speed of the service and hopes that the system has the shortest pause time to bring a better experience to users. The CMS collector is very suitable for the needs of such applications.
The whole process is divided into 4 steps, including:
- Initial mark: just mark the objects that GC Roots can directly associate with. The speed is very fast and needs to be stopped (STW -Stop the world).
- Concurrent marking: Analyze the reachability of objects in the heap starting from the GC Root, and find surviving objects. It takes the longest time in the entire collection process and does not need to be paused.
- Re-marking: In order to correct the marking record of the part of the object whose marking is changed due to the continued operation of the user program during concurrent marking, a pause (STW) is required. The pause time in this phase is generally slightly longer than the initial marking phase, but much shorter than the concurrent marking time.
- Concurrent cleanup: no pause is required.
advantage:
Since the longest time-consuming concurrent marking and concurrent removal process collector threads in the entire process can work with user threads, in general, the memory recovery process of the CMS collector is executed concurrently with user threads.
Disadvantages:
CPU resource sensitivity: Because multiple threads occupy CPU resources in the concurrent phase, if the CPU resources are insufficient, the efficiency will be significantly reduced.
Floating garbage: Since the user thread is still running during the concurrent cleanup phase of the CMS, new garbage will continue to be generated as the program runs. This part of the garbage appears after the marking process, and the CMS cannot deal with them in the current collection. It will be cleaned up in the next GC. This part of garbage is called "floating garbage".
Due to the existence of floating garbage, it is necessary to reserve a part of the memory, which means that CMS collection cannot wait for the old generation to be full again like other collectors.
In the 1.6 version, the space usage threshold of the old generation (92%)
If the reserved memory is not enough to store floating garbage, Concurrent Mode Failure will occur, and the virtual machine will temporarily enable Serial Old instead of CMS.
Will generate space debris: mark-sweep algorithm will cause discontinuous space debris
3.5 G1
The G1 garbage collector is mainly aimed at machines with multiple processors and large memory. It meets the requirements of predicting GC pause time with a very high probability, and it also has high throughput performance characteristics. It is a garbage collector based on tag sorting.
3.5.1 G1 heap management method
The heap memory is divided into multiple logical heap areas of equal size, some of which are treated as the same role (eden, survivor, old) of the old generation collector, but the number of areas for each role is not fixed.
The size of each heap region is determined when the JVM is started. The JVM usually generates 2000 regions, and the size of each region is between 1M-32M. These Regions will be logically mapped into Eden, Survivor, and old generation spaces.
3.5.2 G1 new generation garbage collection
The surviving objects in the new generation are transferred to one or more Survivor areas. If the survival threshold is reached, these objects will be moved to the old elder area. During the recovery process, there will be a STW pause, and the Eden and Survivor sizes will be calculated for the next GC.
Before the new generation collection:
After the new generation collection ends: the new generation is transferred to the Survivor area or the old area, and garbage collection is performed in parallel.
3.5.3 G1 old age garbage collection
- Initial mark (STW)
In this stage, the G1 GC marks the root. This stage is closely related to conventional (STW) young generation garbage collection. - Root region scan (root region scan)
G1 GC scans the references to the old generation in the initially marked survival area and marks the referenced objects. This stage runs simultaneously with the application (non-STW), and only after this stage is completed, can the next STW young generation garbage collection begin. - Concurrent Marking
G1 GC looks for accessible (live) objects in the entire heap. This stage runs simultaneously with the application and can be interrupted by STW young generation garbage collection - Final Marking (Remark, STW)
This stage is STW recycling, helping to complete the marking cycle. G1 GC clears the SATB buffer, tracks the live objects that have not been accessed, and performs reference processing. - Cleanup (STW)
In this final stage, the G1 GC performs the STW operation of statistics and RSet purification. During the statistical period, G1 GC will identify completely free areas and areas available for mixed garbage collection. The cleanup phase is partially concurrent when resetting the blank area and returning to the free list.
3.6 ZGC
Java11 has launched the latest garbage collector, ZGC is mainly to reduce the JVM pause time.
The full name of ZGC is Z Garbage Collector, which is a scalable, low latency garbage, concurrent garbage collector designed to achieve the following goals:
- Pause time does not exceed 10ms
- The pause time does not increase with the size of the heap or the size of the live objects
- Can handle memory sizes ranging from hundreds of megabytes to several terabytes (maximum 4T)
3.6.1 Main realization technology
Pointer tagging Or Colored Pointers
ZGC uses several of the 64 bits of the pointer to represent Finalizable, Remapped, Marked1, and Marked0 to mark the storage state of the pointer to the memory. It is equivalent to marking the object information (not the object header) on the object reference. When the pointed memory changes (when the memory is moved in Compact finishing), the color will change.
- Marked0/marked1: Determine whether the object has been marked
- Remapped: Determine whether the application has pointed to the new address
- Finalizable: Determine whether the object can only be accessed by Finalizer
These bits in different states also represent the different colors of this reference
Why are there 2 marks? At the beginning of each GC cycle, the flag bits used will be exchanged to invalidate the marked state corrected in the last GC cycle, and all references become unmarked.
-
GC cycle 1: Use mark0, then all reference marks will become 01 at the end of the cycle.
-
GC cycle 2: Use mark1, the expected mark is 10, and all references can be remarked.
GC barriers (GC Barriers)
due to the existence of colored pointers, when the program is running to access the object, you can easily know the storage state of the object in the memory (accessing the object through the pointer), if the requested memory is colored, then Trigger the read barrier, the read barrier will update the pointer and then return the result, this process has a certain cost, so as to achieve the effect of concurrent with the user thread.
Compared with the traditional algorithm for marking objects, ZGC marks the pointer and adds Load Barrier (read barrier) when accessing the pointer. For example, when the object is being moved by the GC, the color on the pointer will be wrong, and the barrier will be The pointer is updated to a valid address and then returned, that is, there is always a probability of being slowed down when only a single object is read, and there is no rough overall Stop The World in order to keep the application consistent with the GC.
3.6.2 Principle of ZGC
Logically last time ZGC is divided into three stages: Mark (mark), Relocate (migration), and Remap (remap)
- Mark: All live objects are recorded in the Livemap (live object table, bitmap implementation) of the corresponding Page, and the Reference of the object is changed to the marked (Marked0 or Marked1) state
- Relocate: A group of Pages selected according to the size of the live objects in the page, copy all the live objects to the new Page, and record the correspondence between the original address of the object and the new address in an additional forward table (transfer table)
- Remap: All references to the Relocated live objects are repointed to the new correct address
In terms of implementation, since you want to correct all references, you need to traverse the entire object graph like the Mark phase, so this time Remap will be merged with the next Remark phase. Therefore, there are two stages in the implementation of GC, namely the Mark&Remap stage and the Relocate stage
Marking
a first portion GC cycle is marked. Marking includes finding and marking all heap objects accessible to the running application, in other words, finding objects that are not garbage.
ZGC marking is divided into three stages.
The first stage is STW, where GC roots are marked as live objects. GC roots are similar to local variables, through which other objects on the heap can be accessed. If an object cannot be accessed by traversing the object graph starting from roots, then the application cannot access it, and the object is considered garbage. The collection of objects accessed from roots is called the Live collection. The GC roots marking step is very short, because the total number of roots is usually small.
After this phase is completed, the application resumes execution, and ZGC starts the next phase, which simultaneously traverses the object graph and marks all accessible objects. During this phase, the read barrier needle tests all loaded references with a mask, which determines whether they are marked or unmarked, and if the references have not been marked, they are added to the queue for marking.
After the traversal is completed, there is a final, short-time Stop The World phase, which handles some edge cases (we will ignore it for now), and the marking phase is completed after this phase is completed.
The next major part of the relocation GC cycle is relocation. Relocation involves moving live objects to free up part of the heap memory. Why move objects instead of filling in gaps? Some GCs actually do this, but it has the unfortunate consequence that allocating memory becomes more expensive, because when memory needs to be allocated, the memory allocator needs to find free space where objects can be placed. In contrast, if a large block of memory can be released, then allocating memory is simple, just increment the pointer by the amount of memory required by the new object.
ZGC divides the heap into many pages. At the beginning of this phase, it selects a set of pages that need to relocate the active objects. After selecting the relocation set, a Stop The World will appear, where ZGC relocates the root objects in the set and maps their references to the new location. As with the previous Stop The World step, the pause time involved here depends only on the number of roots and the ratio of the size of the relocation set to the total active set of the object, which is usually quite small. So unlike many collectors, the pause time increases as the heap increases.
After moving root, the next stage is concurrent relocation. At this stage, the GC thread traverses the relocation set and relocates all objects in the pages it contains. If the application thread tries to load the object before the GC relocates it, then the application thread can also relocate the object. This can be achieved through a read barrier (triggered when a reference is loaded from the heap), which ensures that the application sees everything The references have been updated, and it is impossible for the application to operate on the relocated objects at the same time.
The GC thread will eventually relocate all objects in the relocation set, but there may still be references to the old locations of these objects. GC can traverse the object graph and remap these references to new locations, but this step is expensive. So this step is merged with the next marking phase. When traversing the object object graph during the marking phase of the next GC cycle, if an unremapped reference is found, it is remapped and then marked as active.
The garbage collector talks about this for the time being, and I will introduce you to the actual JVM optimization later.