Benefits of activeReferenceQueue

Peter Levart peter.levart at
Tue Jul 29 09:46:32 UTC 2014

On 07/29/2014 11:06 AM, Jaroslav Tulach wrote:
>>> > >This is basically a re-implementation of ReferenceQueue.remove(int
>>> > >timeout) instance method in terms of a static method, which only briefly
>>> > >"touches" the queue instance wrapped in a Reference but majority of time
>>> > >it waits for notification while only holding a Reference to the queue.
> ... because as we look at the patch attached to issue:
> we can find out it uses very similar approach:

Ah, sorry. The 'X.diff' was buried in the jira page so deep, I haven't 
noticed it before...

Yes, that's a clever way of doing this, but it can only be done by 
overriding a package-private enqueue() method unfortunately.

I have also played with the idea of overriding finalize() method on the 
ReferenceQueue subclass used in ActiveQueue and using it as a signal 
that the queue is about to go away, but there are issues involving 
unavoidable races since finalize() is called before WeakReference to the 
object is cleared and one can obtain a strong reference to the object 
which has already executed or is about to execute the finalize() method, 
making it 'alive' again, but wasting a single finalize() call-back each 
object gets in it's life...

Regards, Peter

>   > But that's only half of the story. The other half is how a thread finds
>>> > >out that the queue has been collected so it can exit.
> Well, the patch
> solves that by its
> +    private static class Locks extends ReferenceQueue<Object> {
> +        @Override
> +        boolean enqueue(Reference<? extends Object> r) {
> +            if (r instanceof Lock) {
> +                synchronized (r) {
> +                    r.notifyAll();
> +                }
> +            }
> +            return false;
> +        }
> +    }
> part. As the test at the end of the patch shows, the solution behaves find.
> -jt

More information about the core-libs-dev mailing list