On 21.10.2013 13:09, Heiko W. Rupp wrote:
> Am 21.10.2013 um 11:34 schrieb Vitalii Tymchyshyn:
>> Note that removing finalizers without introducing some other mechanism, like reference queues, would introduce
serverside leaks on poorly written yet correct applications!
>
> Server side leaks are introduced the moment that you rely on a finalizer being called (close to the time the object
isno longer needed).
> Per JLS, the finalizers are a) not guaranteed to ever run, b) run in any specific order c) at any given time.
>
> And the other mechanisms exist -- close() calls. Software that relies on the finalizer for this cleanup may show
unpredictable
> behavior.
If we can't get rid of the finalizer completely, I wonder if we could
arrange things so that we could avoid the finalizer overhead when there
are server-side resources associated with the statement. I would guess
that in most cases that you don't close a Statement properly, it's a
very short-lived Statement used to run a single query. Such a statement
will typically not have any server-side resources associated with it.
Actually, we already seem to use PhantomReferences to clean up orphaned
SimpleQuery and Portal objects. AFAICS those are the things that
actually represent server-side resources. Why do we even have a
finalizer in AbstractJdbc2Statement? Perhaps we used to rely on the
finalizer to clean up things, but later added the more fine-grained
PhantomReferences to the underlying objects, making the finalizer redundant?
> Another reason to get rid of finalize() methods is that Object creation is several hundred times slower with the
finalize()
> methods present, as not only the Statement etc. is created, but also the Finalizer and the later needs to be put on
thefinalizer
> queue. Josh Bloch talks about 5.6ns vs 2400ns for a simple object in "Effective Java, 2nd edition".
> That is a penalty everyone has to pay - even if they close Statements etc correctly.
That's still negligible compared to sending a statement to the remote
host and getting the result back, though.
- Heikki