Good uses of the finalize() method [duplicate]

2019-02-16 08:32发布

问题:

This question already has an answer here:

  • Why would you ever implement finalize()? 21 answers

This is mostly out of curiosity.

I was wandering if anyone has encountered any good usage for Object.finalize() except for debugging/logging/profiling purposes ?

If you haven't encountered any what would you say a good usage would be ?

回答1:

If your Java object uses JNI to instruct native code to allocate native memory, you need to use finalize to make sure it gets freed.



回答2:

Late to the party here but thought I would still chime in:

One of the best uses I have found for finalizers is to call explicit termination methods which, for what ever reason, were not called. When this occurs, we also log the issue because it is a BUG!

Because:

  • There is no guarantee that finalizers will be executed promptly (or technically at all), per the language specification
  • Execution is largely dependent on the JVM implementation
  • Execution can sometimes be delayed if the GC has a lower thread priority

This leaves only a handful of tasks that they can address without much risk.



回答3:

  1. close external connections (db, socket etc)
  2. close open files. may be even try to write some additional information.
  3. logging
  4. if this class runs external processes that should exist only while object exists you can try to kill them here.

But it is just a fallback that is used is "normal" mechanism did not work. Normal mechanism should be initiated explicitly.



回答4:

Release resources that should be released manually in normal circumstances, but were not released for some reason. Perhaps with write a warning to the log.



回答5:

I use it to write back data to a database when using soft references for caching database-backed objects.



回答6:

I see one good use for finalize(): freeing resources that are available in large amounts and are not exclusive.

For example, by default there are 1024 file handles available for a Linux process and about 10000 for Windows. This is pretty much, so for most applications if you open a file, you don't have to call .close() (and use the ugly try...finally blocks), and you'll be OK - finally() will free it for you some time later. However for some pieces of code (like intensive server applications), releasing resources with .close() is a must, otherwise finally() may be called too late for you and you may run out of file handles.

The same technique is used by Swing - operating system resources for displaying windows and drawing aren't released by any .close() method, but just by finalize(), so you don't have to worry about all .close() or .dispose() methods like in SWT for example.

However, when there is very limited number of resources, or you must 'lock' resource to use it, also remember to 'unlock' it. For example if you create a file lock on a file, remember also to remove this lock, otherwise nobody else will be able to read or write this file and this can lead to deadlocks - then you can't rely on finalize() to remove this lock for you - you must do it manually at the right place.