This example comes from running an application with one active thread—that makes the ex-
ample easier to follow, but the concepts apply even if there are multiple threads.
During each second, the CPU is busy for 450 ms (42% of the time executing user code, and
3% of the time executing system code). Similarly, the CPU is idle for 550 ms. The CPU can
be idle for a number of reasons:
▪ The application might be blocked on a synchronization primitive and unable to execute
until that lock is released.
▪ The application might be waiting for something, such as a response to come back from a
call to the database.
▪ The application might have nothing to do.
These first two situations are always indicative of something that can be addressed. If con-
tention on the lock can be reduced, or the database can be tuned so that it sends the answer
back more quickly, then the program will run faster and the average CPU use of the applica-
tion will go up (assuming, of course, that there isn't another such issue that will continue to
block the application).
That third point is where confusion often lies. If the application has something to do (and is
not prevented from doing it because it is waiting for a lock or another resource), then the
CPU will spend cycles executing the application code. This is a general principle, not specif-
ic to Java. Say that you write a simple script containing an infinite loop. When that script is
executed, it will consume 100% of a CPU. The following batch job will do just that in Win-
REM We never get here...
Consider what it would mean if this script did not consume 100% of a CPU. It would mean
that the operating system had something it could do—it could print yet another line saying
LOOPING —but it chose instead to be idle. Being idle doesn't help anyone in that case, and if
we were doing a useful (lengthy) calculation, forcing the CPU to be periodically idle would
mean that it would take longer to get the answer we are after.