preface

In the previous article, about three different kinds of garbage collection algorithms and their respective advantages and disadvantages, also analyzed the key points in garbage collection algorithm is useless objects, how to determine an object at the same time, for a variety of different reference for the analysis of the different from this article about different kinds of garbage collector for the realization of the garbage collection algorithms

Garbage collector

There are about 10 different types of garbage collectors in the market, as shown below:

According to the different areas of action, it can be divided as follows:

1. Serial, ParNew, Parallel for the younger generation
2. CMS, Serial Old, Parallel Old
3. In the case of G1 and the garbage collector after G1, it is a mixed collection

Although there are so many garbage collector, but until now, there is still no the best garbage collector, more no universal garbage collector, otherwise you also won’t appear so much garbage collector, we need to do is according to the specific scene, select the appropriate garbage collector, then the first to look at the old Serial collector.

Serial collector

Serial collector Serial collector is the most basic and oldest garbage collector, as you can tell from the name, this is a Serial collector, that is, a single-threaded collector

Serial Old collector

Serial Old is an older version of the Serial collector, which is also a single-threaded collector using a mark-collation algorithm. It may be used in JDK 5 and earlier as a companion to the Parallel Scavenge collector, or as a fallback in the event of a Concurrent Mode Failure in a Concurrent collection.

The characteristics of the Serial

• Only one garbage collection thread is used to complete the garbage collection
• While garbage collection is in progress, all other worker threads must be paused to stop the world until its collection is complete.
• The new generation/young generation adopts mark-copy algorithm, and the old generation adopts mark-collation algorithm.

The shortcoming of Serial

The biggest drawback is bad user experience, due to stop the world mechanism, the GC thread recycle the task is initiated by the virtual machine in the background automatically and automatically, unpredictable and uncontrollable on all the threads in the user’s normal work stopped, it is not acceptable for many applications.

Imagine if your computer stopped responding for five minutes every hour.

The advantages of the Serial

Serial not only has disadvantages, it has advantages over other collectors in that it is simple and efficient (compared to single-threaded collectors), and it consumes the least extra memory of all collectors for memory-constrained environments;

For single-core processors or environments with a small number of processor cores, the Serial collector can achieve maximum single-thread collection efficiency by focusing on garbage collection because there is no overhead of thread interaction.

JVM Settings

• -xx :+UseSerialGC
• -xx :+UseSerialOldGC(old age)

ParNew collector

Because of the poor user experience caused by the stop the world mechanism, the most direct direction to reduce the stop the world time is to change the single-thread to multi-thread GC, so take a look at its evolution -ParNew collector

As you can see from the above figure, the ParNew collector used multi-threaded parallel collection to do garbage collection in the new generation, but it was single-threaded in the old generation

As the number of CPU cores increases, the presence of ParNew is beneficial. By default, it enables the same number of garbage collection threads as the number of processor cores, and you can limit the number of garbage collection threads using the -xx :ParallelGCThreads parameter.

Parnew collector characteristics

• The new generation uses multi-threaded parallel collection to complete garbage collection
• While garbage collection is in progress, all other worker threads must be paused to stop the world until its collection is complete.
• The new generation/young generation adopts mark-copy algorithm, and the old generation adopts mark-collation algorithm

Aside from the support for multithreaded parallel collection, the ParNew collector does not offer much innovation over the Serial collector

JVM Settings

-XX:+UseParNewGC

Parallel avenge

The Parallel Avenge avenge is superficially similar to ParNew, but the focus of the collector is different from the other garbage collectors, the focus is on throughput (efficient CPU utilization), whereas garbage collectors such as CMS focus more on downtime of user threads (improved user experience)

Parallel Old collector

Parallel Old is an older version of the Parallel Avenge collector, supported by multiple threads for concurrent collection and implemented on a mark-collation algorithm. The Parallel Avenge collector was developed to be superior to the Insane and the Parallel Avenge collector. The Application of the Parallel Avenge collector was based on the application of the Parallel Avenge collector. JDK 8 uses this combination by default

The Parallel Exploiter

• The new generation/young generation adopts mark-copy algorithm, and the old generation adopts mark-collation algorithm
• Controls the maximum garbage collection pause time- XX: MaxGCPauseMillis parameters
• Set the throughput size directly:- XX: GCTimeRatio parameters
• Adaptive adjustment strategies:- XX: + UseAdaptiveSizePolicy parameters

-xx :MaxGCPauseMillis: The allowed value is a number of milliseconds greater than 0. The collector will do its best to ensure that memory reclamation does not take longer than the user set value. It is important to note that the garbage collection pause time is shortened at the expense of throughput and new generation space. The system reduces the STW time, which means that garbage collection occurs more frequently, instead of 100 ms pauses every 10 seconds, garbage collection now occurs every 5 seconds and 70 ms pauses. Pause times did go down, but so did throughput

-xx :GCTimeRat IO: The allowed value is an integer between 0 and 100, that is, the ratio of garbage collection time to total time, which is equivalent to the reciprocal of throughput. For example, if this parameter is set to 19, the maximum allowed garbage collection time is 5% of the total time (i.e. 1/(1+19)). The default is 99, which is the maximum allowed garbage collection time of 1%(i.e. 1/(1+99)).

– XX: + UseAdaptiveSizePolicy: After setting, don’t need to specify the size of the new generation (Xmn), Eden and Survivor area ratio (- XX: SurvivorRatio) object size, promotion old s (- XX: PretenureSizeThreshold) parameters such as the, The vm collects performance monitoring information based on the current operating status of the system and dynamically adjusts these parameters to provide the most appropriate pause time or maximum throughput.

The Parallel Exploiter under JDK 8

Open the terminal, enter Java -xx :+PrintCommandLineFlags -version, and press Enter:

It was found that -xx :+UseParallelGC was used, but since JDK7u4, improvements have been made to the default old collector -xx :+UseParallelGC, so that when HotSpot VM selects -xx :+UseParallelGC, -xx :+UseParallelOldGC will be enabled by default, so the default collector is ParallelOld.

The default option in JDK8 is -xx :+UseParallelGC, which is the Parallel Insane +Parallel Old combination.

Document the source

1. Openjdk Settings for Parallel_GC

2. Openjdk optimizations for Parallel_GC

JVM Settings

• -xx :+UseParallelGC(young generation)
• -xx :+UseParallelOldGC

CMS garbage collector

The CMS (Concurrent Mark Sweep) collector is a collector whose goal is to obtain the shortest collection pause time. It is perfectly suited for use in ux focused applications. It was the first truly concurrent collector for the HotSpot VIRTUAL machine, and it was the first time that garbage collection threads worked (basically) at the same time as user threads.

As can be inferred from the name Mark Sweep, it is the implementation of the mark-sweep algorithm, and its operation process is more complex than the above garbage collectors. The whole process can be divided into the following four steps:

• Initial flag: Pause all other threads to stop the world and write down objects referenced directly by GC Roots, very fast.

• Concurrent marking: The concurrent marking phase is the process of traversing the entire object chain from the directly associated object of GC Roots. This process is long, but does not require the user thread to be paused and can be run concurrently with the garbage collection thread. As the user program continues to execute, it may cause the state of the marked object to change.

• Relabelling: The relabelling phase is used to correct the record of the part of the object whose markup changed during concurrent labeling because the user thread continued to run. The pause time in this phase is generally slightly longer than in the initial tagging phase and much shorter than in the concurrent tagging phase. The main use of tricolor markup in the incremental update algorithm (see the details below) for re-marking.

• Concurrent cleanup: The user thread is started and the GC thread begins to clean the unmarked area. If any new objects are added to this stage, they will be marked as black, and no processing will be done. See below for details on the three-color marking algorithm

• Concurrent reset: Resets the marked data during this GC.

Process analytical

1. In the initial tag, GC Roots’ direct reference object is recorded. Note that it is a direct reference object, not all objects in the reference chain, such as User User = new User(), only the new User object is recorded, and the object dependent on User object is not recorded. It is also necessary to stop the world at the initial tag step, because if the user thread is constantly executing and new GC Roots are generated, the initial tag cannot be completed.

2. In the concurrent tag, instead of executing Stop the world, the GC thread and the user thread execute concurrently

3. In re-marking, stop the world is performed, but this step takes much less time than the second step of concurrent marking, because it does not need to find the object reference chain, and its implementation of the tricolor is described in more detail below

4. In concurrent cleanup, unmarked objects are cleared, but stop the world is not implemented in this step. Since the GC garbage collection thread and the user thread are executing in parallel, new objects may be generated during this step, and the CMS will mark these incremental objects directly in black. This black color will also be covered in detail in the tricolor markers that will be introduced later

There is nostop the worldThe first question that comes up

CMS garbage collector does not implement stop the world mechanism for the two steps of concurrent marking and concurrent cleaning, especially after the completion of concurrent marking, due to the execution of the user program, many objects’ states actually change, and the objects originally referenced by GC Roots, There are no GC Roots references/garbage objects that were resurrected and are not garbage objects anymore. Changing the state of an object reference is a very uncontrollable behavior for the JVM, and also introduces a second problem

There is nostop the worldBrings up the second question

During the concurrent marking and concurrent cleaning phases, the user thread is still running, and new garbage objects are naturally generated. However, this part of garbage objects is generated after the marking process, and the CMS cannot deal with them in the current collection, so it has to be cleaned up in the next garbage collection. This part of the garbage is called floating garbage.

Concurrent Mode Failure occurs when a CMS GC is overloaded and the last GC has not yet finished. The JVM then starts a backup: temporarily enable the Serial Old collector to restart the Old garbage collection. The Serial Old collector executes STW, resulting in long pause times.

So parameters – XX: CMSInitiatingOccupancyFraction set too high will be very easy to cause a lot of concurrent failures, performance is reduced, the user should be in a production environment according to the actual application situation to balance Settings.

Why would a CMS implement it this way? In fact, all of this is for the user experience, because if the heap is large, then once stop the world happens, the user will pause for a long time, which is very unfriendly to user threads

Parallel between CMSLove that kill

Comparison shows that Parallel stops the world during GC, but CMS divides the whole GC collection process into five steps, in order to reduce the time of stop the world. According to empirical statistics, the time spent in the step of concurrent marking for object reference link is spent. It takes up 80% of the whole GC time, so CMS does not implement the stop the World mechanism at this step, and splits stop the World into two other steps that are relatively time-consuming. In this way, the user experience will be one stop at a time, rather than directly pulling the brake, which greatly improves the user experience. Especially in the case of large heap memory

But here’s the important thing: This is not to say that CMS is better than Parallel collector, since CMS collector also allows the user thread and the COLLECTOR thread to execute concurrently during the GC process, thus increasing the GC collection time (CPU resources are divided by the user thread). Parallel collector has a stop the world mechanism. The COLLECTOR thread can consume a significant amount of CPU time, so the Parallel collector’s GC time is shorter than the CMS collector’s GC time, so the CMS is sacrificing the GC time for the user experience

The Parallel collector is used by JDK 8 as the default. The Parallel collector is used by JDK 8 as the default. The Parallel collector is used by JDK 8 as the default

There is no single best garbage collector, and there is no universal garbage collector. What we need to do is to choose the appropriate garbage collector according to the specific scenario

Advantages and disadvantages of CMS

• Advantages:

1. Concurrent collection
2. Low pause

• Disadvantages:

1. It is sensitive to CPU resources and will compete with the server for resources, which means GC takes a long time
2. Floating garbage cannot be handled, which is garbage objects that are generated during the concurrent marking and concurrent cleanup phases and can only be collected by the next GC
3. Since it is using a tag – clear algorithm, it can lead to after the collection, will produce a lot of memory, casually for subsequent object storage, of course, you can use – XX: + UseCMSCompactAtFullCollection allows the JVM after the execution of the mark – clear, do it again.
4. Uncertainty in the execution process, there will be the last garbage collection is not completed, and then garbage collection will be triggered again, especially in the time-consuming concurrent marking and concurrent cleaning phase, while collecting, while the program continues to execute, may not complete the execution of Full GC. Concurrent Model failure, at which point stop the world is collected by the Serial Old garbage collector

Set core parameters of the CMS

1. Enable CMS: -xx :+UseConcMarkSweepGC

2. Set the number of concurrent GC threads to -xx :ConcGCThreads

3. FullGC do compression after finishing, which is used to reduce memory fragments: – XX: + UseCMSCompactAtFullCollection

4. Full set how much time the GC compression after finishing time, the default is 0, that after every FullGC compression: – XX: CMSFullGCsBeforeCompaction

5. Full GC will be triggered when this percentage is reached by older generations. The default is 92. Note that this is a percentage, leaving 8% space to avoid concurrent model failure. -XX:CMSInitiatingOccupancyFraction

6. Only use setting threshold – XX: CMSInitiatingOccupancyFraction Settings, if not specified, then the JVM only used for the first time set data, follow-up will automatically adjust, such as, triggered a concurrent model failure, The JVM will adjust the proportion of the value is small, if you don’t trigger the concurrent model failure, then the JVM will turn this value: – XX: + UseCMSInitiatingOccupancyOnly

7. Start a Minor GC before the GC to reduce references to the younger generation and reduce the overhead of the tag phase. Generally, CMS GC takes 80% of the time in the concurrent tag phase. During the concurrent tag phase, it is very likely that objects in the older generation will rely on objects in the younger generation, known as cross-generation references. If you’re going to have to find references across generations to make concurrent tags, and the new generation object is probably garbage, then there’s no need to mark it again, so start a Minor GC before GC: -xx :+CMSScavengeBeforeRemark

8. Said at the time of initial tag multithreaded execution, shorten the STW: – XX: + CMSParallelInitialMarkEnabled

9. Multi-threaded execution during re-marking, shorten the STW: -xx :+ CMSPARallelEnabled

Example of setting CMS parameters

Memory space Settings

Suppose there is a server with 8GB of memory, and the normal JVM parameters are as follows:

java -Xms3072M -Xmx3072M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio = 8
Copy the code

-xx :SurvivorRatio = 8, this parameter makes the memory size ratio of Eden and survivor1 and survivor2 in the new generation 8:1:1, if -xx :SurvivorRatio = 4 then 4:1:1

Operation process

• In practice, objects generated in the first 13 seconds can be placed in Eden. However, when the order is executed at the 14th second, THE JVM finds that Eden is already full, so it STW (Stop the world) and MinorGC
• At this time, the object generated at 14s has not been removed from the stack, so the object is still in the heap and cannot be reclaimed. Therefore, the 60M object generated at 14s will try to be placed in the survivor zone. The generation age is set to 1. So objects with survivor ages greater than or equal to 1 are moved to the old age by which time the Minor GC has completed

Due to the dynamic object age determination mechanism, allocating memory in this way can lead to frequent Full GC, so we need to update our JVM parameters to increase the Survivor region

java -Xms3072M -Xmx3072M -Xmn2048M Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio = 8
Copy the code

Thus reducing the because object dynamic age judgment mechanism and cause of frequent into the problem of old age, a lot of optimization is nothing but let short-lived objects in survivor zone as far as possible, don’t go into old age, such a Minor GC, these objects will be recycled, won’t wait for Full GC into old age.

Object dynamic age setting

For the age of the object should enter the old age, according to the real business scene to make a judgment, from the above cases:

In this example, the MinorGC interval is about 15S, and most objects become garbage in a few seconds. It is possible to change the dynamic age value to a smaller value, such as 3. If most objects become garbage in 5s, 15/5=3. So that means that it’s going to take 3 MinorGC’s for the object to get to the old age, which is close to 1 minute. The time between 3 MinorGC’s + the MinorGC execution time + the time it takes to move to the old age. If the object hasn’t been collected for that long, It is safe to assume that these objects are long-lived objects that can be moved to older ages rather than occupying memory in Survivor regions.

Large object Settings

For large objects directly into the old age, this can be combined with their own system to see if there are any large objects generated, estimate the size of large objects, generally set to 1M (experience) about the same, these objects are generally allocated by the system initialization cache objects such as large cache List, Map, etc.

The final result

java -Xms3072M -Xmx3072M -Xmn2048M Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio = 8 -XX:MaxTenuringThreshold=3 -XX:PretenureSizeThreshold=1M
Copy the code

CMS Parameter Settings

-xx :+UseParallelOldGC(-xx :+UseParallelOldGC); -xx :+UseParallelOldGC(-xx :+UseParallelOldGC); With a clear sense of this, we can use ParNew + CMS(-xx :+UseParNewGC -xx :+UseConcMarkSweepGC) to optimize

Large object Settings

We can go back to the old objects themselves and start analyzing what objects have not been collected after three MinorGC runs, just some cache objects, objects in the Spring container, thread pool objects, etc., which may not add up to 100 megabytes. In this case, analyze the size of cache objects, Spring container objects, thread pool objects, and so on

Here’s another case: For example, the second kill business may exceed our expectation in an instant, and we may have to process 500-600 orders per second, so the objects generated per second may exceed 60M. Coupled with the surge of system pressure, the processing time of an order may be extended, and the objects generated per unit time will become larger. Therefore, for the second kill scenario, It is possible that the original estimate of 60 meters will become more than 100 meters.

Set the CMS compression frequency

Assuming that this happens every 5-6 minutes, it is possible to trigger a Full GC every hour or so because the old age is Full. The condition for triggering a Full GC also includes the old age space allocation guarantee mechanism. So it’s almost impossible to have a Full GC due to a failure of the old age space allocation guarantee before a Minor GC is triggered, and it’s perfectly acceptable to have a Full GC happen every half hour to an hour, because a split-kill might last for 10-20 minutes, followed by a Full GC for hours or days

Defragmentation about CMS

Since the Full GC is performed every 30 to 1 hour, it is possible to perform defragmentation after each Full GC, but if the seckill time is long, we can adjust defragmentation after multiple Full GC, using 3 as an example

Set the results

java -Xms3072M -Xmx3072M -Xmn2048M Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio = 8 -XX:MaxTenuringThreshold=3 -XX:PretenureSizeThreshold=1M -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=92 -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=3
Copy the code

Support the low pause weapon – tricolour mark

The CMS garbage collector is known for its low pauses, which, according to the CMS running process, are made parallel in the concurrent marking, concurrent collection phase, without the STW, but this also introduces a problem:

• The state of an object can easily change due to the execution of a user program. An object referenced by GC Roots is now not referenced by GC Roots

To solve this problem, the JVM introduced a solution called tricolor tagging

Three color tag

During concurrent tagging, references between objects are likely to change as the application thread continues to run during tagging, which can be roughly divided into multiple tagging and missed tagging scenarios

• Multimark: In the concurrent marking phase, a GC Roots reference chain is marked, but the user thread is not stopped. When the method ends, the chain of objects may be full of garbage objects called floating garbage. This is called multimark

The multi-label situation is fine, but there are some floating garbage objects, at most until the next GC, these garbage objects will still be collected. Also: For new objects created after the concurrent marking starts, it is common practice to mark them all in black and this round will not clear them. This part of the object may also become garbage in the meantime, which is also part of the floating garbage

• In the concurrent marking phase, the scanned object has a new reference and cannot be scanned

The JVM introduces a tricolor labeling algorithm to solve this problem. It uses the reachability analysis algorithm to find the object chain referenced by GC Roots and marks it in the following three colors based on whether the condition has been accessed:

1. Black: Indicates that the object has been accessed by the garbage collector and that all references to the object have been scanned. The black object indicates that it has been scanned, it is safe to live, and there is no need to scan again if other object references point to the object. A black object cannot point directly to a white object (without passing the gray object)

2. Gray: Indicates that the object has been accessed by the garbage collector, but at least one reference to the object has not been scanned

3. White: indicates that the object has not been accessed by the garbage collector. It is clear that at the beginning of the reachability analysis, all objects are white. If at the end of the analysis, all objects are still white, that is, they are unreachable.

Tricolor marking process

The flow chart is shown above, with an example to take a closer look at the three-color marker:

package jvm;

public class ThreeColorRemark {
    public static void main(String[] args) {
        Test_A testA = new Test_A();
        // Start marking concurrency
        / / read
        Test_D testD = testA.testB.testD;
        / / write
        testA.testB.testD = null;
        / / writetestA.testD = testD; }}class Test_A {
    Test_B testB = new Test_B();
    Test_D testD = null;
}
class Test_B {
    Test_C testC = new Test_C();
    Test_D testD = new Test_D();
}
class Test_C {}class Test_D {}Copy the code

1. Start with the initial markup, because testA is directly marked black because it is a reference to GC Roots

2. At the stage of concurrent marking, we searched for the reference chain of the object according to the reachability analysis algorithm. When scanning testB, we found that it depended on testC object and testD object. At this time, we began to scan testC object and found that it existed and had no dependency, so we marked testC object as black

3. The testD object has not been scanned yet, so it is still white, and the testB object is marked gray because it has been accessed by the garbage collector, but the testD object it depends on has not yet been accessed

4. If an object is still marked white during concurrent collection, it is garbage and can be collected

How does tricolor mark solve missing mark scene

For example, in the main method above, there are several lines of code:

// Start marking concurrency
/ / read
Test_D testD = testA.testB.testD;
/ / write
testA.testB.testD = null;
/ / write
testA.testD = testD;
Copy the code

When testA objects are initialized, the member variable testD is null, and the testA objects are marked black during the initial marking phase. When the program is running, we set the dependent testD reference in the testB object to NULL and the testD reference in the testA object to the object referred to by the testD reference in the original testB object, as shown in the following figure

But testA has already been marked, that is, it cannot be scanned again, so the testD object that it depends on cannot be marked, and it is not the object that GC Roots points to, so there will be a missing mark scene. When the concurrent marking ends, testD must be white and judged as a garbage object. But the testD object is not a garbage object, so there are serious garbage collection bugs

The solution

Wilson theoretically proved in 1994 that the problem of missing label can occur if and only if the following two conditions are met simultaneously, that is, an object that should be black is mislabeled as white:

• Insert one or more new references from the black object to the white object, in this case setting the testD reference in the testA object to the object pointed to by the testD reference in the original testB object

• Delete all direct or indirect references from the grey object to the white object, in this case setting the testD reference dependent on the testB object to NULL

Missing marks will cause the referenced object to be deleted as a garbage object. There are two solutions:

1. Incremental Update
2. Snapshot At The Begining, STAB

Incremental updates are for additions, and original snapshots are for deletions

Incremental update: When a black object inserts a new reference to a white object, the newly inserted reference is recorded. After the end of the concurrent marking, the re-marking phase will stop the world and rescan the black object in these recorded reference relationships

Original snapshot: Object to be deleted when the gray to white object reference relations, will delete the reference relationship, at the end of the concurrent tags until the mark phase, will stop the world to tell these records have a reference to the relationship between the grey object as the root, to scan again, so you can scan to white object, The purpose of marking these white objects as black objects is to allow them to be stored in the current GC and rescan in the next GC, which may also be floating garbage

JVMS record operations, whether inserts or deletes, through write barriers. STAB is the pre-write barrier and incremental updates are the post-write barrier.

Write barriersNote: This is pseudocode

Suppose the underlying code looks like this when assigning a value to a member variable of an object

void field_store(oop* field, oop new_value) {
   // Assign
   *field = new_value;
}
Copy the code

Write barriers add some processing before and after the assignment, similar to AOP

void field_store(oop* field, oop new_value) {
   // before the assignment
   pre_write((oop*)field);
   // Assign
   *field = new_value;
   // After the assignment
   after_write(new_value);
}
Copy the code

Write barriers implement SATB

When a member variable of testB changes, for example, when a reference disappears testA.testb. TestD = null, write barriers can be used to record the original reference testD of testB

void pre_write(oop* field) {
   // Get the old value
   oop old_value = (oop*) field;
   // Record the old value
   remark_set.add(old_value);
}
Copy the code

Write barriers implement incremental updates

When A member variable of object testA changes, for example, referencing A new testa. testD = testD, write barriers can be used to record the new member variable of object A, testD

void after_write(oop new_value) {
   // Record the new value
   remark_map.add(new_value);
}
Copy the code

Summary of tricolor marking algorithm

Accessibility of modern-style tracking algorithm of the garbage collector, almost all learning algorithm from three color marker, although implementation may be different, such as: white/black collection generally won’t appear, but there are other reflected color, gray collection can manifest itself through the stack, queue, traversal method can be breadth traversal/depth, etc

For read/write barriers, using Java HotSpot VM as an example, it misses the mark handling when marking concurrently:

• CMS: Write barriers + incremental updates
• G1, Shenandoah:Write barriers + SATB
• ZGC:Read barrier

Read/write barriers can be used to record changes in references across generations/extents, read barriers can be used to support concurrent execution of moving objects, etc. In addition to these features, there are performance considerations, and each garbage collector has its own ideas.

This paper summarizes

Ok, that’s all the content of this article, around various garbage collectors, focusing on CMS. In the next article, G1 and ZGC are developed on the basis of CMS, so we have to understand the mechanism of CMS before we can look at G1 and ZGC. In this article, We also went through the following steps

1. Phase 1: Introduces the various garbage collectors and their features and pros and cons
2. The second stage: the CMS is carried out in detail to introduce the mechanism and parameter tuning configuration
3. Stage 3: talk about the three-color markup algorithm that underpins CMS pauses

There are two garbage collector is very important not to speak, is the G1, ZGC, on the one hand is for the use of the company or the JDK 8, on the other hand also has the space relationship, if here, too much information at once, so I’m going to put in the next article, to analyze the G1 and ZGC, can look forward to!!!

omg

Finally, if you feel confused about the article, please leave a comment immediately. If you think I have something to ask for a thumbs up 👍 for attention ❤️ for share 👥 is really very useful for me!! If you want to get massive Java resources easy to use IDEA plug-ins, resume templates, design patterns, multi-threading, architecture, programming style, middleware…… , can pay attention to the micro channel public number Java encyclopedia, the last of the last, thank you to see the support of the officer!!