Home  >  Article  >  Java  >  Introduction to methods to prohibit the use of finalize in Java

Introduction to methods to prohibit the use of finalize in Java

黄舟
黄舟Original
2017-10-14 09:37:551203browse

This article mainly introduces the prohibition of using the finalize method in Java. Friends who need it can refer to it

What is the finalize method

finalize The () method is defined in the Java.lang.Object class, which means that all classes can override this method. The Java garbage collector can only release memory allocated through new, so if your object is not a memory obtained through new, then the garbage collector does not know how to release the memory of the object.

In order to deal with this situation, java allows the finalize() method in the java.lang.Object class to be overloaded in the class.

How it works: Once the garbage collector is ready to release the storage space occupied by the object, its finalize() method will first be called, and the memory occupied by the object will not be actually reclaimed until the next garbage collection action occurs. .

The calling mechanism of the finalize function

The Java virtual machine specification does not strictly stipulate whether garbage collection should be performed and how it should be performed. Therefore, the calling mechanism mentioned here is not guaranteed to be suitable for all JVMs.

When is it called?

When will finalize be called? Generally speaking, it may not be called until the JVM starts garbage collection. The time point at which the JVM performs garbage collection is very uncertain and depends on various runtime environmental factors. It is precisely because of the uncertainty of the finalize function calling time that it leads to some of the shortcomings mentioned later.

Who will call?

A common JVM will call the finalize function through the GC's garbage collection thread. Since the garbage collection thread is very important (it is also an integral part of the JVM after all), 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 perform a try catch when calling each finalize function. If When an exception is caught, it is discarded directly, and then the finalize function of the next invalid object is processed.

Why is it forbidden to use finalize()

1. The calling time is uncertain---there is a risk of wasting resources

The calling mechanism has been introduced earlier. Students should recognize the fact that "the timing of calling finalize is very uncertain". Therefore, if you release some scarce resources in finalize(), it may cause the scarce resources to wait for a long, long, long time before being released. This is a waste of resources! In addition, the resources carried by certain class objects (such as some JDBC classes) may themselves consume a lot of memory, and the delayed release of these resources will cause great performance problems.

2. May not be called - there is a risk of resource leakage

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

It is estimated that some students are thinking of "runFinalizersOnExit" to ensure that all finalizes are called before the JVM exits. It is a pity and regret that this method has been abandoned since JDK 1.2. Even if this method is not abandoned, it still has a huge thread safety hazard!

As can be seen from the above, once you rely on finalize() to help you release resources, that is very bad (there is a risk of resource leakage)! Many times, performance problems caused by resource leaks are more serious and should not be underestimated.

3. The object may be resurrected when the finalize function is called.

Originally, the garbage collector will call the object only when it has expired (no reference). finalize function. However, if you encounter a perverted programmer, re-saving the reference to the object itself (that is, this) somewhere inside the finalize() function is equivalent to resurrecting yourself (because the object has new reference and is no longer in an invalid state). In order to prevent this weird thing from happening, the garbage collector can only check whether the object is still in an invalid state after each call to finalize(). This virtually increases the overhead of the JVM. Just mention it casually. As the JDK documentation stipulates, the JVM will only call finalize() at most once for each class object instance. Therefore, for those instances of fake corpses, finalize() will not be called when they actually die. Doesn't this seem weird?

4. Remember to catch exceptions yourself

Just mentioned when introducing the finalize() calling mechanism, 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 (the dangers of ignored exceptions are mentioned "here"). In order to prevent this kind of thing, you have to write a try catch statement for any code that may throw an exception in finalize() and catch it yourself.

5. Be careful about thread safety

Since finalize() is called by a garbage collection thread, it is not the same thread as your own code; even finalize() of different objects may be called by different garbage collection threads (such as using a "parallel collector" when). Therefore, when you access certain data in finalize(), you must always pay attention to thread safety issues.

Summarize

The above is the detailed content of Introduction to methods to prohibit the use of finalize in Java. For more information, please follow other related articles on the PHP Chinese website!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn