大佬教程收集整理的这篇文章主要介绍了Debugging to Understand Finalizer--reference，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
This post is covering one of the Java built-in concepts called Finalizer. This concept is actually both well-hidden and well-known,depending whether you have bothered to take a look at the java.lang.Object class thoroughly enough. Right in the java.lang.Object itself,there is a method called finalize(). The implementation of the method is empty,but both the power and dangers lie on the JVM internal behaviour based upon the presence of such method.
When JVM detects that class has a finalize() method,magic starts to happen. So,lets go forward and create a class with a non-trivial finalize() method so we can see how differently JVM is handling objects in this case. For this,lets start by constructing an example program:
The example is creating new objects in an unterminated loop. These objects use static aliveCount variable to keep track how many instances have already been created. Whenever a new instance is created,the counter is incremented and whenever the finalize() is called after GC,the counter value is reduced.
So what would you expect from such a simple code snippet? As the newly created objects are not referenced from anywhere,they should be immediately eligible for GC. So you might expect the code to run forever with the output of the program to be something similar to the following:
Apparently this is not the case. The reality is completely different,for example in my Mac OS X on JDK 1.7.0_51,I see the program failing with just about after ~1.2M objects have been created:
To understand what is happening,we would need to take a look at our example code during the runtime. For this,lets run our example with -XX:+PrintGCDetails flag turned on:
From the logs we see that after just a few minor GCs cleaning Eden,the JVM turns to a lot more expensive Full GC cycles cleaning tenured and old space. Why so? As nothing is referring our objects,shouldn’t all the instances die young in Eden? What is wrong with our code?
To understand,the reasons for GC behaving as it does,let us do just a minor change to the code and remove the body of the finalize() method. Now the JVM detects that our class does not need to be finalized and changes the behaviour back to “normal”. Looking at the GC logs we would see only cheap minor GCs running forever.
In our original example on the other hand,the situation is different. Instead of objects without any references, JVM creates a personal watchdog for each and every one of the Finalizableinstances. This watchdog is an instance of Finalizer. And all those instances in turn are referenced by the Finalizer class. So due to this reference chain,the whole gang stays alive.
Now with the Eden full and all objects being referenced,GC has no other alternatives than to copy everything into Survivor space. Or worse,if the free space in Survivor is also limited,then expand to the Tenured space. As you might recall,GC in Tenured space is a completely different beast and is a lot more expensive than “lets throw away everything” approach used to clean Eden.
Only after the GC has finished,JVM understands that apart from the Finalizers nothing refers to our instances,so it can mark all Finalizers pointing to those instances to be ready for processing. So the GC internals add all Finalizer objects to a special queue atjava.lang.ref.Finalizer.ReferenceQueue.
Only when all this hassle is completed our application threads can proceed with the actual work. One of those threads is now particularly interesting for us – the “Finalizer” daemon thread. You can see this thread in action by taking a thread dump via jstack:
<a class="item printSource" title="print" href="http://java.dzone.com/articles/debugging-understand-finalizer#printSource">print<a class="item about" title="?" href="http://java.dzone.com/articles/debugging-understand-finalizer#about">?
From the above we see the “Finalizer” daemon thread running. “Finalizer” thread is a thread with just a single responsibility. The thread runs an unterminated loop blocked waiting for new instances to appear in java.lang.ref.Finalizer.ReferenceQueue queue. Whenever the “Finalizer” threads detects new objects in the queue,it pops the object,calls the finalize() method and removes the reference from Finalizer class,so the next time the GC runs the Finalizer and the referenced object can now be GCd.
So we have two unterminated loops now running in two different threads. Our main thread is busy creating new objects. Those objects all have their personal watchdogs called Finalizer which are being added to the java.lang.ref.Finalizer.ReferenceQueue by the GC. And the “Finalizer” thread is processing this queue,popping all the instances from this queue and calling the finalize() methods on the instances.
Most of the time you would get away with this. Calling the finalize() method should complete faster than we actually create new instances. So in many cases,the “Finalizer” thread would be able to catch up and empty the queue before the next GC pours more Finalizers into it. In our case,it is apparently not happening.
Why so? The “Finalizer” thread is run at a lower priority than the main thread. In means that it gets less CPU time and is thus not able to catch up with the pace objects are being created. And here we have it – the objects are created faster than the “Finalizer” thread is able to finalize() them,causing all the available heap to be consumed. Result – different flavours of our dear friend.
If you still do not believe me,take a heap dump and take a look inside. For example,when our code snipped is launched with -XX:+HeapDumpOnOutOfMemoryError parameter,I see a following picture in Eclipse MAT Dominator Tree:
So to recap,the lifecycle of Finalizable objects is completely different from the standard behaviour,namely:
Moral of the story? Next time,when you consider finalize() to be superior to the usual cleanup,teardown or finally blocks,think again. You might be happy with the clean code you produced,but the ever-growing queue of Finalizable objects thrashing your tenured and old generations might indicate the need to reconsider.
reference from :http://java.dzone.com/articles/debugging-understand-finalizer
以上是大佬教程为你收集整理的Debugging to Understand Finalizer--reference全部内容，希望文章能够帮你解决Debugging to Understand Finalizer--reference所遇到的程序开发问题。