Chapter 5 JVM garbage collector (1): jvm garbage collection
(The garbage collection algorithm is a theory, and the garbage collector is a collection algorithm. For details about the collection algorithm, see Chapter 4 JVM garbage collection algorithm.)
1. Seven garbage collectors
- Serial (Serial GC)
- ParNew (parallel GC)
- Parallel Scavenge (Parallel GC collection)
- Serial Old (MSC) (Serial GC)
- CMS (concurrent GC)
- Parallel Old (Parallel GC)
- G1 (JDK1.7update14 is commercially available)
Note:
- 1 ~ 3 For the young generation of garbage collection: the young generation of garbage collection is called minor GC.
- 4 ~ 6 for garbage collection in the old generation (of course, it can also be used in the Method Area): garbage collection in the old generation is called full GC.
- G1 completes separate generation garbage collection"
Note: parallelism and concurrency
- Parallel: Multiple garbage collection threads operate simultaneously
- Concurrency: The garbage collection thread operates with the user thread
2. Five common combinations
- Serial/Serial Old
- ParNew/Serial Old: Compared with the above, it only has more multi-thread garbage collection than the young generation.
- ParNew/CMS: a more efficient combination
- Parallel Scavenge/Parallel Old: automatically managed combination
- G1: the most advanced collector, but it must be later than JDK1.7update14
2.1. Serial/Serial Old:
Features:
- The young generation Serial collector uses a single GC thread to implement the "copy" algorithm (including scanning and copying)
- The Old Serial Old collector uses a single GC thread to implement the "mark-organize" algorithm.
- Both Serial and Serial Old will suspend all user threads (that is, STW)
Note:
- STW (stop the world): the safepoint (the point at which the loop ends and the point at which the method execution ends) is injected to each method during code compilation. When the application is paused, wait for all user threads to enter the safepoint, pause all threads, and recycle garbage.
Applicable scenarios:
- Number of CPU cores <2, physical memory <2 GB (in simple terms, single CPU, new generation space is small, and STW time requirements are not high)
- -XX: UseSerialGC: force this GC combination
- -XX: PrintGCApplicationStoppedTime: view the STW time
2.2. ParNew/Serial Old:
Note:
- Apart from using multiple GC threads to implement the replication algorithm, ParNew is the same as Serial, but Serial Old in this combination is a single GC thread, so this combination is an embarrassing combination, no Serial/Serial Old speed in a single CPU (because ParNew multithreading requires switching ), in the case of multiple CPUs, there is no later combination (because Serial Old is a single GC thread), so it is not used much.
- -XX: ParallelGCThreads: specifies the number of ParNew GC threads, which is the same as the number of CPU cores by default. This parameter may also be used when cms gc is combined.
2.3. Parallel Scavenge/Parallel Old:
Features:
- The young generation Parallel Scavenge collector uses multiple GC threads to implement the "copy" algorithm (including scanning and copying)
- The older generation Parallel Old collector uses multiple GC threads to implement the "mark-organize" algorithm.
- Parallel Scavenge and Parallel Old both suspend all user threads (that is, STW)
Note:
- Throughput: CPU Running code time/(CPU Running code time + GC time)
- CMS mainly focuses on shortening the STW (the shorter the time, the better the user experience, so it is mainly used to handle a lot of interactive tasks)
- Parallel Scavenge/Parallel Old focuses on throughput (the higher the throughput, the higher the CPU utilization, so it is mainly used to handle a lot of CPU computing tasks and less user interaction tasks)
Parameter settings:
- -XX: + UseParallelOldGC: use this GC combination
- -XX: GCTimeRatio: directly set the throughput. If it is set to 19, the maximum GC time allowed is 1/(1 + 19) of the total time. The default value is 99, that is, 1/(1 + 99)
- -XX: MaxGCPauseMillis: Maximum GC pause time. The smaller the value, the better.
- -XX: + UseAdaptiveSizePolicy: this parameter is enabled.-Xmn/-XX: Invalid vorratio/-XX: PretenureSizeThreshold does not work. The virtual machine automatically collects monitoring information, dynamically adjust these parameters to provide the most appropriate pause time or maximum throughput (GC adaptive adjustment policy), and what we need to set is-Xmx,-XX: + UseParallelOldGC or-XX: the two GCTimeRatio parameters are good (of course,-Xms also specifies the same as-Xmx)
Note:
- -XX: GCTimeRatio and-XX: MaxGCPauseMillis
- If-XX: + UseAdaptiveSizePolicy is not enabled,-Xmn/-XX: Invalid vorratio/-XX: PretenureSizeThreshold parameters can still be configured, take the resin server as an example <jvm-arg>-Xms2048m </jvm-arg> <jvm-arg>-Xmx2048m </jvm-arg> <jvm-arg>-Xmn512m </jvm -arg> <jvm-arg>-Xss1m </jvm-arg> <jvm-arg>-XX: permSize = 256 M </jvm-arg> <jvm-arg>-XX: MaxPermSize = 256 M </jvm-arg> <jvm-arg>-XX: export vorratio = 8 </jvm-arg> <jvm-arg>-XX: MaxTenuringThreshold = 15 </jvm-arg> <jvm-arg>-XX: + UseParallelOldGC </jvm-arg> <jvm-arg>-XX: GCTimeRatio = 19 </jvm-arg> <jvm-arg>-XX: + PrintGCDetails </jvm-arg> <jvm-arg>-XX: + PrintGCTimeStamps </jvm-arg>View Code
Applicable scenarios:
- Many CPU computing tasks with fewer user interaction tasks
- I don't want to worry about GC parameters too much and want the virtual machine to perform optimization on its own.
2.4. ParNew/CMS
Note:
- The above is only the process of collecting CMS in the Old generation. For the young generation of ParNew, see "2.2, ParNew/Serial Old ".
- CMS is a multi-Recycle thread and should not be misled. default number of threads: (number of CPUs + 3)/4
- CMS mainly focuses on shortening the STW (the shorter the time, the better the user experience, so it is mainly used to handle a lot of interactive tasks)
Features:
- The young generation ParNew collector uses multiple GC threads to implement the "copy" algorithm (including scanning and copying)
- The CMS collector of the old generation uses multithreading to implement the "tag-sorting" Algorithm
- Initial Tag: the node directly associated with the root SET node. Very short time, STW required
- Concurrent flag: traverse the associated nodes marked previously and continue to mark down all surviving nodes. It takes a long time.
- Retag: Re-traverse the referenced relational objects modified during the concurrent trace process. The time is between the initial tag and the concurrent tag, which is usually not very long. STW required
- Concurrent cleanup: directly clears non-live objects. After cleanup, switch the CPU occupied by this thread to the user thread.
- All user threads (namely, STW) are paused for initial marking and re-marking, but the time is short. The concurrent marking and concurrent cleaning time is long, but STW is not required.
For details about how to record changed reference object During Concurrent tag and how to scan these objects during tag re-marking, see Chapter 6 JVM garbage collector (2)
Disadvantages:
- Concurrent tag and concurrent cleanup: for example, if there are two CPUs, one is used for garbage collection, and the other is used for user threads. In this case, there were two CPUs running user threads. Now there is one thread, and the efficiency will drop sharply. That is to say, the throughput is reduced (that is, the CPU usage is reduced ).
- Concurrent cleanup: In this process, the generated garbage cannot be cleared (because it occurs after remarking)
- Concurrent tag and concurrent cleanup: because it is concurrent with the user thread, the user thread may allocate objects, so that the objects may directly enter the old generation (for example, large objects ), or minor GC may occur in the young generation after the young generation. In this case, we actually need to reserve some space for the old generation, that is to say, if there is still some space in the old generation, garbage collection should be carried out, and a certain amount of memory space should be set aside for other threads, instead of garbage collection until the old generation is full, -XX: CMSInitiatingOccupancyFraction is used to specify the amount of space occupied by the old generation for garbage collection (jdk1.6 is 92% by default)
- Mark-clearing algorithm: Memory fragments are generated. Because it was in the old age, Full GC may be triggered in advance (this is exactly what we should minimize)
Parameter settings:
- -XX: + UseConcMarkSweepGC: use this GC combination
- -XX: CMSInitiatingOccupancyFraction: specifies the amount of space occupied by the old generation for garbage collection (jdk1.6 is 92% by default)
- -XX: + UseCMSCompactAtFullCollection: (enabled by default) Enable the memory fragment process when the CMS collector does not support FullGC. This process requires STW.
- -XX: CMSFullGCsBeforeCompaction: specifies the number of FullGC requests before sorting.
- -XX: ParallelCMSThreads: specifies the number of CMS recycle threads. The default value is: (number of CPUs + 3)/4.
Applicable scenarios:
- Used to process many interactive tasks
- CMS is generally used for Method Area Recycling. Two parameters are configured:-XX: + CMSPermGenSweepingEnabled and-XX: + CMSClassUnloadingEnabled.
3. Experience
- Currently, many large enterprises use jdk1.6, so G1 is not used much.
- The two most commonly used methods are ParNew/CMS and Parallel Scavenge/Parallel Old.
- Four cases of Full GC
- Insufficient space for the old generation
- Do not create too large objects to obtain Arrays
- Try to recycle objects in minor GC
- So that the object remains in the young generation for a period of time, it may be recycled by minor GC during this period of time.
- The method area is full.
- Increase the Method Area
- Use cms gc Recovery Method Area
- Promotion failed in cms gc (when minor GC is used, the region VOR and the old region cannot be used) and concurrent mode failure
- Increase the region vor.
- Add to old zone
- Lower-XX: CMSInitiatingOccupancyFraction
- Set:-XX: CMSMaxAbortablePrecleanTime = 5 (unit: ms) to prevent CMS from being cleaned up after being remarked for a long time.
- Space Guarantee Mechanism (see "deep understanding of Java Virtual Machine (version 2)" P98)
Appendix: For details about the configuration parameters, see Java Virtual Machine (version 2) P90.
