the phase where they scan for unused objects can occur without stopping application threads,
CMS and G1 are called concurrent collectors. They are also called low-pause (and some-
times—incorrectly—pauseless) collectors, since they minimize the need to stop all the ap-
plication threads. Concurrent collectors also take different approaches to compacting the old
When using the CMS or G1 collector, an application will typically experience fewer (and
much shorter) pauses. The trade-off is that the application will use more CPU overall. CMS
and G1 may also perform a long, full GC pause (and avoiding those is one of the key factors
to consider when tuning those algorithms).
As you consider which garbage collector is appropriate for your situation, think about the
overall performance goals that must be met. There are trade-offs in every situation. In an ap-
plication (such as a Java EE server) measuring the response time of individual requests, con-
sider these points:
▪ The individual requests will be impacted by pause times—and more importantly by long
pause times for full GCs. If minimizing the effect of pauses on response times is the goal,
a concurrent collector will be more appropriate.
▪ If the average response time is more important than the outliers (i.e., the 90th% response
time), the throughput collector will usually yield better results.
▪ The benefit of avoiding long pause times with a concurrent collector comes at the ex-
pense of extra CPU usage.
Similarly, the choice of garbage collector in a batch application is guided by the following
▪ If enough CPU is available, using the concurrent collector to avoid full GC pauses will
allow the job to finish faster.
▪ If CPU is limited, then the extra CPU consumption of the concurrent collector will cause
the batch job to take more time.