[concurrency-interest] Reference Collections

Peter Firmstone peter.firmstone at zeus.net.au
Thu Jan 5 09:07:51 EST 2012


Thinking about it further, the best solution for cleaning reference
collections is using a static final ScheduledExecutor as part of the
ReferenceProcessor class.

That way if all the reference collections in use only require one
thread, then only one shared thread will be created.

Each Collection will still get its own ReferenceQueue, it keeps the code
simple and allows the use of multiple collections to scale, since
reference queues would be polled only when running as scheduled tasks,
there's no contention for the ReferenceQueue lock, instead the threads
increase if the load increases and there a plenty of queues to share
among the threads.

A disadvantage is the ReferenceProcessor needs a finalizer to cancel the
task in the scheduled executor when no longer required.

Example: ConcurrentMap<AccessControContext,Set<Permission>> checked,
using weak keys referring to ConcurrentSkipListSet's containing soft
references.

In this case there would be one ReferenceQueue for the keys and one for
each of the Set's.

The path for a calling thread that doesn't add then becomes, create
referrer object, perform get, remove, contains, then return, discarding
the referrer.  Reference object instances are only created for put,
putIfAbsent, add, etc - write methods, in this case the ReferenceQueue
is passed to the Reference constructor, the Reference added to the
collection then the method returns.

Do you think this strategy will scale?

Since Reference Collection's might still be used by client developers
for single threaded use, I'll probably keep the CAS tryLock() option, in
case the underlying collection in use doesn't support multi threading.

Thanks in advance,

Peter.



More information about the Concurrency-interest mailing list