JVM garbage collection mechanism (i) the decision of recovering objects

On the JVM garbage collection mechanism, we generally do not go too far, because Java and C + + is a big difference is that Java to help us to do garbage collection, and not like C + + as the kind of manual recycling, of course, any automatic things have some drawbacks, such as robots, even if the high degree of automation, But in dealing with certain emotional problems, there will be some omissions in the processing, a joke, let's start with a look at the JVM garbage collection is going on.

First, how to judge the object has died

The JVM reclaims objects that are not in use, or objects that are already dead, to save space, so we are sure to judge which objects are dead and not used?

1 Reference Counting algorithm:

This algorithm is very simple, that is, when our object is not referenced, there is a counter, such as Count, will count + +, similarly, if the applied object is set to null, then count--, until Count = 0. When the JVM is recycled, he will find the object count = 0, which is not used by default and is recycled.

This algorithm, in theory, is very good, but when the object is referenced by the time can not be carried out, for example: A class, there is a B class in the reference B, while the Class B has a class A reference a, when we also a a= new A (), b b = new B (); This is a strong reference, will count + +, when we let the inside reference a.b =b,b.a=a, then the second quote, Count becomes 2, if you let

A =null,b =null,count--When we recycle, we find count = 1; The JVM will not be recycled, then it will waste memory, which is also the main disadvantage of the reference counting algorithm, here also by the way analysis of this algorithm:

1. A separate field storage counter is required to increase the overhead of storage space;

2. Each assignment needs to update the counter, increasing the time overhead;

3. The garbage object is easy to identify, as long as the counter is 0, it can be used as garbage collection;

4. timely recovery of waste, no delay;

5. The problem of circular references cannot be resolved;

2 Accessibility Analysis algorithm

This algorithm can be the object of circular reference problem, the basic principle is: Through a "GC root" root object as a starting point, and then search down the node, the search path is called the reference chain, that is, we often say the reference, when we can not find any path connected to the object of the case can be determined to be recycled, This is the same as the object can not find home, here refer to the JVM diagram:

2.1 GC ROOT The range of objects collected includes:

A. Objects referenced in the virtual machine stack (local variable table in the stack frame)

B. Objects referenced by class static properties in the method area

C. Objects referenced by constants in the method area

D. Objects referenced by Jni (native method) in the local method stack

About the distribution of some of the stack method areas, later, you can refer to:

http://www.360doc.com/content/11/0504/12/3903749_114271703.shtml

Although there is an accessibility analysis algorithm to determine the state of the object, but this is not the condition of whether the object is recycled, the condition of object recycling is far more complex than this, such as the object can not be found through root, it will not necessarily be recycled, will enter a reprieve stage, those cannot be found through the root node reference chain objects, will be the first And a filter, the filter condition is whether this object is necessary to execute the Finalize () method, when the object does not overwrite the Finalize () method, or if the Finalize () method has been called by the virtual machine, and the virtual machine is considered "no need to execute".

If the object is judged to be necessary to perform finalize (), then the object is placed in a f-queue queue and executed by a lower priority finalizer thread, where the JVM fires the method, but does not guarantee that it will wait for his run to finish. Because the Finalize () method executes slowly, or a dead loop, it affects the execution of other elements of the queue.

The Finalize () method executes a second token, waits for the JVM to recycle, and while the Finalize () method executes, the object can be "rescued", that is, within the execution method, the object is again referenced, then the object is resurrected, looking at the code:

Java code

2. Package com;
6. Import Java.lang.reflect.Method;
10. Import Org.springframework.cglib.proxy.MethodInterceptor;
12. Import Org.springframework.cglib.proxy.MethodProxy;
18. Public class finalizegc{
22. public static FINALIZEGC save_gc = null;
26. public static void Main (string[] args) throws interruptedexception {
28. SAVE_GC = new FINALIZEGC ();
30. //Break off the reference chain
32. SAVE_GC = null;
34. //Call Finalize recovery, inside a rescue operation
36. System.GC ();
38. //Finalize priority is low, pause for 0.5 seconds wait for him to execute
40. Thread.Sleep (500);
42. System.out.println ("The object state is--->" +save_gc);
46. //The code above, but has been saved invalid
48. SAVE_GC = null;
50. System.GC ();
52. Thread.Sleep (500);
54. System.out.println ("The object state is--->" +save_gc);
58. }
64. //Override this method
66. @Override
68. protected Void Finalize () throws Throwable {
70. super.finalize ();
72. System.out.println ("The Finalize method is being implemented");
74. //New references
76. FINALIZEGC.SAVE_GC = this ;
78. }
80. }
86. Results:
88. Executing Finalize method
90. The object state is--->com. FINALIZEGC@c17164
94. The object state is--->null

As you can see, Finalize was executed at the time of the GC, and the object was saved, but the discovery was executed only once, and it was saved only once, so there was a value, and one was null. Here you can see that the JVM's Finalize () of the object is only executed once, In this case, it is not recommended to override this method because it interferes with the object's recycling call mechanism and is expensive to run.

In addition to the above-mentioned objects, there are a number of discarded constant recycling, such as: There is a string "ABC" has entered the constant pool, but the current system does not have any place to reference the object, the constant will be cleared constant pool.

There are also discarded classes, or useless classes that are recycled, and some of the criteria here are:

A. All instances of this class have been reclaimed, that is, no instances of the class exist in the Java heap

B. The classloader that loaded the class have been recycled

C. The Java.lang.Class object of this class does not have any place to invoke the method of accessing the class by reflection anywhere.

Summary:

1. Here are just a few of the methods and conditions for determining whether some Java objects can be recycled

2. There are some algorithms for garbage collection and garbage collector, these are to describe how the JVM organizes these outdated objects distributed in memory, how to do the bulk of the mobile phone deletion work, this later explain it.

JVM garbage collection mechanism (i) the decision of recovering objects