[concurrency-interest] Concurrency-interest Digest, Vol 84, Issue 30

Peter Firmstone peter.firmstone at zeus.net.au
Sun Jan 8 06:01:23 EST 2012


Wow thanks, those gold nuggets will save many headaches, much
appreciated.

Regards,

Peter.


On Sun, 2012-01-08 at 03:00, concurrency-interest-request at cs.oswego.edu
wrote:
> Send Concurrency-interest mailing list submissions to
> 	concurrency-interest at cs.oswego.edu
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> or, via email, send a message with subject or body 'help' to
> 	concurrency-interest-request at cs.oswego.edu
> 
> You can reach the person managing the list at
> 	concurrency-interest-owner at cs.oswego.edu
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Concurrency-interest digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Re ference Collections (bestsss)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sat, 7 Jan 2012 03:19:47 -0800 (PST)
> From: bestsss <stanimir at riflexo.com>
> To: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Re ference Collections
> Message-ID: <33097991.post at talk.nabble.com>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> 
> 
> Peter Firmstone-3 wrote:
> > 
> > Ok, based on the comments so far:
> > 
> > Reasoning about the possibility that one thread may not be able to keep
> > up with a ReferenceQueue, bestsss mentioned that ReferenceQueue is a
> > stack, not a queue, because it blocks while the garbage collector thread
> > holds it's lock, the cleaning thread won't be able to poll(), but I
> > suspect the jvm only does this a scheduled intervals.
> > 
> It's not a GC thread but the dedicated ReferenceHandler which gets the
> enqueued references and adds them to the appropriate queues (stacks), also
> executes sun.misc.Cleaner directly. It employs wait/notify and notify() is
> called by the JVM itself.
> 
> 
> Peter Firmstone-3 wrote:
> > 
> >     private final static ScheduledExecutorService garbageCleaner =
> >             Executors.newScheduledThreadPool(1);
> >     // Map to register newly created object references.
> >     private final static Map<Reference,ScheduledFuture> finalizerTasks =
> >             new ConcurrentHashMap<Reference,ScheduledFuture>();
> >     // Finalizer queue to advise cancellation of ScheduledFuture's, 
> >     // when their ReferenceProcessor has been collected.
> >     private final static ReferenceQueue<Reference> phantomQueue = 
> >             new ReferenceQueue<Reference>();
> >     static {
> >         // Finizer Task to cancel unneeded tasks.
> >         garbageCleaner.scheduleAtFixedRate(
> >                 new FinalizerTask(phantomQueue, finalizerTasks), 
> >                 5L, 5L, TimeUnit.MINUTES
> >                 );
> >     }
> >     
> > 
> 
> I'd encourage you to pay extra attention at creating the "static" threads,
> they leak resources badly - mostly thread group, context ClassLoader and
> java.security.AccessControlContext (that contains reference to a classloader
> too) and it has caused me truly a lot of grief. The problem occurs in
> managed environments where redeploys are normal practice in long (months++)
> running processes. The spawned thread will inherit and keep forever the
> context class loader of the calling thread. It's absolutely random which
> thread will initialize the class first. Use thread a ThreadFactory and set
> the conext ClassLoader to ReferenceProcessor.class.getClassLoader() (or just
> null) and try to put in thread in the "system" (or main) thread group if
> there is no System.getSecurityManager(). To prevent the leaking of ACL can
> do smth like AccessController.doPrivileged(...). Also you may want to
> increase the thread priority but thread prir. are often ignored anyways.
> Least, name the thread properly :)
> 
> JDK, itself, has problems leaking ClassLoaders (KeepAliveCache for example)
> and quite a lot of other libraries suffer from the same issue, the open
> sources ones are relatively easy to fix but some require heavy hacking via
> reflection.
> -- 
> View this message in context: http://old.nabble.com/Reference-Collections-tp33078668p33097991.html
> Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 
> 
> End of Concurrency-interest Digest, Vol 84, Issue 30
> ****************************************************



More information about the Concurrency-interest mailing list