Re: Remove usage of finalizers ?
От | Heikki Linnakangas |
---|---|
Тема | Re: Remove usage of finalizers ? |
Дата | |
Msg-id | 52654590.1050600@vmware.com обсуждение исходный текст |
Ответ на | Re: Remove usage of finalizers ? ("Heiko W. Rupp" <hwr@pilhuhn.de>) |
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления: