Hi,
Confirmed, the design and implementation encapsulate the cleanup so it
can be run consistently
at-most-once either at close or when it is unreferenced.
It has not been a problem for sun.misc.Cleaner because the cleanup is
*only* done when
the ref is unreachable. But there are issues about latency in getting
resources released and reusable.
Roger
On 10/14/2015 9:17 AM, Brian Goetz wrote:
Finally, how important is it to be able to unregister a cleaner? In
all the years we've had sun.misc.Cleaner that capability has never
been needed, and leaving it out would simplify the API.
I see this as having two big potential benefits (I'll let Roger
confirm whether the implementation provides both):
- Resource release for finalizable objects is generally coded in two
places; in the explicit close() / release() method, which we hope
people will use, and in the finalizer, in case the object is collected
without being closed. Having two ways to express the same action is
error-prone; if there's one definition of "release the resources" then
they can't get out of sync.
This requires an atomic means to say "unregister the cleaner, and, if
its not yet been run, run it now".
- If you can unregister the cleaner on the happy path (where the user
explicitly closes the object ), then all the enqueue / reference
processing / finalization work can be optimized away.
