Re: Finalizers

[Darrell Teague <da...@mantech.com>]

Two more cents on this topic...

Joshua Bloch of Sun and many others (myself included) have argued that reliance on finalizers for anything other than a last-ditch clean-up effort is not recommended.  Instead, it is recommended that any resource consuming classes (i.e., that open socket, file, database connection, whatever) provide some type of "close" method that should (in practice) be called by the client.  Granted, there is no way to ensure the client will call such a method but the finalize() method is not guaranteed to happen, in the sequence expected, etc either.  At least with a declared public method, clients can be guaranteed a tidy clean-up process (if they call it) whereas reliance on finalizers may be non-deterministic since the JVM implementation and other factors beyond the developers control determine the sequence, behavior, priority, etc of the call to finalize(). 

>>> don@bea.com 09/30/03 01:12PM >>>
As you may already know, finalizers must be used with extreme caution.  
Because they are run by in the GC thread (when all other threads are 
paused) if a finalizer deadlocks, the entire VM will be frozen.  This 
makes using synchronization in a finalizer particularly dangerous.  
There are also problems around any operations that allocate memory in a 
finalizer.

(Note: my information may be out of date).

    -Don

David Bau wrote:

>Eric, was thinking about the threading/object creation etc issues over the
>weekend.
>
>Another interesting issue: currently we use a finalizer on cursors, but
>finalizers seem to be fairly expensive, so apps that spew out lots and lots
>of cursors have issues.  I wonder what problems we'd have to deal with in
>order to eliminate the finalizer, and whether or not that would be possible,
>or if it would come into conflict with some of the other parameters of the
>problem just like synchronization?
>
>David
>
>
>- ---------------------------------------------------------------------
>To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
>Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
>
>
>
>  
>


- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/