Figure 5-3. Actual versus average CPU usage (CMS)
The application thread starts by using 25% of the total CPU. Eventually it has created enough
garbage for the CMS background thread to kick in; that thread also consumes an entire CPU,
bringing the total up to 50%. When the CMS thread finishes, CPU usage drops to 25%, and so on.
Note that there are no 100% peak-CPU periods, which is a little bit of a simplification: there will
be very short spikes to 100% CPU usage during the CMS young generation collections, but those
are short enough that we can ignore them for this discussion.
There can be multiple background threads in a concurrent collector, but the effect is similar: when
those background threads run, they will consume CPU and drive up the long-term CPU average.
This can be quite important when you have a monitoring system triggered by CPU usage rules:
you want to make sure CPU alerts are not triggered by the 100% CPU usage spikes in a full GC,
or the much longer (but lower) spikes from background concurrent processing threads. These
spikes are normal occurrences for Java programs.