On 12/08/2015 07:44 PM, Kim Barrett wrote:
On Dec 8, 2015, at 7:44 AM, David Holmes <david.hol...@oracle.com> wrote:
But thinking more on this approach this is simply not scalable. A
Cleaner per cleanable-class could result in hundreds of threads being
active!
That would indeed be awful. However, the scope of a Cleaner should
not usually be a class. More typically it would be a subsystem,
module, plugin, or some other sensible unit of sharing. I assume
Peter's example had a class-scoped Cleaner for simplicity of
presentation. A class-scoped Cleaner probably should be treated as a
canonical anti-pattern for Cleaner usage; appropriate in rare
circumstances, but usually a mistake.
What exactly are the advantages over finalization again?
The same as PhantomReference-based cleanup vs finalization.
- Performance (especially after JDK-8071507).
- Semantic simplicity, avoiding the need to deal with resurrection of
objects, and objects not needing to protect themselves from some
kinds of post-cleanup misuse.
... the last thing is applicable only if Cleanable.clean() is never
invoked. If it is invoked (as part of on-demand cleaning like
AutoCloseable.close()) the object will still have to protect itself from
misuse.
That's what the problem with direct/mapped ByteBuffer is. The protection
from post-cleanup misuse would be to costly so there was rather no
on-demand unmapping implemented (in public API)...
Regards, Peter
