HotSpot JVM collector
There are 7 collectors above, which are divided into two pieces. The top is the new generation collector, and the bottom is the old generation collector. If there is a connection between the two collectors, they can be used together.
Serial (serial GC) collector
The Serial collector is a new generation collector, single-threaded, using a replication algorithm. It must suspend all other worker threads (user threads) during garbage collection. It is the default young generation collector in JVM client mode. For environments limited to a single CPU, the Serial collector has no thread interaction overhead, so it is natural to concentrate on garbage collection to achieve the highest single-threaded collection efficiency.
ParNew (parallel GC) collector
The ParNew collector is actually a multi-threaded version of the serial collector. Except for using multiple threads for garbage collection, the rest of the behavior is the same as the Serial collector.
Parallel Scavenge (parallel recycling GC) collector
The Parallel Scavenge collector is also a new generation collector. It is also a collector using a replication algorithm and a parallel multi-threaded collector. The characteristic of the parallel Scavenge collector is that its focus is different from other collectors. The focus of collectors such as CMS is to shorten the pause time of user threads during garbage collection as much as possible, while the goal of the parallel Scavenge collector is to achieve a feasible Controlled throughput. Throughput = program running time / (program running time + garbage collection time), the virtual machine runs for a total of 100 minutes. Where garbage collection takes 1 minute, the throughput is 99%.
Serial Old (serial GC) collector
Serial Old is the older version of the Serial collector, which also uses a single thread to perform the collection, using the "mark-collate" algorithm. Mainly use virtual machines in Client mode.
Parallel Old (parallel GC) collector
Parallel Old is an older version of the Parallel Scavenge collector, using multithreading and a "mark-and-clean" algorithm.
CMS (Concurrent GC) collector
The CMS (Concurrent Mark Sweep) collector is a collector whose goal is to obtain the shortest collection pause time.
The CMS collector is implemented based on the "mark-sweep" algorithm, and the entire collection process is roughly divided into four steps:
①.Initial mark (CMS initial mark)
②. Concurrent mark (CMS concurrenr mark)
③. Remark (CMS remark)
④. Concurrent sweep (CMS concurrent sweep)
Among them, the two steps of initial marking and re-marking still need to stop other user threads. The initial mark is only to mark the objects that GC ROOTS can directly associate with, which is very fast. The concurrent mark stage is the stage of the GC ROOTS root search algorithm, which will determine whether the object is alive. The re-marking phase is to correct the marking records of the part of the object whose marking is changed due to the user program continuing to run during the concurrent marking. The pause time of this phase will be slightly longer than the initial marking phase, but shorter than the concurrent marking phase. .
Since the collector thread can work together with the user thread during the longest concurrent marking and concurrent clearing process in the whole process, overall, the memory recovery process of the CMS collector is performed concurrently with the user thread.
The advantages of CMS collector: concurrent collection, low pause, but CMS is far from perfect, there are three significant disadvantages:
1. The CMS collector is very sensitive to CPU resources. In the concurrent phase, although the user thread will not be paused, it will occupy the CPU resources and cause the reference program to slow down and the total throughput to decrease. The number of recycling threads started by CMS by default is: (number of CPUs + 3) / 4.
2. The CMS collector cannot handle floating garbage, and "Concurrent Mode Failure" may occur, which will lead to another Full GC. Since the user thread is still running in the concurrent cleaning phase of the CMS, new garbage will be continuously generated with the running of the program. This part of the garbage appears after the marking process, and the CMS cannot process them in this collection, so it has to wait for the next GC. Clean it up. This part of garbage is called "floating garbage". It is also because the user thread still needs to run during the garbage collection phase, that is, enough memory space needs to be reserved for the user thread to use, so the CMS collector cannot wait until the old age is almost completely filled before collecting like other collectors. A part of the memory space is reserved for program operation during concurrent collection.
By default, the CMS collector will be activated when the old generation uses 68% of the space. You can also provide the trigger percentage through the value of the parameter -XX:CMSInitiatingOccupancyFraction to reduce the number of memory recycling and improve performance. If the memory reserved during the running of the CMS cannot meet the needs of other threads of the program, a "Concurrent Mode Failure" failure will occur. At this time, the virtual machine will start the backup plan: temporarily enable the Serial Old collector to restart the old generation garbage collection, so that The pause time is long.
Therefore, if the parameter -XX:CMSInitiatingOccupancyFraction is set too high, it will easily lead to the failure of "Concurrent Mode Failure", and the performance will be reduced.
3. The last disadvantage is that CMS is a collector based on the "mark-sweep" algorithm. After the "mark-sweep" algorithm is used to collect, a large number of fragments will be generated. When there are too many space fragments, it will bring a lot of trouble to object allocation. For example, for large objects, the memory space cannot find a continuous space to allocate and must trigger a Full GC in advance. In order to solve this problem, the CMS collector provides a -XX:UseCMSCompactAtFullCollection switch parameter to add a defragmentation process after the Full GC. You can also use the -XX:CMSFullGCBeforeCompaction parameter to set how many times to perform a full GC without compression, followed by to a defragmentation process.
G1 collector
The G1 (Garbage First) collector is a new collector provided by JDK1.7. The G1 collector is implemented based on the "mark-sort" algorithm, which means that no memory fragmentation occurs. There is also a feature that the previous collectors collected the entire new generation or old generation, while G1 will collect the entire Java heap (including the new generation and the old generation).
Summary of garbage collector parameters:
-XX:+<option> 启用选项 -XX:-<option> 不启用选项 -XX:<option>=<number> -XX:<option>=<string>参数 描述 -XX:+UseSerialGC Jvm运行在Client模式下的默认值，打开此开关后，使用Serial + Serial Old的收集器组合进行内存回收 -XX:+UseParNewGC 打开此开关后，使用ParNew + Serial Old的收集器进行垃圾回收 -XX:+UseConcMarkSweepGC 使用ParNew + CMS + Serial Old的收集器组合进行内存回收，Serial Old作为CMS出现“Concurrent Mode Failure”失败后的后备收集器使用。 -XX:+UseParallelGC Jvm运行在Server模式下的默认值，打开此开关后，使用Parallel Scavenge + Serial Old的收集器组合进行回收 -XX:+UseParallelOldGC 使用Parallel Scavenge + Parallel Old的收集器组合进行回收 -XX:SurvivorRatio 新生代中Eden区域与Survivor区域的容量比值，默认为8，代表Eden:Subrvivor = 8:1 -XX:PretenureSizeThreshold 直接晋升到老年代对象的大小，设置这个参数后，大于这个参数的对象将直接在老年代分配 -XX:MaxTenuringThreshold 晋升到老年代的对象年龄，每次Minor GC之后，年龄就加1，当超过这个参数的值时进入老年代 -XX:UseAdaptiveSizePolicy 动态调整java堆中各个区域的大小以及进入老年代的年龄 -XX:+HandlePromotionFailure 是否允许新生代收集担保，进行一次minor gc后, 另一块Survivor空间不足时，将直接会在老年代中保留 -XX:ParallelGCThreads 设置并行GC进行内存回收的线程数 -XX:GCTimeRatio GC时间占总时间的比列，默认值为99，即允许1%的GC时间，仅在使用Parallel Scavenge 收集器时有效 -XX:MaxGCPauseMillis 设置GC的最大停顿时间，在Parallel Scavenge 收集器下有效 -XX:CMSInitiatingOccupancyFraction 设置CMS收集器在老年代空间被使用多少后出发垃圾收集，默认值为68%，仅在CMS收集器时有效，-XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSCompactAtFullCollection 由于CMS收集器会产生碎片，此参数设置在垃圾收集器后是否需要一次内存碎片整理过程，仅在CMS收集器时有效 -XX:+CMSFullGCBeforeCompaction 设置CMS收集器在进行若干次垃圾收集后再进行一次内存碎片整理过程，通常与UseCMSCompactAtFullCollection参数一起使用 -XX:+UseFastAccessorMethods 原始类型优化 -XX:+DisableExplicitGC 是否关闭手动System.gc -XX:+CMSParallelRemarkEnabled 降低标记停顿 -XX:LargePageSizeInBytes 内存页的大小不可设置过大，会影响Perm的大小，-XX:LargePageSizeInBytes=128mClient, Server mode default GC
新生代GC方式 老年代和持久代GC方式| Client |
Serial Serial GC | Serial Old Serial GC |
| Server | Parallel Scavenge parallel recycling GC | Parallel Old Parallel GC |
Sun/oracle JDK GC combination
新生代GC方式 老年代和持久代GC方式| -XX:+UseSerialGC |
Serial Serial GC |
Serial Old Serial GC |
| -XX:+UseParallelGC |
Parallel Scavenge parallel recycling GC |
Serial Old Parallel GC |
| -XX:+UseConcMarkSweepGC |
ParNew Parallel GC |
CMS concurrent GC When "Concurrent Mode Failure" appears Use Serial Old serial GC |
| -XX:+UseParNewGC |
ParNew Parallel GC |
Serial Old Serial GC |
| -XX:+UseParallelOldGC |
Parallel Scavenge parallel recycling GC |
Parallel Old Parallel GC |
| -XX:+UseConcMarkSweepGC -XX:+UseParNewGC |
Serial Serial GC |
CMS concurrent GC When "Concurrent Mode Failure" appears Use Serial Old serial GC |