Four algorithms
Reference count (not resolve the circular reference)
Copy (New Generation)
Mark - finishing
Mark - Clear
Four main garbage collector
Serial Serial Recycling: single-threaded design and production environment using a thread for recycling, we will suspend all user threads, not suitable for the server environment
Tuvalu multi-hit! ! !
parallel parallel recovery: multiple garbage collector threads execute in parallel, then the user thread is suspended, scientific computing applied to large data
CMS concurrent mark - sweep: user threads and garbage collection concurrently executing threads, no need to stop user threads, used the Internet for a higher response time requirements.
Can be seen from the name (containing "Mark Sweep") on, CMS collector is based on the "mark - sweep" algorithm, and its operation process with respect to the front of several collectors is more complicated, the whole process is divided into four steps, including: initial mark (CMS initial mark) concurrent mark (CMS concurrent mark) re-mark (CMS remark) concurrent Clear (CMS concurrent sweep) where the initial mark, re-mark these two steps still need to "Stop The World . " The initial mark just mark what objects can be linked directly to the GC Roots, very fast, concurrent mark phase is in progress GC RootsTracing, and re-mark phase is due for a correction period concurrent mark the user program continues to operate and generate leads to marked changes that part of the record mark objects, dwell time at this stage usually slightly longer than some of the initial mark phase, but shorter than the concurrent mark time. Since the whole process takes the longest concurrent mark and clear process of collecting concurrent threads can work together with the user thread, so, in general, the memory recovery process CMS collector is with the user concurrently executing threads. We can more clearly see the operation of the steps CMS collector and the concurrent need time to pause by Figure 3-10.
Three distinct disadvantages:
- CMS collector is very sensitive to CUP. In fact, for concurrent design of the program are more sensitive to CPU resources. In a concurrent stage, although it does not lead to the user thread pause, but because of the occupation of a part of the threads (or CPU resources) caused by slow applications, the total throughput will be reduced. The number of recovery threads CMS is enabled by default (the number of CPU +3) / 4, that is, when the CPU is above 4, concurrent garbage collection thread of not less than 25% of the CPU resources, and with the increase of the number and the CPU decline. But when the CPU is less than four (for example, 2), the impact on the CMS user program can become large, if the original CPU load is relatively large, but also the separation of half the computing power to perform collector threads, it could lead to user program execution speed suddenly reduced by 50%, in fact, is not acceptable. To cope with this situation, the virtual machine provides CMS collector variant called "incremental concurrent collector" (Incremental Concurrent Mark Sweep / i-CMS), things done and single CPU PC's operating system the use of pre-emptive multi-tasking mechanism thought to simulate the same, which is in concurrent mark, clearing the time for GC threads, user threads run alternately, minimize the time the GC thread of exclusive resources, so that the entire garbage collection process will be longer, but effect on the user program will be very less, which is the rate of decline is not so obvious. Practice has proved that, CMS collector when the incremental effect is very general, in the current version, i-CMS has been declared as "deprecated", that is no longer promote the users.
- CMS garbage collector can not handle floating (Floating Garbage), may appear "Concurrent Mode Failure" caused by the failure to produce another of Full GC. As the clean-up phase of CMS concurrent user thread is still running, with the program running naturally there will continue to generate new garbage, garbage appear after this part of the marking process, CMS can not dispose of them at times when the collection had to wait until the next time GC again when cleared away. This part of the garbage is called "floating garbage." Also due to user threads need to run garbage collection phase, you will also need to set aside enough memory space for user threads, so the CMS collector can not wait for old age as like other collector's almost completely filled then collection, need to set aside part of the space program provides operational use of concurrent collection. In JDK 1.5, the default setting, CMS collector's used when the old is activated after 68% of the space, which is a conservative setting, if growth in the application's old is not too fast, can be appropriate to increase the parameters -XX: CMSInitiatingOccupancyFraction value to increase the percentage of the trigger, in order to reduce the number of memory recovery in order to gain better performance in JDK 1.6, the start threshold CMS collector has been raised to 92%. If the reserved memory to run during the CMS program can not meet the needs, there will be a "Concurrent Mode Failure" fails, then the virtual machine will start back-up plan: Serial Old temporarily enable collectors to re-old's garbage collection, so pause a very long time. So the parameters -XX: CM SInitiatingOccupancyFraction set too high can easily lead to a large number of "Concurrent Mode Failure" failed, but lower performance.
- Finally there is a drawback, said at the beginning of this section, CMS is based on a "mark - sweep" algorithm collector, if readers have the impression earlier this algorithm introduced, then it might think this means the end of the collection there will be plenty of space debris. When too much space debris, will bring great trouble to the large object allocation, there will always be a lot of room remaining years old, but can not find a large enough contiguous space to allocate the current object and had to trigger a Full GC in advance. To solve this problem, CMS collector provides a -XX: + UseCMSCompactAtFullCollection switch parameters (that is turned on by default), the finishing process for the combined open memory fragmentation in the CMS collector can not stand to be FullGC, the process of memory consolidation is not complicated by the problem of space debris is gone, but not the same long pauses. Virtual machine designers also provides another argument -XX: CMSFullGCsBeforeCompaction, this parameter is used when the number of times the uncompressed Full GC execution, followed by a band compression (default value is 0, which means every time you enter Full GC settings are defragmented).
G1: G1 garbage collector is designed for server applications.
- Parallel and Concurrent: G1 can fully advantage of the hardware in a multi-CPU, multi-core environment, the use of multiple CPU (CPU or CPU core) to shorten the Stop-The-World's pause time, some of the other collectors need to pause the original Java thread execution GC action, G1 collector still allows concurrent Java programs by way continue.
- Generational collection: As with other collectors, generational concept is still preserved in G1. While the G1 may not be required with other collectors will be able to independently manage the entire GC heap, but it can use different ways to deal with the newly created object and has survived for some time to get through GC old object multiple times to get better collecting results.
- Spatial integration: with the CMS "mark - clean up" different algorithms, G1 is based on the whole "mark - finishing" collector algorithm is based on the "Copy" algorithm from the local (between two Region) view but in any case, these two algorithms mean no memory space debris during operation of the G1, the collection offers regular memory available. This feature is conducive to long-running programs, not because they can not find a contiguous memory space prematurely trigger the next GC when allocating large objects.
- Predictable pause: This is the G1 relative to the other big advantage of CMS, G1 is reduced dwell time and the CMS common concern, but in addition to the pursuit of low-G1 pause, the pause time model can establish a predictable, allowing use It is explicitly specified length of time in a segment of M msec, the time consumed in the garbage collection can not exceed N milliseconds, which is characterized in almost real-time Java (RTSJ) of the garbage collector.
The scope of the collection of other collectors before the G1 is a whole new generation or old's, and G1 is no longer the case. When using the G1 collector, Java heap memory layout will vary greatly with other collectors, it will be the entire Java heap is divided into multiple independent regions of equal size (Region), although there are also retained the concept of the new generation and the old age but the new generation and the old year is no longer physically separated, and they are part of the Region (not necessarily consecutive) collection
In G1 collector, the object references between the Region and other objects between the collector and the new generation's old quote, virtual machines are using Remembered Set to avoid a full scan of the heap. Each Region has a G1 in the corresponding Remembered Set, virtual machine discovery procedure of Reference in the type of data write operation, will produce a temporary interruption Write Barrier objects write operation, inspection Reference cited is in a different Region among (in the example of the generational check whether the object is a reference to the old era of the new generation of the object), and if so, then by CardTable the relevant reference information is recorded into the Region's Remembered Set the referenced object belongs. When the memory recovery, adding Remembered Set in the enumeration range GC root node can not guarantee there will not be missing the whole heap scan.
Excluding Remembered Set maintenance operation, the operating G1 collector can be divided into the following steps:
Initial labels (Initial Marking)
Concurrent mark (Concurrent Marking)
The final mark (Final Marking)
Filter Recycling (Live Data Counting and Evacuation)
CMS collector for readers familiar with the operation of the process, the operation of the process must have found the first few steps of G1 and CMS have many similarities. The initial mark phase is just about marking objects GC Roots can be directly linked to, and modify the value of TAMS (Next Top at Mark Start), so that the next phase of the user program to run concurrently, can create new objects in the correct available in the Region, this phase requires a standstill thread, but it takes very short. Concurrent mark is the beginning stage of the heap objects reachability analysis from GC Root, find live objects, this stage takes a long time, but may be complicated by the user program execution. The final stage is marked for amendments made during the concurrent mark due to the continued operation of the user program which led to marked changes in that part of the generated record mark, the virtual machine during this time the object changes recorded in the thread Remembered Set Logs inside, marking the final stage of the need to Remembered Set Logs data is merged into Remembered Set, which need to pause the thread stage, but can be executed in parallel. First, the value of recycling and final cost of each Region to sort recycling at the screening stage, to develop recycling programs according to user desired GC pause time, from the information revealed Sun's point of view, this phase can actually be done with the user program concurrent with the execution, but because only recover a portion of Region, time is user-controllable, but stop user threads will greatly enhance the collection efficiency. We can more clearly see the operation of step G1 collector and the concurrent need to pause stage by Figure 3-11.
The default Java garbage collector: -XX: + UseParallelGC
- UseSerialGC (UseSerialOldGC is discarded)
- UseConcMarkSweepGC
- UseParallelGC
- UseParallelOldGC
- UseParNewGC
- UseG1GC