https://www.cnblogs.com/Leo_wl/p/5393300.htmlhttps://www.cnblogs.com/Leo_wl/p/5393300.html==== Brief introduction to several processes of garbage collection of CMS cms action on garbage collection in the old age, but also scan the new generation of content 1. The initial marking phase. The user thread pauses, marking all objects directly connected to the root object. 2. concurrency tagging phase. User thread up, this stage marks all reachable objects 3. Pre-processing phase. Because the user thread is up, there may be modifications or additions to the object, which is the object that marks the transition from the Cenozoic to the old, the objects that were newly assigned to the old age, the objects that were modified, and so on. Because the next stage is the re-tagging, must do GC pauses to scan the new generation and the old age, how to make this pause time is less, how to scan the marker faster, is the task of this stage, so pre-processing for the new generation and the old age have done the corresponding treatment. -----pretreatment Phase: 1. The MINORGC 2.remark phase will concurrently scan the Cenozoic, so preprocessing will split the Cenozoic into multiple threads. -----pretreatment in the old age: 1. Use card table to speed up the scan, which is a byte array. The old age is divided, and each piece is associated with a single byte in the card table. 1. If the object is modified by the user thread during the concurrent tagging phase, it is marked as dirty card, the preprocessing stage is marked for accessibility, and the dirty card tag is cleared so that objects modified in the concurrent tagging phase are also flagged 2. If the old age is quoted to the new generation, it can be quickly scanned by cardtable. 4. The re-tagging phase. Pauses the user thread and re-marks the reachable object. This stage speeds up after preprocessing. 5. Phase of concurrency cleanup. The user thread executes at the same time, producing 6. Reset. Prepare for the next stage of garbage collection. What problems will ===cms bring? 1. Concurrency problem CMS By default, the number of GC threads is (CPU+3)/4, if the number of CPUs, such as only two, there will be a GC so the application will have a percentage of 50 performance degradation will be obvious, but when the number of CPUs rise, there will be no such problem. 2. The second problem of concurrency. When the GC thread user thread executes synchronously, a floating garbage generation occurs. At the same time, the user thread needs to provide space for execution, that is, not until the old age is full before garbage collection, the default is to reach 92 of the old ageRubbish recovery. Of course, this parameter can be set. Too small will cause the GC to have frequent pauses, too large to be able to execute the user thread, because there is not enough space required, this time will result in using the serial collector to recycle, the pause time will be longer. 3. Labeling problems: memory fragmentation, which may be large in the old age but because of memory fragmentation, there is no significant contiguous memory space, and large objects may trigger garbage collection. The solution for CMS is to compress the memory after a few recoveries. ==== Do you need to scan the new generation if you want to mark objects of the old age? How to speed up the new generation of scanning? How is the preprocessing phase controlled? To mark the age of the object needs to scan the new generation, in order to speed up the new generation of scanning will make the new generation of objects less, that is, a garbage collection. Pre-processing phase because the user thread is also running, then the object will always change, must have a stop, this time can set parameters to stop it.
Java Foundation---virtual machine---cms concurrency tag garbage collector
