The contents of this article are too much and cost the author a lot of effort. I strongly recommend readers to collect and watch 😉🙇🙏 first

Now is the end of the year, there are probably many brothers preparing for the interview, I hope this article can help you.

Reprint please indicate the source, the original is not easy!

preface

Previous articles:

  • Introduces you to the JVM class loading mechanism

  • 🔥 beautiful graphics guide you to master the JVM memory layout

Garbage Collection (GC) has a history of more than half a century since it was created in Lisp in 1960. In Java, memory is automatically allocated and reclaimed by the JVM, and the main purpose of the GC is to automatically free up memory by identifying objects that are no longer used.

GC researchers are primarily thinking about these three things.

  • What memory needs to be reclaimed?
  • When is it recycled?
  • How to recycle?

This article also roughly in accordance with this idea, for you to describe the relevant knowledge of garbage collection. Since there will be a lot of knowledge about memory areas, I encourage you to read this article after you have studied the beautiful graphics that lead you to the layout of JVM memory.

Here we first thank Zhou Zhiming for his fresh work: “Deep Understanding of Java Virtual Machine” – 3rd edition

This gives you a deeper understanding of the JVM and is highly recommended.

The main content of this article is as follows (it is recommended that you think and learn in accordance with the following ideas when reading and learning) :

  • What memory needs to be reclaimed? The area of memory where GC occurs?

  • How do I determine if this object needs to be reclaimed? Survival criteria for GC?

    Here, the following knowledge concepts can be derived:

    • Reference counting method
    • Accessibility analysis
    • Types, characteristics and differences of references (strong reference, soft reference, weak reference, virtual reference)
    • Extend knowledge :(WeakHashMap) (reference queue)

  • Once we have the survivability criteria for objects, we need to know the relevant algorithms for GC (idea)

    • Mark-sweep algorithm
    • Copying algorithms
    • Mark-compact algorithm

  • Before we move on, we need to know some GC terms 📖 to prevent confusion about some of the concept descriptions

  • Knowing the algorithms, it is natural to move on to the implementation and application of these algorithms in the JVM, namely the various Garbage collectors

    • Serial collector
    • Parallel collector
    • ⭐ CMS collector
    • ⭐ G1 collector

1. Target region of GC

In a word: GC focuses on the heap and the method area

Understand the distribution and characteristics of Java runtime memory in this article that takes you through the layout of JVM memory.

We know that the program counter, virtual machine stack, local method stack three areas are born and die with the thread. The stack frames in the stack methodically perform stack and stack operations as methods enter and exit. How much memory allocation in each stack frame is basically set in the class structure is known (though at runtime will some optimization by a JIT compiler, but the discussion in this chapter, based on a conceptual model, in general can be thought of as compile-time knowable), so this a few areas of memory allocation and recovery with certainty, In these areas, you don’t need to worry too much about collection, because when a method terminates or a thread terminates, the memory will follow.

The heap and method area are different. Multiple implementation classes in an interface may require different memory, and multiple branches in a method may require different memory. We only know which objects will be created while the program is running, and the allocation and reclamation of this part of memory are dynamic. This is the area of memory that GC focuses on.

Ii. Survival criteria for GC

Knowing which areas of memory need to be reclaimed, the natural question is, how do you determine if an object needs to be reclaimed? Reclaim object… No object I sound a little weird 😂)

There are two classic strategies for determining whether an object can be reclaimed.

  • Reference counting algorithm
  • Accessibility analysis algorithm

1. Reference counting

Maintains a counter counter in the object header that is +1 if the object is referenced once; Counter -1 if reference is invalid. When the counter is 0, the object is considered invalid.

Reference counting algorithms are not used in mainstream Java virtual machines to manage memory, mainly because it is difficult to solve the problem of circular references between objects. The reference count of the objects that are referenced through the loop will never be zero, and as a result they will never be released.

2. Accessibility analysis algorithm ⭐

Starting from GC Roots, the search path is called reference chain. When an object is not connected to GC Roots by any reference chain, the object is proved to be unavailable. Unreachable objects.

In Java, GC Roots refers to:

  • Objects referenced in the Java virtual machine stack (the local variable table in the stack frame)
  • Objects referenced in the local method stack
  • The object referenced by the constant in the method area
  • The object referenced by the class static property in the method area

3. References in Java ⭐

Java extends the concept of Reference, which is divided into four types: Strong Reference, Soft Reference, Weak Reference and Phantom Reference. The intensity of these four citations gradually decreases in turn.

The main reason for this design is to describe a class of objects that can remain in memory when there is enough space; If memory space is too tight after garbage collection, these objects can be discarded. Many system cache functions fit this application scenario.

That is, the JVM has a different execution strategy for GC for different reference types. So we need to know about that.

A. Strong Reference

MyClass obj = new MyClass(); / / strong reference

obj = null // The 'obj' reference is set to null, and the 'MyClass' object created earlier can be reclaimed
Copy the code

As long as a strong reference exists, the garbage collector will never reclaim the referenced object, and only if the reference is set to NULL will the object be reclaimed. However, if we mistakenly maintain a strong reference, such as assigning a value to a static variable, the object will not be recycled for a long time, resulting in a memory leak.

B. Soft Reference

A soft reference is a weaker reference to a strong reference that exempts an object from some garbage collection and only attempts to reclaim the object it points to if the JVM decides it is out of memory. The JVM ensures that the object to which the soft reference points is cleaned up before an OutOfMemoryError is thrown. Soft references are often used to implement memory-sensitive caches, so that if there is free memory, the cache can be retained temporarily and cleaned up when it is low, ensuring that the cache is used without running out of memory.

SoftReference<MyClass> softReference = new SoftReference<>(new MyClass());
Copy the code

C. Weak Reference

Weak references are weaker than soft references. When a JVM does garbage collection, objects associated only with weak references are reclaimed, regardless of whether memory is sufficient.

WeakReference<MyClass> weakReference = new WeakReference<>(new MyClass());
Copy the code

Weak reference can be extended to a knowledge point, WeakHashMap&ReferenceQueue

ReferenceQueue is the point of reference for GC callbacks. Here because of space reasons will not elaborate, recommended reading: the use of ReferenceQueue

D. Phantom References

Virtual references, also known as ghost references or phantom references, are the weakest type of reference relationship. The existence of a virtual reference does not affect the lifetime of an object, nor can an object instance be obtained through a virtual reference. The sole purpose of setting a virtual reference association for an object is to receive a system notification when the object is reclaimed by the collector.

PhantomReference<MyClass> phantomReference = new PhantomReference<>(new MyClass(), new ReferenceQueue<>());
Copy the code

3. GC algorithm ⭐

Now that we have criteria to determine whether an object is alive or not, let’s look at the algorithms associated with GC.

  • Mark-sweep algorithm
  • Copying algorithms
  • Mark-compact algorithm

1. Mark-sweep algorithm

The mark-sweep algorithm is conceptually the simplest and most basic garbage disposal algorithm.

This method is simple and fast, but its disadvantages are also obvious. One is the efficiency problem, the efficiency of marking and clearing is not high. The other is the space problem. After the mark is cleared, a large number of discontinuous memory fragments will be generated. Too much space fragment may cause that when the program needs to allocate large objects in the future, it cannot find enough contiguous memory and has to trigger another garbage collection action in advance.

The subsequent collection algorithms are based on this idea and improved.

2. Copying algorithms

The replication algorithm improves the efficiency of the mark-clear algorithm.

It divides the available memory by capacity into two equally sized pieces, one of which is used at a time. When this area of memory is used up, the surviving objects are copied to the other area, and the used memory space is cleaned up again.

In this way, the memory is reclaimed for the whole half region every time, and there is no need to consider the complicated situation of memory fragmentation when allocating memory. As long as the heap top pointer is moved, the memory can be allocated in order, which is simple to implement and efficient to run.

The disadvantages are also obvious, with the available memory reduced by half.

Today’s commercial virtual machines all use this collection algorithm to recover the new generation. According to the special research of IBM, 98% of the objects in the new generation are “live and die”. Therefore, it is not necessary to divide the memory space according to the 1:1 ratio, but to divide the memory into a large Eden space and two small Survivor Spaces. Use Eden and one of the pieces Survivor each time.

As mentioned in the previous article, HotSpot’s default Eden:survivor1: Survivor2 =8:1:1, as shown in the figure below.

Memory allocation guarantees

Of course, 98% of object collectables are only data in the general scenario, there is no way to ensure that no more than 10% of objects survive each collection, and when Survivor space is insufficient, other memory (here refers to the old years) is required for allocation guarantee (Handle Promotion).

Memory allocation of guarantee like we go to a bank loan, if we have a good reputation, in 98% of cases can repay on time, so Banks may default we unluckily to repay the loan in the next, only if I can’t need to have a guarantor can guarantee payment, can deduct money from his account, the bank is considered without risk. The same is true of the memory allocation guarantee. If there is not enough space in another Survivor space to hold the surviving objects collected by the previous generation, these objects will enter the old age directly through the allocation guarantee mechanism.

3. Mark-tidy algorithm

The replication algorithm is mainly used to recover objects of the new generation, but this algorithm is not suitable for the old generation. Because of the old age of the object survival rate is higher (after all, most of the GC is experienced through the hardships of a very strong 😎)

Another mark-compact algorithm was proposed based on the characteristics of the old days. The marking process is still the same as the mark-clean algorithm, but instead of cleaning up the recyclable objects directly, the next step is to move all the surviving objects to one end and then clean up the memory directly beyond the end boundary.

4. Generational collection algorithm

Did you notice that we introduced the concept of the new generation and the old generation into the previous statement? Precisely because of the idea of generational collection algorithms, the Java heap is divided into new generation and old generation. There is a sequential causal relationship between the two concepts.

This algorithm is very simple, is according to the different life cycle of the object, the memory is divided into chunks. In the Java heap, the memory area is divided into the new generation and the old generation, so that the most appropriate collection algorithm can be adopted based on the characteristics of each generation.

As we described in the introduction of the above algorithm, in the new generation, a large number of objects are found to die and only a small number of objects survive during garbage collection, so the replication algorithm is selected, and the collection can be completed only by paying a small amount of the replication cost of living objects. In the old days, because the object has a high survival rate and there is no extra space to allocate it, it has to use the “mark-clean” or “mark-tidy” algorithm for recycling.

  • New generation: Replication algorithms
  • The old days: mark-clean algorithm, mark-tidy algorithm

5. Review the process of triggering GC when creating objects

Here is a review of the JVM memory layout flowchart for creating a new object. This diagram also describes the GC flow.

Iv. GC terminology 📖

Before we learn about the garbage collector, we need to introduce some GC terminology 😊 to our readers so that you can understand it later.

  • Part of the collectionPartial GC: Garbage collection that does not aim to collect the entire Java heap.
    • Minor /Young GC: Garbage collection that targets only the new generation.
    • Major GC: Garbage collection that targets only Old GC. Currently, only the CMS collector has the behavior of collecting older generations separately. Also note that the term “Major GC” is a bit confusing and often means different things from source to source, so it’s up to the reader to distinguish between old collections and whole collections depending on the context.
    • Mixed GC: Garbage collection that aims to collect the entire new generation and parts of the old generation. Currently, only the G1 collector has this behavior.
  • Full GC: Collects the entire Java heap and method area garbage collection.
  • Parallel: While the JVM is running, there are both application threads and garbage collector threads. The parallel phase is performed by multiple GC threads, that is, the GC work is divided between them.
  • Serial: The Serial phase is executed only on a single GC thread.
  • STW: Stop The World phase, The application thread is paused so that The GC thread can do its work. When an application is paused because of GC, this is usually due to The Stop The World phase.
  • Concurrent: User threads execute concurrently with garbage collector threads, not necessarily in parallel, but alternately (competing)
  • Incremental: If a phase is incremental, it can run for a while and then terminate prematurely due to some condition, such as the need to perform a higher priority GC phase while still completing productive work. The incremental phase is in sharp contrast to the phase that needs to be fully completed.

Garbage collector ⭐

Knowing the algorithms, it is natural to move on to the implementation and application of these algorithms in the JVM, namely the various Garbage collectors.

The first important thing to realize is that for most JVMS, you need two different GC algorithms, one for cleaning up the new generation and one for cleaning up the old.

This means that you will typically see two collectors in combination in the JVM. The following figure shows all of the collectors in the JVM (Java 8), where wired ones can be combined.

In order to reduce complexity and fast memory, I directly give several commonly used combinations here. Others are either obsolete or simply not practical in real life.

The new generation The old s JVM options
Serial Serial Old -XX:+UseSerialGC
Parallel Scavenge Parallel Old -XX:+UseParallelGC -XX:+UseParallelOldGC
Parallel New CMS -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
G1 G1 -XX:+UseG1GC

Next, let’s start with the individual garbage collectors. It should be mentioned here that I divide garbage collectors into the following categories:

  • Serial GC
  • Parallel GC
  • Concurrent Mark and Sweep (CMS)
  • G1 – Garbage First

There is no other reason, I think this is more in line with the idea of understanding, you better understand.

4.1 Serial Collector

Serial translates to single thread. There are two types of single-threaded collectors, Serial and Serial Old. The only difference is that Serial works in the new generation using the “copy” algorithm, while Serial Old works in the Old generation using the “tag-collation” algorithm. So I’m going to put them together.

Serial collector The serial collector is the most classic, basic, and best understood. They are characterized by single-threaded and exclusive running, which can lead to poor user experience. Although its collection approach is not run-friendly for programs, performance on a single CPU hardware platform can outperform other parallel or concurrent processors due to its single-threaded execution nature.

The meaning of “single thread” is not only that it will use only one processor or one collection thread to do garbage collection, but more importantly, it must suspend all other worker threads until it finishes collecting (the STW phase).

STW can be a bad user experience, so from JDK 1.3 through the latest JDK 13, the HotSpot VIRTUAL Machine development team’s efforts to eliminate or reduce user thread pauses due to garbage collection have continued, from the Serial collector to the Parallel collector, Then came the Concurrent Mark Sweep (CMS) and Garbage First (G1) collectors, and finally Shenandoah and ZGC, which are currently the most cutting-edge Garbage collectors.

Although there are many new collectors, serial collectors still have their own scenarios. To date, it is still the default new generation collector for HotSpot VIRTUAL machines running in client mode, and has one advantage over other collectors: simplicity and efficiency. For memory-resource-constrained environments, it has the lowest additional memory consumption of any collector, with no thread interaction overhead per thread. (This is actually a time for space concept)

The serial garbage collector can be used with the JVM parameter -xx :+UseSerialGC (also shown in the table above)

4.2 Parallel Collector

According to the thinking of program development, after single-threaded processing, the next natural step is the era of multi-core processor, the era of multi-threaded parallel processing of programs. The parallel collector is a multi-threaded collector, which can improve collection performance under multi-core CPUS.

Here we will introduce:

  • ParNew
  • Parallel Scavenge
  • Parallel Old

Here is too long to look at the version of vernacular summary, easy to understand. Because I know some of you who are just starting to learn the JVM feel dizzy when you look at these terms.

  • The ParNew collector is a multithreaded version of the Serial collector, based on the “copy” algorithm, but otherwise exactly the same, and has been largely phased out since JDK9, only working with CMS in the JVM.
  • The Parallel Avenge collector is similar to the ParNew collector in that it is based on a “copy” algorithm, but the former focuses more on itControllable throughputAnd can pass- XX: + UseAdaptiveSizePolicyOpen garbage collectionAdaptive adjustment strategyThe switch.
  • The Parallel Old exploiter is an older version of the Parallel Exploiter, based on the mark-collation algorithm.

A. ParNew collector

The ParNew collector does not offer much innovation over the Serial collector, except that it supports multi-threaded parallel collection, but it is the preferred new generation collector for HotSpot VMS running in server mode, especially legacy systems prior to JDK 7. One reason that has nothing to do with functionality or performance but is important is that it is currently the only one besides the Serial collector that works with the CMS collector.

Since G1, however, ParNew’s position has become more nuanced, and since JDK 9, the combination of ParNew and CMS collector is no longer the official recommended collector solution in server mode. The official hope was that it would be completely replaced by the G1, and even removed the “ParNew + Serial Old” and “Serial + CMS” collector combinations (which were not used in this way), and simply removed -xx: The UseParNewGC parameter means that ParNew and CMS can only work with each other, and no other collector can work with them anymore. Since then, ParNew has been incorporated into CMS as part of its dedicated new generation.

A. avenge B. avenge

The Parallel Scavenge collector, similar to the ParNew collector, is a Parallel multithreaded new-generation collector that uses replication algorithms. The Parallel Insane focuses on controllable Throughput.

Note: Throughput is the ratio of CPU time spent running user code to total CPU consumption, i.e. Throughput = time spent running user code/(time spent running user code + garbage collection time)

The Parallel Avenge collector provides several parameters to precisely control throughput and pause times:

parameter role
–XX: MaxGCPauseMillis The maximum garbage collection pause time is a number of milliseconds greater than 0. The collector tries to keep the collection time within this set point. However, it should be noted that in the same case, the recovery time is inversely proportional to the number of recovery. The smaller the recovery time is, the corresponding number of recovery will increase. So it’s not that the lower the better.
-XX: GCTimeRatio Throughput size, which is an integer between 0 and 100, represents the ratio of garbage collection time to total time.
XX: +UseAdaptiveSizePolicy This is a switch parameter. When activated, there is no need to manually specify the size of the new generation (-xMN), Eden to Survivor ratio (-xx: SurvivorRatio), or the size of the promoted old age object (-xx: SurvivorRatio). PretenureSizeThreshold), the vm collects performance monitoring information based on the current system, and dynamically adjusts these parameters to provide the most appropriate pause times or maximum throughput. This modality is called an adaptive modality strategy for garbage collection (GERGonomics)

C. Parallel Old collector

The Parallel Old is an older version of the Parallel Avenge collector, multi-threaded, based on the mark-and-collate algorithm. This collector was only available in JDK 1.6.

As the Parallel Scavenge avenge would have no choice but to work with the Serial Old (PS MarkSweep) collector if the new generation chooses the Parallel Avenge collector, The Parallel Old collector was created to solve this problem. The Combination of the Parallel Insane and the Parallel Old collector is better suited to throughput and CPU resource-sensitive applications.

4.3 ⭐ Concurrent Mark and Sweep (CMS)

The CMS(Concurrent Mark Sweep) collector is a collector whose goal is to achieve the shortest collection pause time (pursuit of low pauses). It allows the user thread and the GC thread to execute concurrently during garbage collection, so that the user does not feel a significant lag during garbage collection.

As the name suggests, CMS is based on a mark-and-sweep algorithm. Its working process is a bit more complicated than the above collectors. The whole process is divided into the following four steps:

1) CMS Initial mark: it is mainly used to mark the lower level objects from GC Root. This process STW, but there are not many lower level objects directly associated with GC Root, so this process is actually very fast.

2) CMS Concurrent mark: Based on the results of the previous step, continue to identify all associated objects down to the very end of the chain. This process is multithreaded, and although it theoretically takes longer, other worker threads do not block, and there is no STW.

3) CMS remark: As the name implies, to mark again. Why mark it again? Because step 2 does not block other worker threads, it is very likely that other threads will generate new garbage during identification.

Here’s a good example:

Let’s say you and your partner (multiple GC threads) are cleaning a long corridor from one end to the other. By the time you get to the other end of the hall, some of your classmates may have dropped some new garbage. So, in order to clean up the hallway, you need to signal to all your classmates (user threads) not to throw it away again (enter the STW phase), and then you and your friends quickly pick up the new garbage. Of course, because the garbage has been collected, so this time to collect the new garbage, it will not take long (that is, the STW time will not be very long).

CMS Concurrent sweep:

❔❔❔ Q&A: Why does A CMS use a mark-erase algorithm? Didn’t we mention that the “mark-clean” algorithm leaves a lot of memory fragmentation?

That’s true, but you can’t help it. If you switch to a mark-tidy algorithm and clean up the garbage, you can change the memory address of those objects. Remember, other threads are still working at this time, and if the address of the referenced object changes, the world is in chaos.

The JVM provides two parameters for the above problem:

parameter role
–XX: +UseCMS-CompactAtFullCollection (on by default, deprecated from JDK 9) to enable the merge defragmentation process when the CMS collector has to perform FullGC. The defragmentation process cannot be concurrent, and the space fragmentation problem is gone, but the pause time must be long.
–XX: CMSFullGCsBeforeCompaction (Deprecated in JDK 9) This parameter requires the CMS collector to defragment the next time it enters the Full GC after a number of undecluttered Full GC (the default is 0, which means defragmenting each time it enters the Full GC).

As a side effect, since the last concurrent sweep does not block other threads, new garbage objects may still be created during the sweep, which will only be cleaned up in the next GC.

4.4 ⭐ G1 – Garbage First

On the release of JDK 9, G1 claimed to replace the Parallel Insane and Parallel Old as the default garbage collector in server-side mode.

In addition to some shortcomings of CMS, such as memory fragmentation in the old days, STW times have improved a lot, but there is still room for improvement. G1 came out of the window, with a new idea for memory partitioning in the heap, and a bit of a divide-and-conquer approach to algorithms. What does that mean? Let’s move on.

G1 divides the contiguous Java heap into independent regions of equal size, each of which can act as the Eden space of the new generation, Survivor space, or old chronospace, as needed. The size of each Region can be set using -xx: G1HeapRegionSize. The value ranges from 1MB to 32MB and is the NTH power of 2.

Regions also have a special class of Humongous regions that are used to store large objects. G1 considers large objects as long as the size of a Region exceeds half of its capacity. Large objects that exceed the capacity of the entire Region will be stored in N consecutive Humongous regions.

Humongous, or H Region for short, is a Region dedicated to storing super-large objects. Usually, the Region Size is >= 1/2. Most behaviors of G1 treat Humongous Region as a part of the old age.

Given the memory planning in G1, it’s easy to understand why it’s called “Garbage First.” All garbage collection is region-based. G1 maintains a priority list in the background based on the size of collection space obtained by each Region and the time required for collection. Each time, the Region with the highest value (garbage) is preferentially collected based on the allowed collection time, thus avoiding the whole Region garbage collection in the Java heap. That’s how Garbage First got its name.

G1 on the whole, which is based on “tag – finishing” algorithm implementation of collector, but look from the local () between the two Region is based on “tag – copy” algorithm, however, these two algorithms are mean G1 does not produce memory space debris during operation, after completion of the garbage collection can provide neat available memory. This feature makes it easier for programs to run for a long time and not to trigger the next GC prematurely because they cannot find contiguous memory space when allocating memory for large objects.

❔❔❔ Q&A:

An object may not be in the same Region as the object referenced within it. When garbage collection occurs, does the entire heap memory need to be scanned for a complete reachability analysis?

This is where the concept of Remembered Set comes in.

The answer is no. Each Region has a Remembered Set that records the locations of objects referenced by all objects in the Region. Simply add Remembered Set to GC Roots to prevent traversal of the entire heap.

Another concept, Collection Set: A CSet for short, is a Collection of regions that are waiting to be reclaimed. Objects in these regions are copied or moved during GC.

G1 Operation Procedure

If the operation to maintain the Remembered Set is not counted, the G1 collector works in the following steps:

  • Initial Marking: Stop The World, using only one Initial Marking thread to mark all objects directly associated with GC Roots.
  • Concurrent Marking: Use a Marking thread to execute concurrently with the user thread. This process is very slow for accessibility analysis.
  • Final Marking: Stop The World, execute concurrently using multiple Marking threads.
  • Live Data Counting and Evacuation: Recovery of obsolete objects, also stopping The World, and parallel execution using multiple filter recovery threads. (Region statistics are also updated to sort the recovered value and cost of each Region)

As you can see from the description of the phases above, the G1 collector is also intended to completely suspend user threads in addition to concurrent markers. In other words, it is not a pure pursuit of low latency; its official goal is to achieve the highest throughput possible with manageable latency.

Minor /Young GC for G1

When allocating common objects, YGC is triggered when the usage of all Eden Regions reaches the maximum threshold and sufficient memory cannot be allocated. Each time YGC reclaims all Eden and Survivor zones and copies the surviving objects to the Old zone and another portion of Survivor zones.

Here is an extracted GC log:

GC pause (G1 Evacuation Pause) (young)├ ─ ─ the Parallel Time ├ ─ ─ GC Worker Start ├ ─ ─ Ext Root Scanning ├ ─ ─ the Update RS ├ ─ ─ Scan RS ├ ─ ─ Code Root Scanning ├ ─ ─ the Object Copy ├ ─ ─ Code Root Fixup ├ ─ ─ Code Root Purge ├ ─ ─ the Clear CT ├ ─ ─ Other ├ ─ ─ Choose CSet ├ ─ ─ Ref Proc ├ ─ ─ Ref Enq ├ ─ ─ Redirty Cards heavy School ── Heavy School ── Heavy SchoolCopy the code

From this GC log, we can see that the whole YGC consists of multiple sub-tasks and nested sub-tasks, and some core tasks are as follows: Root Scanning, Update/Scan RS, Object Copy, CleanCT, Choose CSet, Ref Proc, Humongous Reclaim, Free CSet.

Recommended reading: Dig deep into G1 GC logs

This article introduces several steps of GC through the G1 GC log. If you are not clear about the above English words, you can refer to them.

Garbage-collection-algorithms – Implementations

G1 Mixed GC

As more and more objects are promoted to Old regions, to avoid running out of heap memory, the virtual machine triggers a Mixed garbage collector, known as Mixed GC, which collects the entire new generation as well as parts of the Old generation. In addition to the entire Young Region, some Old regions are reclaimed. Note that some Old regions are reclaimed, not all of them. You can select which Old regions to collect and control the garbage collection time.

The entire subtask of Mixed GC is exactly the same as that of YGC, except that the scope of the collection is different.

Note: G1 generally does not have the concept of FGC. Because it does not provide the functionality of FGC.

If the Mixed GC still does not work well enough to keep up with the memory allocation requirements of the new object, the Serial Old GC is used for Full GC to force the entire Heap collection.

Compared with CMS, G1 has the following advantages:

  • G1 does not generate memory space fragmentation during operation and provides clean free memory after garbage collection is complete. This feature makes it easier for programs to run for a long time.
  • G1 can predict GC pause times, G1 uses a pause prediction model to meet a user-defined pause time target and selects the number of regions to Collect based on the specified pause time target.

There’s actually a lot more to go on with the G1, and I encourage you to read Inside understanding the Java Virtual Machine or other resources to further your learning and fill in the gaps.

Related parameters:

parameter role
-XX:+UseG1GC Using G1 collector
-XX:G1HeapRegionSize Size of each Region

For more parameters and tuning, see: Analysis and Performance to tune and tune the G1 GC

Afterword.

That’s the end of this series on JVM garbage collection.

Because of the length of the relationship, but also limited by the ability level, this article did not involve a lot of details, can only be regarded as learning JVM students to open a door (a and usually see the article compared to a little bit of the door, write so long allow me to narcissism about it 😂😂). I hope the students who are not satisfied can study more deeply by themselves.

If this article is helpful to you, please give me a thumbs up. This is my biggest motivation 🤝🤝🤗🤗.

reference

  • In-depth understanding of G1 GC logs

  • Some key technologies for the Java Hotspot G1 GC

  • Understanding the Java Virtual Machine in Depth – 3rd edition

  • www.infoq.cn/article/3Wy…

  • Plumbr. IO/faced/ga…