This is the 20th day of my participation in the August More Text Challenge

preface

Avoid Finalizer (deprecated in Java 9) and Cleaner (replaced by Finalizer in Java 9). The reason is simple: Finalizers are unpredictable, often dangerous, and generally unnecessary. Cleaner is less dangerous than Finalizers, but it is still unpredictable, can slow down applications, and is generally not necessary.

In Java, when an object becomes unreachable, the garbage collector reclaims the storage associated with the object, requiring no special work by the programmer. Those that must be closed manually are typically reclaimed in Java with a try-with-Resources or try-finally block.

disadvantages

Timely execution cannot be guaranteed

One of the disadvantages of Finalizers and cleaners is that there is no guarantee that they will be executed ina timely manner. There is no guarantee of the time it takes from the time an object becomes unreachable until its Finalizer or Cleaner is executed. That means out of control! You should not perform any time-critical tasks in Finalizers and Cleaners.

Platform implementations vary greatly

Although garbage collection algorithms should execute Finalizers and cleaner ina timely manner, there are significant differences between JVM implementations. The test may well, the results on the user’s server is not.

Can arbitrarily delay the collection of instances of that class

www.cnblogs.com/zhaoxinshan… As mentioned above, memory overflow was reported after finalizer was added. The reason is that adding finalizers to a class arbitrarily delays the collection of instances of that class. When the Finalizer thread has a lower priority than other threads in the program, objects are terminated as quickly as they enter the finalizer state.

No guarantee of execution

Not only does the Java language specification not guarantee that Finalizers or cleaners will be executed ina timely manner, it doesn’t even guarantee that they will be executed. It is also entirely possible that when a program terminates, some finalizers for objects that are no longer accessible are not executed at all. So never rely on Finalizers or cleaner to update important persistent states.

Thrown exceptions that are not caught are ignored

Another problem with Finalizer is that exceptions thrown during finalization that are not caught are ignored and the object’s finalization process terminates. Uncaught exceptions are not only difficult to troubleshoot, but also result in potentially incomplete objects. If other threads try to use these incomplete objects, arbitrary and unpredictable behavior can result. Normally, uncaught exceptions terminate the thread and print the entire stack error. Finalizer doesn’t do this because the error is ignored and it doesn’t even print a warning message. Cleaner does not have this problem, because the library that uses Cleaner can control its thread.

Serious performance loss

Using finalizers or cleaners can cause serious performance losses. Using try-with-Resources to close it and let the garbage collector collect it takes many times less time than finalizer.

use

To be the last line of defense

The first use of finalizers is when the owner of the object forgets to call the close method recommended in the previous section. While there’s no guarantee that Finalizers or cleaner will run in time (or at all), they can serve as a later line of defense in the event that the client doesn’t end up working properly. If you are considering writing such a Finalizer, consider whether it is worth it. Some Java library classes, such as FileInputStream, FileOutputStream, ThreadPoolExecutor, and java.sql.Connection, use Finalizer as a backstop to prevent users from forgetting to close the resource.

Reclaim a local peer

The second legitimate use of Cleaner is related to the object’s native peer. A local peer is a native object. A common object is delegated to a local object through a native method. Because a local peer is not an ordinary object, the garbage collector does not know it exists, so it is not collected when its Java peer is collected. Assuming application performance is acceptable and the local peer does not contain critical resources, finalizers or cleaner may be useful. If performance does not allow or if the local peer holds resources that must be reclaimed in a timely manner, you should add the close method recommended in the previous paragraph to the class.

conclusion

In general, do not use Cleaner or Pre-Java 9 Finalizers except as a safety net or to terminate non-critical local resources. Even then, beware of uncertainty and performance impact.

The ultimate solution

You can have your class implement the AutoCloseable interface and require the class’s clients to call the close method when each instance is no longer needed, usually using try-with-resources to ensure normal termination even if an exception occurs. One notable detail is that instances must keep track of whether or not they are closed: the close method must record in a domain that the object is no longer valid, and if other methods on the object are called after the object is closed, they must check the domain and throw an IllegalStateException.