Personal blog address http://dandanlove.com/

The previous ARTICLE on the JVM memory model covered the respective purpose, creation and destruction times, of each data region under the memory partition managed by the Java Virtual machine at runtime. We need to know more about the GC mechanism and memory allocation of the JVM when we need to check for various memory leaks and overflow problems, and when incoming and collection become the bottleneck to achieve higher concurrency. This article is based on the previous article about the Java garbage collector and memory allocation strategy.

An overview of the

When it comes to Garbage Collection (GC), most people think of this technology as a companion to Java. In fact, GC is much older than Java. Lisp, born at MIT in 1960, was the first language to really use dynamic memory allocation and garbage collection techniques. When Lisp was still embryonic, people were thinking about three things that GC needed to accomplish:

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

The garbage collector focuses on those data areas

  • Program counter
  • The virtual machine stack
  • Local method stack
  • The heap
  • Methods area

The program counter, Java virtual machine stack, and local method stack are created and destroyed by the thread. The stack frames in the stack methodically perform stack and stack operations as methods enter and exit. How much memory is allocated to each stack frame is basically known when the class structure is determined, so memory allocation and reclamation in these areas are deterministic. There is no need to think too much about reclamation in these areas, because when the method ends or the thread ends, the memory will naturally follow reclamation. While the Java heap area and method of area, an interface of multiple implementation classes need memory may not be the same, a method of multiple branch need memory also may not be the same, we can only know during the application is running will create those objects, this part of the memory allocation and recovery are dynamic, garbage collector of this part of the memory.

Let’s start with object recycling in the Java heap.

Determines whether the object is alive

  • Reference counting: By determining how many times an object is referenced (0, unusable), this is hardly a solution to the problem of objects referring to each other in a loop.
  • Root search algorithm: the method of directed graph is adopted to judge whether an object is reachable from GC Roots.


Gc-accessibility analysis.png

What objects can be used as Root nodes for GC?

  • Objects referenced by local variables in the virtual machine stack
  • The object referenced by the static property of the class
  • The object referenced by the constant
  • Objects referenced in JNI

Object collection

To declare an object dead, there are at least two tagging procedures: if an object is found to have no reference chain linked to GC Roots after the reachable row analysis, it will be tagged once and filtered once based on whether it is necessary to execute the Finalize () method. When an object does not overwrite a Finalize () method, or a Finalize () method has already been called by a virtual machine, the virtual machine considers both cases “not necessary to execute”.


Object reclamation. PNG

Object reference type

Speaking of object recycling, we can not say the reference of the object, because no matter [reference counting method] judge the number of references to the object, or [root search algorithm] judge whether the application chain of the object is reachable, determine whether the object is alive are related to the reference. After JDK1.2, Java expands the concept of Reference, which is divided into four types: Strong Reference, Soft Reference, Weak Reference and Phantom Reference. These four reference programs gradually fade away.

  • Strong references are references that are common in program code, such as “Object obj = new Object()”. As long as strong references exist, the garbage collector will never reclaim the referenced Object.
  • Soft references are used to describe objects that are useful but not necessary. Objects associated with soft references are listed in the recycle scope for a second collection before the system is about to run out of memory. A memory exception is thrown if there is not enough memory for this collection. After JDK1.2, a SoftReference class is provided to implement soft references.
  • Weak references are also used to describe non-essential objects, but they are weaker than soft references. Objects associated with weak references can only survive until the next garbage collection occurs. When the incoming collector works, objects associated only with weak references are reclaimed regardless of whether there is currently enough memory. After JDK1.2, WeakReference classes were provided to implement weak 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 only purpose of setting a virtual reference association for an object is to receive a system notification when the object is reclaimed by the collector. After JDK1.2, PhantomReference classes were provided to implement virtual references.

Method area recovery

The garbage collection of the method area or the HotSpot VIRTUAL machine’s persistent generation mainly consists of two parts: discarded constants and useless classes.

Deprecated constant collection is similar to the collection of objects in the Java heap.

Determining whether a class is “useless” is much tougher than determining whether an object is recyclable. The class must satisfy all three conditions:

  • All the power of the modified class is reclaimed, that is, any power of the modified class exists in the Java heap;
  • Any ClassLoader that loads this class is also recycled.
  • The java.lang.Class object corresponding to this Class is not referenced anywhere, and the methods of this Class cannot be accessed anywhere through reflection.

Garbage collection algorithm

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

Mark-sweep algorithm

[Mark-Clearing] is the most basic collection algorithm, which is divided into two stages of “marking” and “clearing”. First, all the objects that need to be recycled at the marking point are recycled uniformly after the completion of marking. Its marking process is the mark in the object recycling mentioned above. Features:

  • Labeling and scavenging are inefficient
  • There is a lot of memory fragmentation after the flag is cleared


Mark-clear

Copying algorithms

In order to solve the problem of efficiency, a kind of known as the “copy” collection algorithms is present, it will be available memory according to the capacity is divided into two pieces of equal size, using only one piece, every time when it ran out of a piece of memory, it is alive the objects are copied to another piece of the above, then has used a clear memory.

  • It doesn’t create debris
  • High operating efficiency
  • The memory has been reduced by half


Replication algorithm

Mark Compact algorithm

Mark – sorting algorithm is between tags – clear and copy 】 【 】 between collection algorithms, marked with tags – clear 】 【 algorithms still, but subsequent steps are not directly to recyclable objects to clean up, but let all live objects move to the end, and then clear directly outside the boundary of the memory.


Mark-tidy

Generational Collection

Current garbage Collection in commercial virtual machines is done using “Generational Collection,” an algorithm that doesn’t have any new ideas but divides memory into chunks based on the lifetime of the object. Typically, the Java heap is divided into the new generation and the old generation, so that the most appropriate collection algorithm can be used for each generation. In the new generation, a large number of objects are found dead every time they come and collect, and only a small number of objects survive. Therefore, it is illegal to choose replication, and only a small amount of the reproduction cost of living objects can be collected. In the old days, because of the high survival rate of the object, there is no additional control for its allocation guarantee, it must use “mark-clean” or “mark-tidy” algorithm to recycle.

Memory allocation policy


Java memory allocation

Here memory allocation, mainly to be allocated on the heap, half of all, the object’s memory allocation is carried out on the heap, but modern technology page support object demolition ride scalar types (scalar type atom types, namely represents a single value, can be a basic type or a String type), and then, allocated on the stack allocated on the stack is rare, we don’t consider here.

The mechanism of Java memory allocation and reclamation is summarized as generation allocation and generation reclamation. Objects are divided into Young Generation, Old Generation, and Permanent Generation (also known as method region) according to their survival time.

  • Young Generation: When objects are created, the allocation of memory occurs first in the young generation (large objects can be created directly in the old generation), and most objects are not used soon after creation, so they quickly become unreachable and are cleaned up by the young generation’s GC mechanism (IBM studies show that 98% of objects die quickly). This GC mechanism is called the Minor OR Young GC. Note that the Minor GC does not mean that the young generation is out of memory, it actually only means that the GC is on the Eden region.

Minor GC: Adopting Copying algorithms

  • Old Generation: Objects that survive long enough in the Young Generation to not be cleaned up (that is, after several Young GCS) are copied to the Old Generation, which generally has more space to hold more objects and has fewer GCS occurring on the Old Generation than the Young Generation. When the older generation runs out of memory, the Major GC, also known as Full GC, is performed.

Full GC: Mark-Compact algorithm


GC.png

The allocation of memory on the young generation looks like this, and the young generation can be divided into three regions: the Eden region and two Survivor regions (Survivor 0 and Survivor 1).

Most newly created objects will be allocated in Eden, and most of them will soon die. The Eden area is a contiguous memory space, so allocating memory on it is extremely fast.

When Eden is full, a Minor GC is executed to clean up the dead objects and copy the remaining objects to a survivorship Survivor0 (in this case, Survivor1 is blank and one Survivor is always blank).

After that, each time Eden is full, a Minor GC is performed and the remaining objects are added to Survivor0;

When Survivor0 is also full, the surviving objects are copied directly to Survivor1, and the remaining objects are added to Survivor1 after Minor GC in Eden (where Survivor0 is blank).

After the two live zones have been switched a few times (default 15 times for HotSpot virtual machines, controlled by -xx :MaxTenuringThreshold, which is greater than this value to enter the old age), the surviving objects (actually only a small number of our own defined objects, for example) will be copied to the old age.

Objects are allocated in Eden area first

Big object goes straight to the old age

Long-lived objects will enter the old age

The object’s age is set to 1 when entering a Survivor zone for the first time. The object’s age increases by one year each time it “survives” MinorGC in a Survivor zone, and when it reaches a certain age (15 by default), it will be promoted to the old age.

Dynamic object age determination

In order to better adapt to the memory conditions of different programs, the virtual machine does not always require that the object age must reach MaxTenuringThreshold to advance to the old age. If the sum of all object sizes of the same age in the Survivor space is greater than half of the Survivor space, Objects whose age is greater than or equal to this age will go directly to the old age without waiting until the age specified in MaxTenuringThreshold.

Space allocation guarantee

Before MinorGC occurs, the virtual machine checks to see if the maximum contiguous space available in the old generation is greater than the total space available for all objects in the new generation. If this condition is true, then the MinorGC can be guaranteed to be safe. If this is not true, the virtual machine checks the HandlePromotionFailure setting to see if the guarantee failure is allowed. If so, it continues to check whether the maximum available contiguous space of the old age is greater than the average size of the objects promoted to the old age, and if so, a Minor GC is attempted, although this Minor GC is risky; If less than, or the HandlePromotionFailure setting does not allow risk-taking (risk-taking: In the case of a large number of objects surviving the Minor GC, an allocation guarantee from the old age is required to pass Survivor objects directly into the old age), and then a Full GC is performed instead.

The article here is all about the end, if there are other need to communicate can leave a message!!

To read more articles by the author, check out my personal blog and public account:


The revitalization of book city