1. What is the CMS collector
CMS (Concurrent Mark-Sweep) is a garbage collector that sacrifices throughput to obtain the shortest recovery pause time. For applications that require server response speed, this garbage collector is very suitable. Add **-XX:+UseConcMarkSweepGC** to the startup JVM parameter. This parameter indicates that CMS is used for the recycling of the old generation. The basic algorithm used by CMS is: mark-clear .
2. CMS work steps
- STW initial mark
- Concurrent marking
- Concurrent precleaning
- STW remark
- Concurrent sweeping
- Concurrent reset
Initial mark: At this stage, the virtual machine needs to stop the task being executed, the official name is STW (Stop The Word). This process starts with the "root object" of the garbage collection, and only scans the objects that can be directly associated with the "root object" and marks them. So although this process suspended the entire JVM, it was quickly completed.
Concurrent marking: This stage follows the initial marking stage, and continues to trace the marking downwards on the basis of the initial marking. In the concurrent marking phase, the application thread and the concurrent marking thread execute concurrently, so the user will not feel a pause.
Concurrent pre-cleanup: The concurrent pre-cleanup phase is still concurrent. At this stage, the virtual machine searches for objects that have entered the old generation during the concurrent marking phase (some objects may be promoted from the young generation to the old generation, or some objects may be allocated to the old generation). By rescanning, the work of "re-marking" in the next stage is reduced, because the next stage will Stop The World. You can use -XX:-CMSPrecleaningEnabled to turn off without preprocessing
Remark: This stage will pause the virtual machine, and the collector thread scans the remaining objects in the CMS heap. Scanning starts from "following the object" and tracing down, and processing the object association. (STW)
Concurrent cleanup: clean up garbage objects. At this stage, the collector thread and the application thread execute concurrently.
Concurrent reset: At this stage, reset the data structure of the CMS collector and wait for the next garbage collection.
3. Demo
environment: JDK1.8
parameter settings:
-Xms10M -Xmx10M -Xmn3m -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC -XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m
Code:
public class TestCMSGC {
public static void main(String[] args) {
byte[] a = new byte[6 * 1024 * 1024];
a = null;
byte[] a1 = new byte[5 * 1024 * 1024];
byte[] a2 = new byte[1 * 1024 * 1024];
byte[] a3 = new byte[3 * 1024 * 1024];
}
}
GC log:
[GC (Allocation Failure) [ParNew: 1545K->256K(2816K), 0.0015253 secs][CMS: 6496K->594K(7168K), 0.0015234 secs] 7689K->594K(9984K), [Metaspace: 3177K->3177K(1056768K)], 0.0031018 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (Allocation Failure) [ParNew: 1103K->168K(2816K), 0.0003180 secs][CMS: 6740K->6734K(7168K), 0.0022887 secs] 6818K->6734K(9984K), [Metaspace: 3192K->3192K(1056768K)], 0.0026347 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (Allocation Failure) [CMS: 6734K->6716K(7168K), 0.0017369 secs] 6734K->6716K(9984K), [Metaspace: 3192K->3192K(1056768K)], 0.0017498 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (CMS Initial Mark) [1 CMS-initial-mark: 6716K(7168K)] 6745K(9984K), 0.0001022 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[CMS-concurrent-mark-start]
[CMS-concurrent-mark: 0.001/0.001 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[CMS-concurrent-preclean-start]
[CMS-concurrent-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (CMS Final Remark) [YG occupancy: 157 K (2816 K)][Rescan (parallel) , 0.0001984 secs][weak refs processing, 0.0000047 secs][class unloading, 0.0001340 secs][scrub symbol table, 0.0002641 secs][scrub string table, 0.0000800 secs][1 CMS-remark: 6716K(7168K)] 6873K(9984K), 0.0007196 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[CMS-concurrent-sweep-start]
[CMS-concurrent-sweep: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[CMS-concurrent-reset-start]
[CMS-concurrent-reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
par new generation total 2816K, used 157K [0x00000000ff600000, 0x00000000ff900000, 0x00000000ff900000)
eden space 2560K, 6% used [0x00000000ff600000, 0x00000000ff6274b0, 0x00000000ff880000)
from space 256K, 0% used [0x00000000ff880000, 0x00000000ff880000, 0x00000000ff8c0000)
to space 256K, 0% used [0x00000000ff8c0000, 0x00000000ff8c0000, 0x00000000ff900000)
concurrent mark-sweep generation total 7168K, used 571K [0x00000000ff900000, 0x0000000100000000, 0x0000000100000000)
Metaspace used 3237K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 350K, capacity 388K, committed 512K, reserved 1048576K
Let's analyze the minor gc log first, and we
can see Allocation Failure, allocation failure, minor gc, the meaning of the specific parameters are as follows
[GC (Allocation Failure) [ParNew: 1545K->256K(2816K), 0.0015253 secs][CMS: 6496K->594K(7168K), 0.0015234 secs] 7689K->594K(9984K), [Metaspace: 3177K->3177K(1056768K)], 0.0031018 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Then there is the CMS GC log: you
can see that the black part of the log corresponds to the 7 stages above
[Full GC (Allocation Failure) [CMS: 6734K->6716K(7168K), 0.0017369 secs] 6734K->6716K(9984K), [ Metaspace: 3192K->3192K(1056768K)], 0.0017498 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (CMS Initial Mark) [1 CMS-initial-mark : 6716K(7168K)] 6745K (9984K), 0.0001022 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[CMS-concurrent-mark-start]
[ CMS-concurrent-mark : 0.001/0.001 secs] [Times: user=0.00 sys =0.00, real=0.00 secs]
[CMS-concurrent-preclean-start]
[ CMS-concurrent-preclean : 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (CMS Final Remark) [YG occupancy: 157 K (2816 K)][Rescan (parallel) , 0.0001984 secs][weak refs processing, 0.0000047 secs][class unloading, 0.0001340 secs][scrub symbol table, 0.0002641 secs][scrub string table, 0.0000800 secs][1 CMS-remark: 6716K(7168K)] 6873K(9984K), 0.0007196 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[CMS-concurrent-sweep-start]
[CMS-concurrent-sweep: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[CMS-concurrent-reset-start]
[CMS-concurrent-reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
4. Concurrent mode failure & promotion failed The
above is the normal process of CMS GC, but concurrent mode failure may also occur during the recycling process
[GC (Allocation Failure) [ParNew: 2110K->2110K(2816K), 0.0000069 secs][CMS ( concurrent mode failure): 6329K->5804K(7168K), 0.0031868 secs] 8440K->5804K(9984K), [Metaspace: 3229K->3229K(1056768K)], 0.0032197 secs] [Times: user=0.00 sys=0.00, real =0.00 secs]
This means that the space of the old generation is insufficient during the cleaning process, because the garbage cleaning and the reference thread of the CMS are performed in parallel. If the space of the old generation is not enough to accommodate the new objects promoted from the young generation during the parallel cleaning process, Or directly allocated large objects will throw "concurrent mode failure".
Impact : The garbage collector of the old age degenerates from CMS to Serial Old, all application threads are suspended, and the pause time becomes longer.
So if this happens frequently in the application, it should be adjusted
Solution :
1. Increase the space of the old generation
. 2.-XX:+UseCMSCompactAtFullCollection means that CMS will defragment space after completion. Because CMS is a mark removal algorithm, all space fragments will be generated.
-XX:CMSFullGCsBeforeCompaction=n means in After completing how many times CMS, perform space compression
3.-XX:CMSInitiatingOccupancyFraction=N, reduce; this parameter defaults to 68, which means that CMS is performed when the space utilization rate of the old generation reaches 68%
The promotion failed is caused by the Survivor Space being unable to put it down during the Minor GC, and the object can only be put into the old age, and at this time the old age cannot be put down.
Five
.
CMS important parameters Combine the above solutions: CMS important parameters:
-XX:CMSInitiatingOccupancyFraction: trigger the CMS collector memory ratio. For example, 68% means that when the memory reaches 60%, CMS concurrent collection will start.
-XX:+UseCMSInitiatingOccupancyOnly is used in conjunction with the above to set the recovery threshold (68% specified above). If it is not specified, the JVM will only use the set value for the first time, and will automatically adjust it later.
-XX:+UseCMSCompactAtFullCollection: This has been mentioned before, and is used to send a memory consolidation every time the CMS collector cleans up garbage.
-XX:CMSFullGCsBeforeCompaction: Set to trigger a memory consolidation after several CMS garbage collections. Defragmentation will stop-the-world.
Reference:
Actual Java virtual machine JVM fault diagnosis and performance optimization
https://blog.csdn.net/muzhixi/article/details/105274542
https://blog.csdn.net/xiaocai9999/article/details/88368395
https://blog.csdn.net/muzhixi/article/details/105274542 www.cnblogs.com/bootdo/p/10482853.html
https://blog.csdn.net/iamzhongyong/article/details/84512298?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.control&depth_1-utm_source =distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.contro