Determines the object survival mode

GC involves nothing more than three scenarios:

  • Which memory needs to be reclaimed
  • When to recycle
  • How to recycle

For the first question, we first need to make clear whether the object is to be reclaimed, that is, to judge whether the object is still alive, the way to judge is as follows:

Reference counting method

Reference counting is simply adding a reference counter to an object, incrementing it every time it is referenced and subtracting it every time it is no longer referenced.

This method is simple to implement and has good judgment efficiency. One problem, however, is that it can’t judge cross-reference scenarios, such as:

a.test = b; b.test = a

And Java virtual machines do not use reference counting

Accessibility analysis algorithm

Accessibility analysis is through a series of GC root (global references, such as constant or static properties) of the object as a starting point, search down from the starting point, the path through the known as the reference, if chain from GC root the reference to the object, the object is to survive, or object can be recycled, as shown in figure

Reference types

Survival depends on references, which can be divided into four types

  • Strong references: Such as Object a = new Object(), garbage collection does not occur as long as strong references exist.
  • SoftReference: implemented with the SoftReference class, an object associated with a SoftReference is placed in the collection queue for recycling when memory overflow occurs.
  • WeakReference: WeakReference class implementation, weaker than soft reference, WeakReference associated objects, can only live until the next garbage collection.
  • Virtual reference: Implemented by the PhantomReference class, the only purpose of a virtual reference is to receive a system notification when an object is garbage collected, with no impression of the object’s lifetime.

F – Queue Queue

Objects that are immediately unreachable are not immediately recycled, but are marked twice:

Finalizer thread will trigger the virtual machine to execute Finalize (). If finalize() is necessary, Finalizer thread will trigger the virtual machine to execute Finalize (). If Finalize () is necessary, Finalizer thread will trigger the virtual machine to execute Finalize (). So objects that are referenced again in an F-queue have a chance of surviving. To be referenced as in Finalize ().

Garbage collection algorithm

Mark clearance

The most basic algorithm is the mark-removal algorithm, which is divided into two stages of marking and clearing. All objects that need to be recycled are marked first, and unified collection is carried out after the marking is complete.

This algorithm is simple to implement, but there are a lot of memory fragmentation, and the efficiency of marking and cleaning is not high

Replication algorithm

Divide the available memory into two parts, use one piece at a time, and when one piece is running out, copy the surviving objects onto the other piece and clean up the used memory.

This algorithm is simple to implement and efficient to run, but the memory is divided into two parts and the memory usage is reduced

Mark-collation algorithm

The marking phase of the mark-declutter algorithm is the same as that of the mark-clean algorithm, but the subsequent declutter phase moves the surviving objects to one end of memory and then cleans up memory directly beyond the end boundaries. Defragmenting is to avoid memory fragmentation.

Generation collection algorithm

Generational recycling is the use of different recycling algorithms according to the region of the heap, such as the new generation suitable for the use of copy algorithm, the old age suitable for the use of mark-clear algorithm or mark-collation algorithm.

Garbage collector

The main focus here is on the garbage collector implemented by HotSpot, as shown

Each generation has its own collectors, such as Serial, ParNew, Parallel, and G1 (which are both chronologically appropriate) for the new generation, and CMS, Serial Old, and Parallel Old for the Old generation. The connected representatives in the figure can be used together, and the unconnected representatives cannot be used together.

There is something called a Safepoint, where the program does not stop everywhere for GC, but only when a “specific location” (the Safepoint) is reached. The safe points should not be chosen too little so that GC waits too long, nor too often.

Serial collector

This collector is a single-threaded collector that only uses one CPU or one thread for garbage collection, and all other worker threads must be suspended while garbage collection is performed. Stop The World can be hard for an app to accept, such as pausing for 5 minutes for garbage collection for every hour it runs, probably smashing The computer.

ParNew collector

This collector is a multithreaded version of Serial collector, using multiple threads for garbage collection. The rest of the control parameters, collection algorithm, STW, object allocation rules, and collection strategy are exactly the same as Serial without much innovation.

Parallel avenge

The Parallel Insane collector is a new generation collector that uses replication algorithms and is multithreaded. The same as ParNew. The purpose of the Parallel Insane is to achieve a controlled throughput that uses CPU time efficiently to complete a program’s computational tasks as quickly as possible. This collector provides the -xx: MaxGCPauseMillis and -xx: GCTimeRatio parameters for precise throughput control

Serial Old collector

The Serial Old collector is an older version of the Serail collector, which is also a single-threaded collector and uses a mark-collation algorithm. This collector is intended for use by virtual machines in Client mode.

Parallel Old collector

The collector is an older version of the Parallel Avenge collector, using multithreading and mark-collation algorithms. The purpose of the Application is to be insane. The Parallel Exploiter is the application of Serial Old, which does not perform well on the server side. Parallel Insane cannot be used in conjunction with CMS.

CMS collector

CMS (Concurrent Mark Sweep) collector is a collector whose goal is to obtain the shortest recovery pause time. It is now widely used in Internet servers. The CMS collector is implemented based on the mark-clear algorithm, and the whole process is divided into four steps:

  • Initial tag: Tag only objects that GC root can associate directly, which is fast
  • Concurrent marking: GC root trace process
  • Relabelling: Corrects the marking record of the part of the object whose mark changed during concurrent marking as the user program continued to run
  • Concurrent cleanup: Executes concurrently with the user thread

CMS has three obvious disadvantages:

  • Very sensitive to CPU resources. When there are more than four cpus, concurrent collection takes at least 25% of the CPU resources of the garbage collection thread and decreases as the number of cpus increases. With fewer than four cpus, the CMS’s image of a user’s program can become so large that it may have to allocate half of its computing power to GC, resulting in a sudden 50% drop in performance.
  • Unable to handle floating garbage. Floating garbage is the garbage that accompanies the execution of the user program and can only be cleaned up by the next GC.
  • Creates a lot of space debris. CMS is based on the tag – clear algorithm, the algorithm mentioned above, will produce a lot of space debris, in order to solve this problem, a CMS offers – XX: + UseCMSCompactAtFullCollection parameters, when not used at the top of the CMS to be FullGC memory fragments merging sorting.

G1 collector

G1 is a collector for server applications designed to replace the CMS collector. The G1 has the following features:

  • Parallelism vs. concurrency: Use multiple cpus to shorten STW time and keep Java programs running concurrently
  • Generational collection: Better for collecting old objects
  • Space integration: G1 is based on mark-collation algorithm as a whole and copy algorithm as a part to ensure no memory space fragmentation during operation
  • Predictable pause: In addition to pursuing low pause times, G1 models predictable pause times.

G1 divides the Java heap into independent regions of equal size, preserving the concept of old and new generations, but not physically isolated. The operation process of G1 can be divided into:

  • Initial tag: Marks only objects that GC root can associate directly with
  • Concurrent flags: Perform reachability analysis from GC root to find viable objects
  • Final mark: Corrects the mark record of the part of the object whose mark changed as the user program continued to run during concurrent marking
  • Filter collection: The collection value and cost of each Region are sorted, and the collection schedule is specified based on the expected GC pause time of the user

Memory allocation and reclamation policies

Object memory allocation, is allocated on the heap, allocation is in accordance with certain allocation rules.

  • Objects are allocated first in Eden: Objects are allocated in Eden of the new generation. When Eden does not have enough space to allocate objects, the JVM generates a Minor GC. The surviving objects enter the Survivor space, and the large surviving objects enter the old age through the allocation guarantee mechanism. The ratio of Eden and Survivor Spaces is 8:1, which can be adjusted by using -xx: SurvivorRatio.

  • Large objects go directly to the old age: The JVM provides the -xx: PretenureSizeThreshold parameter for large objects, such as very long strings and arrays. Objects larger than this value go directly to the old age to avoid large memory replication in Eden and Survivor zones.

  • Long-lived objects are aged: the JVM gives each object an Age counter, and each time a Minor GC remains alive, its Age increases by one, and when it reaches a certain Age (15 by default), it is aged. The value can be set by -xx: MaxTenuringThreshold.

  • Dynamic age determination: If the sum of the size of all objects of the same age in the Survivor area is greater than half of the Survivor space, the object of age greater than or equal to this age is directly entered into the old age.

  • Space allocation guarantee: Before the Minor GC, the JVM checks whether the contiguous space of the following old ages is greater than the total space of all objects of the new generation. If so, the Minor GC is safe and feasible. If less, the JVM checks whether the HandlePromotionFilure value allows the guarantee to fail, and if so, the JVM checks whether the contiguity of the old age is greater than the average size of the previously promoted old age object, and if so, tries the Minor GC; If less than, or the HandlePromotionFilure value does not allow, a Full GC is performed.