If an application is running gratuitously slowly, there is a reasonable probability that the code causing the problem will be on a stack at any given instant. Stacks can be obtained with ctrl-\ (ctrl-break under Windows) or jstack. Better jconsole or visualvm will allow you to concentrate on a specific thread rather than wading through lots of waiting threads.

When you have the application running slow, take a few samples. Hopefully you can spot the issue. Whilst it wont always work, it has worked for me a number of times. The other week Netbeans did it’s usual thing, and used CPU continuously but didn’t quite die as such. hit it with jconsole (visualvm wouldn’t pick up the process). It appeared to be doing a huge amount of disc access, but it was CPU bound and the disc light was off. So, probably reading the same files/directories over and over. Looking at the code involved the problem was obvious - a WeakHashMap with a transient key used as a cache. If you create a new object and only have a WeakReference to it, then that reference can be cleared immediately.

In real life the object has to wait for the garbage collector to notice it. Well, this used to be true. These days, after warming up the code sufficiently - perhaps several hours IDE usage - along comes HotSpot. I am guessing that an escape analysis operation has been implemented that allows detecting this situation and immediately passing the reference object over to the reference handler (this is more useful for finalisers which share some implementation). Using a SoftReference would be more appropriate for a cache (pity the current collections framework does not provide goodsupport for caches).

So do not use WeakHashMap/WeakReference to implement cache. It might work most of the time, but might fail unexpectedly in production.

See also:

• NamingFactory uses WeakHashMap for cache instead of SoftReferences

Source/Kaynak : http://blogs.sun.com/tackline/entry/performance_debugging_with_ctrl