Analysis of Java memory model and garbage collection _java

1. Java Memory model

The Java Virtual machine divides the memory it manages into a number of data regions as it executes the program, as shown in the following figure:

Program counter: A small area of memory that points to the currently executing byte code. If the thread is executing a Java method, this counter records the address of the executing virtual machine bytecode instruction, and if the native method is executed, the calculator value is null.

Java Virtual machine stack: Thread-Private, its lifecycle and thread are consistent, and each method creates a stack frame to store information such as local variable tables, operand stacks, dynamic links, method exits, and so on.

Local method stack: Similar to virtual machine stack functionality, except that the virtual machine stack performs Java method services for virtual machines, while the local method stack serves the native method used.

Java heap: is the largest piece of virtual machine management memory, shared by all threads, that is used to hold object instances, and almost all objects are allocated in that region. Java heap is the main area of memory recovery, from the point of view of memory recycling, because the collector now mostly use the collection algorithm, so the Java heap can also be subdivided into: the new generation and the old era, and then subdivided into a little words can be divided into Eden space, from Survivor space, to Survivor space and so on. According to the Java Virtual Machine specification, the Java heap can be in a physically discontinuous space, as long as it is logically contiguous.

Method area: Like Java, is shared by individual threads to store data that has been loaded by a virtual machine, such as illuminated steady, static variables, and Just-in-time compiler-compiled code.

Run a regular pool, run a regular pool is part of the method area, class file in addition to the version of the class, fields, methods, interfaces, and other descriptive information, there is a constant pool, used to store the compilation of the various literal and symbolic references generated. The new constants can be placed in a constant pool during run time, and more is the Intern () method of the String class, when a string instance calls intern, does the Java lookup constant pool have the same Unicode string constant, and if so, returns its reference; Adds a Unicode equal to the instance string in the constant pool and returns its reference.

2. How to determine the garbage object

There are several instances of objects stored in the Java heap, and the garbage collector first needs to determine which objects are "alive" and which are "dead", or objects that will not be used by any means, until the heap is recycled.

Reference counting method

The reference counting method is simple and efficient, and is a good algorithm in most cases. The principle is: To add a reference counter to the object, whenever there is a place to reference the object, the Counter plus 1, when the reference is invalid, the counter minus 1, when the counter value of 0 indicates that the object is no longer used. Note that the reference counting method is difficult to solve the problem of circular references between objects, and the mainstream Java Virtual machine does not use reference counting to manage memory.

The algorithm of accessibility analysis

The basic idea of this algorithm is to use a series of objects called "GC Roots" as the starting point, starting from these nodes downward search, the search through the path referred to as the reference chain (Reference Chain), when an object to the GC Roots without any reference chain (in the words of graph theory, is to prove that this object is not available when roots from GC to this object. As shown in the figure, objects 5, Object 6, and object 7, although they are related to each other, are not accessible to GC roots, so they will be judged to be recyclable objects.

In the Java language, objects that can be roots as GC include the following:

The object referenced in the virtual machine stack (the local variable table in the stack frame).

The object referenced by a class static property in the method area.

The object referenced by the constant in the method area.

The object referenced by JNI (that is, the commonly said native method) in the local method stack.

Now the question is, does the accessibility analysis algorithm have a circular reference problem between objects? The answer is yes, that is, there is no circular reference problem between objects. The GC root is a specially defined "starting point" outside the object graph and cannot be referenced by objects within the object graph.

object is alive or dead (to Die or Die)

Even objects that are not available in the Accessibility analysis algorithm, is not "Must die", at this time they are temporarily in the "probation" stage, to really declare an object of death, at least two times to go through the marking process: if the object in the analysis of the accessibility of GC roots linked to the chain of reference, It will be marked for the first time and filtered once, if the object is necessary to execute the Finapze () method. When the object does not overwrite the Finapze () method, or the Finapze () method has been called by the virtual machine, the virtual machine treats both cases as "unnecessary execution." Programs can be covered by finapze () to a "soul-stirring" self-rescue process, but this is only one chance yo.

/** * This code demonstrates two points: * 1. Objects can be saved by themselves at the time of GC. * 2. This opportunity to save oneself is only once, because the Finapze () method of an object is only automatically invoked by the system once * @author ZZM/PUBPC class FINAPZEESCAPEGC {pubpc static finap 
 
 ZEESCAPEGC save_hook = null; 
 PUBPC void Isapve () {System.out.println ("Yes, I am still apve:)"); 
  @Override protected void Finapze () throws Throwable {Super.finapze (); 
  System.out.println ("Finapze mehtod executed!"); 
 Finapzeescapegc.save_hook = this; 
 
  } pubpc static void Main (string[] args) throws Throwable {Save_hook = new finapzeescapegc (); 
  The object successfully saved itself for the first time Save_hook = null; 
  System.GC (); 
  Because the Finapze method has a low priority, pause for 0.5 seconds to wait for it to Thread.Sleep (500); 
  if (Save_hook!= null) {Save_hook.isapve (); 
  else {System.out.println ("No, I am dead:("); 
  The code below is exactly the same as above, but this time the self-help failed save_hook = null; 
  System.GC (); 
  Because the Finapze method has a low priority, pause for 0.5 seconds to wait for it to Thread.Sleep (500); 
  if (Save_hook!= null) {Save_hook.isapve (); 
  else {System.out.println ("No, I am dead:("); 
 }} 
} 

The results of the operation are:

Finapze Mehtod executed! 
Yes, I am still apve:) 

Then say quote

Whether to judge the reference number of the object by reference counting algorithm, or whether the reference chain of the object can be reached by the method of the accessibility analysis, it is related to the "reference" to determine the object survival. Prior to JDK 1.2, references in Java were defined as a tradition: if the value stored in a reference type of data represents the starting address of another chunk of memory, the memory is said to represent a reference. After JDK 1.2, Java expanded the concept of references into strong references (strong Reference), soft references (Soft Reference), weak references (Weak Reference), virtual references (Phantom Reference) 4 species, the 4 kinds of reference strength in turn gradually weakened.

• Strong references are references that are common in program code, such as "Object obj = new Object ()", as long as a strong reference exists and the garbage collector never reclaims the referenced object.

• Soft references are used to describe objects that are useful but not required. For objects associated with a soft reference, the objects are listed in the recycle scope for a second recycle before the system will have a memory overflow exception. If there is not enough memory for this collection, a memory overflow exception is thrown. After JDK 1.2, a SoftReference class is provided to implement soft references.

• Weak references are also used to describe non-essential objects, but their strength is weaker than soft references, and objects associated with weak references can only survive until the next garbage collection occurs. When the garbage collector works, objects that are only associated with weak references are recycled, regardless of whether the current memory is sufficient. After JDK 1.2, the WeakReference class was provided to implement the weak reference.

• A virtual reference is also known as a phantom reference or phantom Reference, which is the weakest reference relationship. The existence of a virtual reference to an object does not affect its lifetime at all, nor does it get an object instance 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 JDK 1.2, a phantomreference class is provided to implement the virtual reference.

Soft reference Usage Examples:

Package JVM;

Import java.lang.ref.SoftReference;

Class Node {
pubpc String msg = "";
}

Pubpc class Hello {
pubpc static void Main (string[] args) {
node Node1 = new Node ();//strong reference
node1.msg = "Node1 ";
softreference<node> Node2 = new softreference<node> (NODE1); Soft reference
Node2.get (). msg = "Node2";

System.out.println (node1.msg);
System.out.println (Node2.get (). msg);
}

The output results are:

Node2
Node2

3, the typical garbage collection algorithm

1.mark-sweep (Mark-purge) algorithm

This is the most basic garbage collection algorithm, the reason is that it is the most basic because it is the easiest to implement, the idea is the simplest. The tag-purge algorithm is divided into two phases: the marking phase and the purge phase. The task of the mark phase is to mark all objects that need to be reclaimed, and the cleanup phase is the space occupied by the object being tagged. The specific process is shown in the following illustration:

It is easy to see from the diagram that the tag-purge algorithm is easy to implement, but one of the more serious problems is that it is easy to generate memory fragmentation, and too much fragmentation can lead to a new garbage collection action that will not be able to find enough space in the subsequent process to allocate space for large objects.

2. Copying (copy) algorithm

In order to solve the defects of mark-sweep algorithm, the copying algorithm is presented. It divides the available memory by capacity into two blocks of equal size, using only one piece at a time. When this piece of memory is run out, the surviving object is copied to another piece, then the memory space is cleaned up once, so it is not easy to have the memory fragmentation problem. The specific process is shown in the following illustration:

This algorithm is simple, efficient and not easy to generate memory fragmentation, but the use of memory space has made a high price, because the memory can be used to reduce the original half.

Obviously, the efficiency of the copying algorithm is very much related to the number of the surviving objects, if there are many surviving objects, then the efficiency of the copying algorithm will be greatly reduced.

3. Mark-compact (Mark-finishing) algorithm

In order to solve the defects of copying algorithm and make full use of memory space, a mark-compact algorithm is proposed. The algorithm marks the same phase as the Mark-sweep, but after the tag is finished, it does not clean the recyclable object directly, but instead moves the surviving objects to one end, and then cleans out the memory outside the end of the boundary. The specific process is shown in the following illustration:

4.Generational Collection (generational collection) algorithm

The Generational collection algorithm is an algorithm used by most of the JVM's garbage collectors at present. Its core idea is to divide memory into a number of different regions based on the life cycle of the object's survival. In general, the heap zoning is divided into the old age (tenured Generation) and Cenozoic (young Generation), the old age is characterized by a garbage collection only a small number of objects need to be recycled, and the new generation is characterized by each garbage collection has a large number of objects need to be recycled, Then the most suitable collection algorithm can be adopted according to the characteristics of different generations.

At present, most of the garbage collectors in the new generation are taking copying algorithm, because each garbage collection in the Cenozoic to reclaim most objects, that is, the number of operations to replicate less, but in practice is not in accordance with the proportion of 1:1 to divide the new generation of space, In general, the Cenozoic is divided into a larger Eden space and two small survivor space (generally 8:1:1), each using the Eden space and one of the survivor space, when recycling, Copy the surviving objects in Eden and survivor to another survivor space, and then clear out Eden and the survivor space that you just used.

And because of the characteristics of the old age is a collection of only a small number of objects, the general use of the mark-compact algorithm.

The above analysis of the Java memory model and garbage collection is a small series to share all the content, I hope to give you a reference, but also hope that we support the cloud habitat community.