JVM Advanced features and Practices (ii): Object Survival decision algorithm (reference) and recycling

Regarding the garbage collector GC(Garbage Collection), most people mean that it is the associated product of the Java language. In fact, the history of GC is far more distant than that of Java, which was born in 1960 at the MIT Lisp is the first language to really use memory dynamic allocation and garbage collection techniques. When Lisp is still embryonic, developers are thinking about 3 things the GC needs to accomplish:

• What memory needs to be recycled?
• When do I recycle?
• How to recycle?

At present, the GC has already solved the above problems, the dynamic allocation of memory and memory recovery mechanism is quite mature, everything seems to be "automated" up. Developers still need to understand the basics of GC and memory allocation, as developers need to implement the necessary monitoring and tuning of these "automation" technologies when troubleshooting various memory overflows, memory leaks, and garbage collection as a bottleneck for the system to reach a higher level of concurrency.

In the previous article, blog post introduced the various parts of the Java Memory Runtime area, where

• program counter , virtual machine stack , local method stack 3 regions are born with threads, and the stack frames in the stack execute the stack and stack operations in a methodical manner as the method enters and exits. The memory allocated in each stack frame is basically known when the class structure is determined, so there is certainty in memory allocation and recycling in these areas, and there is no need to think too much about recycling in these areas, because the memory naturally follows the recycle when the method ends or the thread ends.

• While the Java heap and the method area are different, multiple implementation classes in an interface may require different memory, and multiple branches in one method may require different memory, and we can only know which objects are created while the program is running. This part of the memory allocation and recycling are dynamic, the garbage collector is concerned about this part of memory, the subsequent discussion of "memory" allocation of the collection is also referring to this piece, especially need attention.

JVM Advanced features and Practices (i): Java memory area and memory overflow exception

I. Whether the object is dead

In the heap, where almost all of the object instances in the Java world are stored, the garbage collector, before reclaiming the heap, is the first to determine which of these objects is "alive" and which ones are "dead" (that is, objects that cannot be used in any way).

1. Reference counting algorithm (Reference counting)

(1) algorithm meaning

Many textbooks determine whether the object survives the algorithm: Add a reference counter to the object, and whenever there is a place to reference it, the counter plus 1, when the reference fails, the counter minus 1, any time the counter 0 of the object is impossible to be used again.

(2) Algorithm efficiency analysis

I believe most people are not unfamiliar with this algorithm, objectively speaking, the reference counting algorithm implementation is simple, the decision efficiency is very high, most of the case is a good algorithm. For example, Microsoft's COM (Component Object Model) technology, the use of ActionScript3 Flashplayer, the Python language is the use of this algorithm for memory management. However, the algorithm is not referenced in the Java Virtual machine to manage memory, the main reason is that it is difficult to solve the problem of circular reference between objects .

(3) Examples of proof

For example, the method in the following code testGC() : Object Obja and Object objb have field instance, assignment order, objA.instance = objB; objB.instance = objA; and Besides, these two objects are no longer referenced, in fact, these two objects can not be accessed again, but they reference each other, Causes their reference count to be not 0, so the reference counter cannot notify the GC collector to reclaim them.

"Defect in reference counter"After the/** * TESTGC () method is executed, will obja and OBJB be GC? */PublicClassREFERENCECOUNTINGGC {Public Object Instance =NullPrivateStaticFinalint _1mb = 1024 * 1024; /** * The only meaning of this member property is to occupy a bit of memory so that it can be seen in the GC log whether it has been recycled */private byte[] bigsize = new byte[ 2 * _1MB]; public static void TESTGC () {REFERENCECOUNTINGGC obja = new REFERENCECOUNTINGGC (); REFERENCECOUNTINGGC OBJB = new REFERENCECOUNTINGGC (); obja.instance = ObjB; objB.instance = Obja; Obja = null; objb = null; //assume that Gc,obja and OBJB can be recycled in this line? System.GC (); }} 

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21st
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21st
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29

Operation Result:

[Full GC (System)  0k->210K(10240K),  0.0149142 secs] 4603K->210K(19456K), [Perm : 2999K->2999K(21248K)], 0.0150007 secs] [Times: user=0.01 sys=0.00, real=0.02 secs]

• 1
• 2

• 1
• 2

Results Analysis:

From the running results, it is found that the GC log contains "4603k->210k", which means that the virtual machine is not recycled because the two objects are referencing each other, which also indicates from the side that the virtual machine does not determine whether the object is alive by reference counting algorithms.

2. Accessibility Analytics Algorithm (reachability analysis)

(1) algorithm meaning

In the implementation of mainstream commercial programming languages (Java,C #, and even the oldest Lisp), the accessibility analysis is used to determine whether an object survives. The basic idea of this algorithm is: through a series of objects called "GC Roots" as a starting point, search down from these nodes, the path traversed by the search is called the reference chain (Reference Chain), when an object to the GC Roots does not have any reference chain attached (in the case of graph theory, that is, GC Roots to this object is unreachable), it is not available when proving this object.

(2) schematic description

As the example shows, objects Object5, OBJECT6, and object7 are associated with each other, but they are unreachable to gcroots , so they will be judged as recyclable objects.

(3) Objects in Java that can be used as Gcroots

In Java, the objects that can be used as gcroots include the following:

• Objects referenced in the virtual machine stack (local variable table in the stack frame)
• Object referenced by class static property in method area
• Objects referenced by constants in the method area
• The object referenced by JNI (that is, the general native method) in the local method stack

3. References (strong, soft, weak, virtual reference)

(1) "referencing" the old concept

Whether the reference number of the object is judged by the counting algorithm, or whether the reference chain of the object can be reached by the accessibility analysis algorithm, it is related to "reference" to determine whether the object is alive or not. Before JDK1.2, the reference definition in Java was traditional: if the value stored in the data of the reference type represents the starting address of another piece of memory, it is said that this memory represents a reference.

This definition is pure but too narrow, an object in which the definition is only referenced or not referenced in two states, missing the description of another class of objects: When the memory space is sufficient, can remain in memory If the memory space is still very tense after garbage collection, you can discard the objects. many of the system's caching capabilities are consistent with this scenario.

(2) "citation" new concept

After JDK1.2, Java extends the concept of references into strong references (strong Reference), soft references (Soft Reference), weak references (Weak Reference), virtual references (Phantom Reference) 4 species, the reference strength in turn gradually weakened. 4 references are explained below:

• Strong reference : refers to a general existence in a program, similar to Obejct obj = new Object() such a reference. as long as a strong reference exists, the garbage collector never reclaims the referenced object.

• Soft references: used to describe some objects that are useful but not necessary. For objects associated with soft references, these objects are listed for a second collection before the system will have a memory overflow exception. If this collection does not have enough memory, a memory overflow exception will be thrown. after JDK1.2, the SoftReference class is provided to implement the soft reference.

• Weak references: also used to describe non-required objects, but its 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 is working, the objects associated with a weak reference are reclaimed regardless of whether the current memory is sufficient. after JDK1.2, the WeakReference class is provided to implement the weak reference.

• Virtual references: also known as Phantom references or Phantom references (a good name for HHH), it is the weakest reference relationship. whether an object has a virtual reference exists, does not affect its lifetime at all, and cannot obtain an object instance through a virtual reference . The only purpose of setting a virtual reference association for an object is to be able to receive a system notification when the object is reclaimed by the collector. after JDK1.2, the Phantomreference class is provided to implement the virtual reference.

4. To survive or to die?

To being or not to being, this is a question.

(1) The process of "death" of the Sentenced object

Pull away, back to the text. Even those unreachable in the Accessibility analysis algorithm are not sentenced to "death", they are temporarily in the "probation" stage, to really declare an object "death", at least two times to go through the marking process:

• First token: if the object discovers that there is no reference chain connected to the GC roots after the accessibility analysis, it will be first marked and filtered, and the condition is whether this object is necessary to execute the finaliza() method.
• Second token: when the object has no overwrite finaliza() method, or the finaliza() method has been called by the virtual machine, the virtual machine treats both cases as "no need to execute".

(2) Finaliza () Method-Object escapes the last chance of "death"

If this object is judged to be necessary to execute the finaliza() method, then this object will be placed in a queue called f-queue and then executed by a low-priority Finalizer thread that is automatically established by a virtual machine later. The so-called " execution " here means that the virtual opportunity triggers this method, but does not promise to wait for it to end, because if an object executes slowly in a finaliza() method, or if a dead loop (more extreme) occurs, it is likely to cause F-queue other objects in the queue are permanently waiting, and even the entire memory-recycling system crashes.

finaliza()Method is the last chance for an object to escape the fate of death, and later the GC will mark the second small scale for the objects in the f-queue queue. If an object wants to finaliza() successfully save itself in a method, simply re-associate with any object on the reference chain, such as assigning itself (the This keyword) to a class variable or a member variable of an object, so that it will be moved out of the collection that is "about to be recycled" at the second mark If the object is not yet escaped, it is basically recycled.

(3) Proof of self-salvation of the object

The following code shows an example of an object finaliza() being executed, but it can still survive:

"A demonstration of the self-salvation of a single object"/** * This code demonstrates two points: * 1. Objects can be saved by the GC itself. * 2. This chance of self-help is only one time, because the Finalize () method of an object is called only once by the system automatically *@author ZZM * *PublicClassFINALIZEESCAPEGC {Publicstatic FINALIZEESCAPEGC Save_hook =NullPublicvoidIsAlive () {System.out.println ("Yes, I am still alive:)");}@OverrideProtectedvoidFinalize ()Throws Throwable {Super.finalize (); System.out.println ("Finalize Mehtod executed!"); Finalizeescapegc.save_hook =This }PublicStaticvoidMain (string[] args)Throws Throwable {Save_hook =New FINALIZEESCAPEGC ();//object for the first time successfully saved himself Save_hook = null; System.GC (); //because the finalizer method has a low priority, pausing for 0.5 seconds to wait for it to Thread.Sleep (500); if (save_hook! = null) {save_hook.isalive ();} else {System.out.println (" No, I am dead:(");} //the code below is exactly the same as above, but this time the rescue failed Save_hook = null; System.GC (); //because the finalizer method has a low priority, pausing for 0.5 seconds to wait for it to Thread.Sleep (500); if (save_hook! = null) {save_hook.isalive ();} else {System.out.println (" No, I am dead:(");}}     

1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• Ten
• one
• 2
• (
• )
• +
• +
• /
• 0
• +
• all
• +
• +
• +
• -
• 29
• +
• +
• all
• +
• +
• PNS
• up
i>39
• 48
• all
• /
• /
• /
• /li>

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21st
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30
• 31
• 32
• 33
• 34
• 35
• 36
• 37
• 38
• 39
• 40
• 41
• 42
• 43
• 44
• 45
• 46
• 47
• 48

Operation Result:

finalize method executed!yes, i am still alive :)no, i am dead :(

• 1
• 2
• 3

• 1
• 2
• 3

Results Analysis:

From the above results, the method of theSave_hook object finalize() was actually triggered by the GC collector and was successfully escaped before being collected.

Another noteworthy area, the code has two pieces of the same code snippet, the result is a successful escape, a failure. this is because the method of any one object is finalize() only called once by the system, and if the object faces the next collection, its finalize() method will not be executed again, so the second escape fails.

(4) Recommendations for the Finaliza () method

In particular, the above finalize() description of the method of object death is tragic, and the author does not recommend that developers use this method to save the object. You should avoid using it as much as possible, as it is not a destructor in C + +, but rather a compromise that is made easier for C + + programmers to accept when Java is first born. It is expensive, uncertain, and does not guarantee the sequence of calls to individual objects.

Some textbooks describe its suitability for "shutting down external resources", which is a self-comforting way to use this method. finalize() can do the work, use try-finally or other methods are more suitable and timely, so the author suggested that you can forget this method exists.

5. Recycling Method Area

(1) Garbage collection

Most people think that the method area is not garbage collected, the Java Virtual Machine specification does say no, and the "Price/performance" of garbage collection in the method area is low: in the heap, especially in the Cenozoic, a garbage collection can reclaim 70%~95% space in a regular application. And the efficiency of the method area is much lower than this.

Garbage collection in the method area mainly recycles two parts: obsolete constants and useless classes.

(2) Recycling of "obsolete constants"

Reclaiming obsolete constants is very similar to reclaiming objects in the Java heap . take the collection of literals in a constant pool as an example, for example, a string "ABC" has entered a constant pool, but no string object references this constant of a constant pool, and there is no other reference to this literal, at which point the "ABC" constant is cleared out of the constant pool by the system. The same is true of other classes (interfaces), methods, and field symbol references in a constant pool.

(3) Conditions for recycling "useless"

It is relatively simple to determine whether a constant is an "obsolete constant", and it is more demanding to determine whether a class is a "useless class", which requires the following 3 conditions:

• All instances of the class have been reclaimed, that is, no instances of the class exist in the Java heap.
• The ClassLoader that loaded the class has been reclaimed.
• The corresponding Java.lang.Class object of this class is not referenced anywhere, and the method of the class cannot be accessed by reflection.

Virtual machines can be recycled with useless classes that meet the 3 conditions above, and only say "yes", not as "objects" are necessarily recycled.

(4) Note

Scenarios in which a large number of bytecode frameworks, such as reflection, dynamic proxies, Cglib, dynamically generated JSPs, and OSGi are frequently customized ClassLoader require virtual machines to have class offload capabilities to ensure that the method area does not overflow.

This chapter on the content of learning is very abundant, the object of the survival of the two algorithms, the concept of reference and method area recovery, especially two algorithms, interview often involves, readers need to pay attention to understanding learning.

If there is a mistake, please feel free to advise ~

JVM Advanced Features and Practices (ii): Object Survival decision algorithm (reference) and recycling