Shulou(Shulou.com)06/02 Report--

How to talk about Java performance optimization functions, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can gain something.

The calling mechanism of ★ finalize function

I often talk about: "the importance of understanding the essential mechanism." So today we have to talk about the calling mechanism of the finalize function. Before we chat, let's make it clear: the Java virtual machine specification does not dictate whether garbage collection should be done or not, and how to do it. So the finalize function calling mechanism I mentioned here may be applicable to most JVM, but it is not guaranteed to apply to all JVM.

When will ◇ be called?

When will finalize be called? Generally speaking, it is not possible for JVM to be called until it starts garbage collection. The timing of garbage collection by JVM is [very] uncertain, depending on a variety of runtime environmental factors. It is the uncertainty of the timing of the finalize function call that leads to some of the shortcomings mentioned later.

Who will call ◇?

When will it be called? let's go on to talk about who called it.

It is common for JVM to call finalize functions through GC's garbage collection thread. Because the garbage collection thread is more important (at least it is a part of JVM), in order to prevent the exception thrown by the finalize function from affecting the operation of the garbage collection thread, the garbage collection thread will try/catch each finalize function. If it catches an exception, it discards it directly, and then goes on to deal with the finalize function of the next invalid object.

★ 's misunderstanding and misuse of finalize function ◇ understands finalize as a "destructor"

Students who have studied C++ should know the "destructor" (students who do not understand C++ can just skip this section). The C++ destructor is called [immediately] as soon as the object leaves scope.

Many students who switch from C++ to Java will take it for granted that the finalize function of Java will become the destructor of C++ (there are some similarities between the two). However, the reality is often not so beautiful. Because there are many very [critical] differences between Java's finalize function and C++ 's destructor, those who use finalize as a destructor are doomed to hit a brick wall (see "shortcomings of the finalize function" later in this article).

◇ relies on finalize to release resources

Many students hope that through finalize () to complete the release of some resources in the class object (such as closing the database connection and so on).

For students with such an attempt, please pay attention to the "shortcomings of the finalize function" later in this article!

Considerations for ★ to use the finalize function

Some of the matters needing attention described below may have little to do with performance optimization, which I also list together.

◇ call time is uncertain-there is a risk of wasting resources

The invocation mechanism has been introduced earlier. Students should recognize the fact that the timing of finalize calls is very uncertain. So, if you release some scarce resource in finalize (), it may cause the scarce resource to wait a long time before it is released. This is a waste of resources!

In addition, the resources carried by some class objects (such as some JDBC classes) may themselves be memory-consuming, and the delayed release of these resources can cause significant performance problems.

◇ may not be called-there is a risk of resource leakage

Many students mistakenly think that finalize () will always be called, [it is not]. In some cases, finalize () is not called at all. For example, when JVM exits, the finalize functions of those objects in memory may not be called.

I figured: some students are thinking of "runFinalizersOnExit" to make sure that all finalize is called before JVM exits. Unfortunately, however, this method has been abandoned since JDK 1.2. Even if this method is not abandoned, there are great thread safety risks! For those of you who try to make up your mind, please die as soon as possible.

As can be seen from the above, once you rely on finalize () to help you release resources, that is not good ([danger of resource leakage])! In many cases, the performance problems caused by resource leakage are more serious and should not be underestimated.

The ◇ object may be resurrected when the finalize function is called-- there is a risk of faking corpses

Fraudulent corpses are relatively rare, but I'd like to mention them a little bit.

Originally, the garbage collector calls the finalize function of an object only if it has expired (there is no reference). However, if you encounter a perverted programmer, re-storing the object's own reference (that is, this) somewhere inside the finalize () function is tantamount to reviving itself (because the object is referenced again and is no longer in an invalid state). Isn't this sick enough: -)

To prevent this weird thing from happening, the garbage collector can only check again after each call to finalize () to see if the object is still in an invalid state. This virtually increases the cost of JVM.

Just by the way. As specified in JDK's documentation, JVM calls finalize () at most once per class object instance. So, for those instances of fraudulent corpses, finalize () will not be called when they actually die. Doesn't that look weird?

◇ should remember to do exception trapping yourself.

When introducing the finalize () call mechanism, I just mentioned that once an exception is thrown outside the finalize function, it will be caught and discarded by the garbage collection thread. In other words, the exception is ignored. To prevent this, you have to write a try catch statement to catch any code that may throw an exception in finalize ().

◇ should be careful of thread safety

Because finalize () is called by a garbage collection thread, it is not the same thread as the thread of your own code; even finalize () of different objects may be called by different garbage collection threads (for example, when using the "parallel collector"). So, when you access some data in finalize (), you have to keep an eye on thread safety.

I've wasted so many words in front of me, so let's sum it up a little bit. I thought: finalize is really the chicken rib of Java.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.