原文：https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/collectors.html
The discussion to this point has been about the serial collector. The Java HopSpot VM includes three different types of collectors, each with different performance characteristics.
The serial collector uses a single thread to perform all garbage collection work, which makes it relatively efficient because there is no communication overhead between threads. It is best-suited to single processor machines, because it cannot take advantage of multiprocessor hardware, although it can be useful on multiprocessors for applications with small data sets (up to approximately 100MB). The serial collector is selected by default on certain hardware and operating system configurations, or can be explicitly enabled with the option 🍐 -XX:+UseSerialGC
The parallel collector (also known as the throughput collector) performs minor collections in parallel, which can significantly reduce garbage collection overhead. It is intended for applications with medium-sized to large-sized data sets that are run on multiprocessor or multi-threaded hardware. The parallel collector is selected by default on certain hardware and operating system configurations, or can be explicitly enabled with the option 🍐 -XX:+UseParallelGC -Parallel compaction (并行缩并) is a feature that enables the parallel collector to perform major collections in parallel. Without parallel compaction, major collections are performed using a single thread, which can significantly limit scalability. Parallel compaction is enabled by default if the option 🍐 -XX:+UseParallelGC has been specified. The option to turn it off is 🍐 -XX:-UseParallelOldGC.
The mostly concurrent collector performs most of its work concurrently (for example, while the application is still running) to keep garbage collection pauses short. It is designed for applications with medium-sized to large-sized data sets in which response time is more important than overall throughput because the techniques used to minimize pauses can reduce application performance. The Java HotSpot VM offers a choice between two mostly concurrent collectors; see The Mostly Concurrent Collectors. Use the option 🍐 -XX:+UseConcMarkSweepGC en enable the CMS collector or 🍐 -XX:+UseG1GC to enable the G1 collector.
Unless your application has rather strict pause time requirements, first run your application and allow the VM to select a collector. If necessary, adjust the heap size to improve performance. If the performance still does not meet your goals, then use the following guidelines as a tarting point for selecting a collector.
If the application has a small data set (up to approximately 100MB), then select the serial collector with the option 🍐 -XX:+UseSerialGC.
If the application will be run on a single processor and there are no pause time requirements, then let the VM select the collector, or select the serial collector with the option 🍐 -XX:+UseSerialGC.
If (a) peak application performance if the first priority and (b) there are no pause time requirements or pauses of 1 second or longer are acceptable, then let the VM select the collector, or select the parallel collector with 🍐 -XX:UseParallelGC.
If response time is more important than overall throughput and garbage collection pauses must be kept shorter than approximately 1 second, then select the concurrent collector with 🍐 -XX:UseConcMarkSweepGC or 🍐 -XX:+UseG1GC.
If the recommended collector does not achieve the desired performance, first attempt to adjust the heap and generation sizes to meet the desired goals. If performance is still inadequate, then try a different collector: use the concurrent collector to reduce pause times and use the parallel collector to increase overall throughput on multiprocessor hardware.
