On a single-CPU machine, if the garbage collector of a JVM is running actively, 
your requests to the JVM will not get processed until, well, the garbage collection 
cycle finishes.  The task manager (on Windows) will show this:

The potential causes for frequent (and too frequent) garbage collection in a JVM 
are a) memory leaks in your Java application; and/or b) loading large files (such as 
large images, PDF, Word, Excel, etc) into JVM's heap for in-memory processing, therefore 
maxing out a pre-configured heap forcing garbage collection to kick off often.  
Remember, garbage collection happens when the free/total heap ratio goes under a 
certain value (default or admin-configured).

Because most garbage collection algorithms stop the world for some period of time, a 
single-threaded garbage collector can quickly become a scalability bottleneck, 
because all but one processor are idle while the garbage collector has suspended 
the user program threads.

JDK 1.4.1 and beyond offers at least six algorithms for garbage collecting to choose from, 
you're probably wondering which one to use. Figure below (copyright IBM developerWorks) 
offers some guidance, dividing collectors into single-threaded and concurrent, and into 
low-pause and high-throughput. Given what you know about your application and deployment 
environment, this may be enough to select the appropriate algorithm. For many applications, 
the default collectors work just fine -- so if you don't have a performance problem, 
there's no point in inviting more complexity. However, if your application is deployed 
on a multiprocessor system or uses a very large heap, you may get some performance boost 
from changing collector options.

To see the DW article, click here.