Whenever asked to JVM (Java Virtual Machine) is usually 99% probability will ask: how to determine an object's state of life and death in the JVM?
In this paper, to talk about this issue of life and death algorithm to determine the state of the object are the following:
1, the reference counter algorithm
Reference calculator determines whether the survival of the subject algorithm is this: for each object is provided a reference counter, whenever a local time reference to the object, the counter is incremented, contrary, whenever reference is decremented failure 1.
Advantages: simple, high performance.
Disadvantages: Frequent consumption increase or decrease processing computing cpu, counter bits take up a lot of wasted space, the most important disadvantage is that the problem can not be solved circular references.
Because the reference counter algorithm is very difficult to solve the problem of circular references, so the mainstream Java virtual machine does not use reference counting algorithm to manage memory.
Run results:
Start: 117 M
Run: 96 M
End: 119 M
As can be seen from the results, the virtual machine does not refer to each other because they do not recycle, but also the side that virtual machines are not using the reference counter implemented.
2, reachability analysis algorithm
Mainstreaming in the mainstream languages, such as Java, C #, or even whether reachability analysis algorithm ancient Lisp objects are used to determine survival.
The core idea of this algorithm is through a series of "GC Roots" objects as a starting point, from these objects down to start the search, the search path through called " chain of references ."
When an object is no time to GC Roots coupled referenced chain proved to be an object can be recycled. As shown below:
In Java, as GC Roots list of objects:
-
Object reference Java Virtual Machine stack.
-
Native method stack JNI (both general said Native Method) object references.
-
Class method static constant region of the reference object.
-
Reference object literal approach area.
Object reference relationship with life and death
From the above two algorithms view, whether it is a reference counting method or reachability analysis algorithms and "reference" object-related, indicating that: life and death decisions cited target object.
That reference to the object are those who do?
Before JDK1.2, cited definition is very traditional: If the reference value represents the type of data stored is the starting address of another piece of memory, this memory is said to represent a reference.
This definition is very pure, but also very narrow, in which case the object is either a reference or no reference to the range between the two objects is powerless.
JDK1.2 after a reference was expanded into the quote:
-
A strong reference (Strong Reference)
-
Soft references (Soft Reference)
-
Weak references (Weak Reference)
-
Virtual reference (Phantom Reference)
This is the answer to the first question of the beginning of the article, an object that is not a non-life death, when the space is also enough, you can also keep these objects
If space is insufficient, then abandon these objects. Many implement caching functionality is also consistent with such a scenario.
Strong references, soft, weak, reference phantom reference, these four references are in descending order of intensity.
Strong Quote: ubiquitous in the code, similar to the "Object obj = new Object ()" such a reference, as long as the reference is still strong, the garbage collector never recovered off the object being referenced.
Soft references: a weakening of relatively strong references cited a number, you can make objects exempt some garbage collection only when jvm deemed insufficient memory, only to attempt to recover the soft reference object pointing. jvm will ensure that before throwing OutOfMemoryError, clean up the soft reference object pointing.
Weak references: non-essential objects, but its strength is weaker than the soft references, objects are associated with weak references can only survive to take place before the next garbage collection.
Virtual reference: also known as ghost or phantom cited references, a reference relationship is weakest, can not obtain the object instance by a virtual reference, the virtual object is provided only a reference to an object, the object is to be recovered in the presence of a collector upon receipt of a notification system.
Marked for Death and Salvation
Unreachable reachability algorithm objects, not "Feisibuke", to really declare an object death, at least to go through the process twice marker.
After performing the reachability analysis if the object is not referenced GC Roots chain connected, it will be the first mark, and screening with the proviso that if the object is necessary to perform finalize () method.
Two conditional execution finalize () method:
1, the rewrite finalize () method.
2, before the finalize () method have not been called, because the object's finalize () method can only be executed once.
If these two conditions are met, this object will be placed in the F-Queue queue and perform it at a later self-built by a virtual machine, low priority Finalizer thread.
"Self-rescue" object
finalize () method is the last chance the object from the fate of death, if an object finalize () method can be re-associated with any object on the chain of references, such as his own (this keyword) is assigned to a variable or class member variable objects.
Look at specific implementation code:
Execution of results:
Execution finalize method
I am still alive
I am already dead
As can be seen from the results, finalize any object () method will only be called once the system.
Not recommended finalize () method to save the object, for the following reasons:
1, finalize the object () can only be performed once.
2, it is costly to run.
3, large uncertainty.
4, can not guarantee the order in which the calling object.
END