Java performance optimization [4]: About finalize Functions

The last post talked about the optimization of the garbage collector. After a long time, I didn't continue to talk about finalize (in fact, this is a bit of a problem with GC ). Today, let's take a look at the performance topics related to finalize functions.

★Call mechanism of finalize Function
I often read about the importance of essential mechanisms. So today we have to talk about the finalize function calling mechanism. Before talking about it, I would like to explain: Java Virtual Machine specifications (see "here"), and there is no rigid rule on whether garbage collection should be done or how to do it. So the finalize function calling mechanism mentioned here may be applicable to most JVMs, but it cannot be guaranteed to be applicableAll.
◇ When will it be called?
When will finalize be called? Generally, it will not be until the JVM starts garbage collection.PossibleCalled. The time for JVM garbage collection isVeryUncertain, depending on various runtime environment factors. For details, see "previous post in this series ". It is precisely because of the uncertainty of the finalize function call time point that some shortcomings are mentioned later.
◇ Who will call it?
When to call it, let's talk about who called it?
The common JVM calls the finalize function through the garbage collection thread of GC. The garbage collection thread is important (which is also an integral part of JVM). To prevent exceptions thrown by the finalize function from affecting the operation of the garbage collection thread, the garbage collection thread performs trycatch when calling each finalize function. if an exception is caught, it directly discards it and then processes the finalize function of the next Invalid object.

★Misunderstanding and misuse of finalize Functions
◇ Use finalize as a "destructor"
Students who have studied C ++ should know the "destructor" (those who do not know C ++ can skip this section ). The C ++ destructor is used when the object is out of scope,NowCalled. Many C ++-to-Java colleagues take it for granted that the finalize function is a C ++ destructor (the two do have some similarities ). However, the reality is often not so beautiful. Java finalize functions and C ++ destructor have manySignificantDifference, those who use finalize as the Destructor are destined to hit the wall (For details, refer to "disadvantages of finalize function" after this article ").
◇ Use finalize to release resources
Many hope to use finalize () to release some resources of class objects (such as closing database connections ). If you have such an attempt, please pay attention to the "disadvantages of the finalize function" mentioned later in this article "!

★Considerations for using the finalize Function
Some of the notes described below may have little to do with performance optimization.
◇ Uncertain call time-risks of resource waste
The call mechanism has been introduced earlier. Students should recognize"The call time of finalize is uncertain.. Therefore, if you release some scarce resources in finalize (), it may lead to the release of such scarce resources after a long time. This is a waste of resources! In addition, the resources carried by some class objects (such as some JDBC classes) may consume memory, and the delayed release of these resources may cause great performance problems.
◇ It may not be called-there is a risk of resource leakage
Many think that finalize ()Always YesCalled, but not actually. In some cases, finalize () cannot be called. For example, when the JVM exits, the finalize function of the objects in the memory may not be called.
It is estimated that some people will be playing the "runfinalizersonexit" idea to ensure that all finalize will be called before the JVM exits. Unfortunately, this method has been deprecated since JDK 1.2. Even if this method is not discarded, there is a great thread security risk! Those who tried to make this idea should die early.
It can be seen from the above that once you rely on finalize () to help you release resources, it is very bad (There is a risk of resource leakage)! I have mentioned the severity of resource leakage here. In many cases, the performance problems caused by resource leaks are even more serious.
◇ Objects may be revived when the finalize function is called-there is a risk of fraud
Corpse fraud is rare, but I 'd like to mention it a little bit.
Originally, the garbage collector will call the finalize function of an object only when the object has expired (not referenced. However, in case of an abnormal programmer, The finalize () function restores the reference of the object itself (that is, this) somewhere, this is equivalent to the resurrection of yourself (because this object has been referenced again and is no longer in the invalid state ). Is this abnormal?

To prevent such a strange situation, the garbage collector can only check whether the object is still in an invalid state after calling finalize. This increases the JVM overhead.
Just mention it. As stated in the JDK document (see here for details), JVM can call finalize () at most once for each class object instance (). Therefore, finalize () will not be called when the zombie instances actually die. Does this look strange?
◇ Remember to capture exceptions yourself
As mentioned in the introduction to the finalize () call mechanism, once an exception is thrown out of the finalize function, it will be captured and discarded by the garbage collection thread. That is to say, the exception is ignored (the danger of the exception being ignored is described here ). To prevent this, you have to write a try catch statement to catch any code that may throw an exception in finalize.
◇ Be careful with thread security
Because the call to finalize () is a garbage collection thread, it is not the same as the thread of your own code; or even the finalize () of different objects () it may be called by different garbage collection threads (for example, when "parallel Collector" is used ). Therefore, when you access some data in finalize (), you must always pay attention to thread security issues.

★Conclusion
I have spent so many words before, and I will summarize it a little later. I think: Finalize is really a weakness of Java. Maybe itVery fewIt is useful for programmers, but it is of no obvious benefit to most people (including yourself. Everyone should try not to use it.

Copyright Notice
All original articles in this blog are copyrighted by the author. This statement must be reprinted to keep this article complete, and the author's programming preferences and original addresses in the form of hyperlinks should be noted:

Http://program-think.blogspot.com/2009/06/java-performance-tuning-4-finalize.html