Garbage collector __java in Java

1. Serial Collector

The serial collector is a single thread collector, but its "single-threaded" meaning does not simply mean that it uses only one CPU or a collection thread to do the garbage collection, and more importantly, when it does garbage collection, all the other worker threads must be paused until the collection is complete.

Serial collector Until now, it is still the default Cenozoic collector that Java virtual machines run in client mode. It also has a better place than other collectors: simple and efficient (one-line turndown with other collectors), and for an environment that limits a single CPU, the serial collector, with no threading overhead, is naturally able to achieve the highest single thread collection efficiency by concentrating on garbage collection. In the user's desktop application scenario, the memory allocated to the virtual machine management is generally not very large, collecting a few 10 trillion or even one hundred or two hundred trillion of new generation (only the new generation of memory, desktop applications are basically not larger), the pause time can be controlled in dozens of milliseconds up to 100 milliseconds, as long as not frequent, This pause is acceptable. Therefore, the serial collector is a good choice for running virtual machines in client mode.

2. Parner collector

The Parnew collector is one of the garbage collectors in the Java virtual machine. It is a multi-threaded version of the serial collector, except for garbage collection using multiple threads, which includes all the control parameters available to the serial collector (for example:-xx:survivorratio,-xx:pretenuresizethreshold,- Xx:handlepromotionfailure, collection algorithms, Stop the world, object allocation rules, recycling policies, etc. are consistent with the serial collector)

Parnew is the preferred generation collector for many virtual machines running in server mode, and in JDK1.6 and prior versions, it works with the CMS collector in addition to the serial collector.

3. Parallel Scavenge collector

The Parallel scavenge collector is a Cenozoic collector that uses a replication algorithm.

Parallel scavenge collector is characterized by its focus is different from other collectors, CMS and other collector concerns are as much as possible to shorten the garbage collection when the user thread downtime, while the Parallel scavenge collector's goal is to achieve a controllable value throughput. Throughput is the ratio of the CPU's time to running user code to the total CPU consumption, i.e. throughput = Running user code time/(running user code time + garbage collection time). The virtual machine runs for 100 minutes, where the garbage collection takes 1 minutes, and the throughput is 99%.

The Parallel scanvenge Collector provides two parameters for precise control of throughput, which is the-xx:maxgcpausemillis parameter that controls the maximum garbage collector pause time, and the-xx:gctimeratio that directly sets the throughput size.

The Maxgcpausemills parameter allows a value that is greater than 0 milliseconds, and the collector ensures that the memory collection does not exceed the set value as much as possible. The reduction in GC pause time is in exchange for sacrificing throughput and Cenozoic space: the system to reduce the Cenozoic, collecting 300MB time is certainly faster than the collection of 500MB, which also led to more frequent garbage collection, the original 10 seconds to collect, each pause 100 milliseconds, now become 5 seconds to pause, 70 milliseconds per pause. The pause time is indeed falling, but the throughput has dropped.

The value of the Gctimeratio parameter should be an integer greater than 0 and less than 100, which is the ratio of garbage collection time to total time, equivalent to the reciprocal of throughput. If you set the parameter to 19, the maximum allowable GC time is 5% of the total time (i.e. 1/(1+19)), the default value is 99, and the garbage collection time is maximum allowable 1%.

The Parallel scavenge collector also has a parameter-xx:useadaptivesizepolicy. This switch parameter, when opened, does not need to manually specify the proportions of the new Generation (-XMN), the Eden area and the Survivor Area (-xx:survivorratio), and the size of the age of promotion (-XX: Pretenuressizethreshold), the virtual opportunity collects performance monitoring information based on the current system's operation and dynamically adjusts these parameters to provide the most appropriate pause time or maximum throughput.

4. Serial Old collector

Serial old is the older version of the serial collector, which is a single-threaded garbage collector, using the "tag-collation" algorithm. The main purpose of this collector is also to use virtual machines in client mode. In the case of server mode, it has two main uses, one for use with the parallel scavenge collector in JDK1.5 and prior versions. Another use is the back plan for the CMS collector. Used when the concurrent Mode failure is collected concurrently.

5. Parallel Old collector

The Parallel old collector is the older version of the Parallel scavenge collector, using multi-threaded and "tag-organize" algorithms. The collector was only available in JDK1.6, before the new generation of parallel scavenge collectors had been in a more awkward state. The reason is that the new generation chose the parallel scavenge collector, so the old age has no choice but to choose the serial. Due to the old age serial in the service end of the application of the "drag", the use of parallel scavenge collectors may not be able to achieve greater throughput in the overall application of the effect, because the single thread of the old generation collection can not fully utilize the server's multiple CPU processing capacity. In the old age and high hardware environment, this combination of throughput is not necessarily a combination of parnew plus cms.

When you know that the parallel old collector appears, the throughput priority collector finally has a more authentic combination of applications that gives priority to parallel scavenage plus parallel old collectors when it comes to throughput and CPU-sensitive situations.

6. CMS Collector

The CMS (Concurrent Mark Sweep) collector is a collector that targets the shortest recovery pause time, a multithreaded collector that is implemented with a "tag-purge" algorithm that is more complex to operate than several previous collectors. The whole process is divided into the following 4 steps:

1 initial mark (CMS inital mark)
2) concurrent mark (CMS concurrent Mark)
3) re-tagging (CMS remark)
4) Concurrency Cleanup (CMS concurrent sweep)

Among them, the initial marking, the re-crit these two steps still need "Stop the World". The initial tag is simply to mark the object in which GC Roots can be directly associated, fast, and the concurrent marking phase is the process of GC Roots tracing, while the re-marking truncation is the marking record of the part of the object that causes the markup to change as the user program continues to function during the concurrent markup , the pause time in this phase is generally slightly longer than the initial mark truncation, but is far shorter than the concurrent markup time.

CMS is a good collector, but still has the following 3 obvious disadvantages

1 The CMS collector is very sensitive to CPU resources. In the concurrency phase, it does not cause the user thread to pause, but it slows down the application because it consumes some resources and reduces the total throughput.

2) The CMS collector is unable to handle floating garbage, and a "Concurrent Mode failure" failure may result in the production of another full GC. Since the CMS concurrent cleanup phase user thread is still running, accompanied by the program running naturally there will be new garbage constantly generated, this part of the garbage appears in the marking process, the CMS can not be processed during the collection process. We have to wait for the next GC to clear it off.

3) CMS is a collector based on the "tag-clean" algorithm. When the collection is over there will be a lot of space debris, space debris too much, will bring trouble to large object allocation, want to old age there is still a lot of space remaining, but can not find enough contiguous space to allocate the current object, had to trigger a full GC in advance.

7. G1 Collector

G1 is a server-side application-oriented garbage collector. Compared with other collectors, G1 has the following characteristics:

1 Parallel and Concurrency: G1 can take full advantage of the hardware advantages of multiple CPUs, multi-core environments, use multiple CPUs to shorten the Stop-the-world pause time, and some other collectors would have to pause Java threads to perform GC actions, The G1 collector can still allow Java programs to continue to execute in a concurrent manner.

2) Generational collection: As with other collectors, the concept of generational is still retained in G1. Who's to be able to G1 the entire GC pair without the need for other collectors, but it can take a different approach to processing the newly created objects and old objects that have survived for some time and survived multiple GC to get a higher collection effect.

3) Space integration: Unlike the CMS "mark-clean" algorithm, G1 is based on the "tag-collation" algorithm to implement the Collector, from the local (two region) based on the "Replication" algorithm, but anyway, Both of these algorithms mean that no memory space will be generated during the G1 run, and that the collection will provide regular memory availability. This feature is useful for long-running programs, and allocating large objects does not trigger the next GC in advance because it cannot find the practice memory space.

4. Predictable pauses: This is another major advantage of G1 compared to the CMS, reducing the pause time is G1 and CMS common concern, but G1 in addition to the pursuit of low pause, but also to establish a predictable pause time model, can allow users to explicitly specify in a length of m millisecond time fragment, The time spent on garbage collection must not exceed n milliseconds, which is almost already characteristic of real time Java (RTSJ) garbage collectors.

The collection of other collectors before G1 is a whole new generation or an old age, and G1 is not. In this way, when using the G1 collector, the memory layout of the Java heap differs greatly from that of other collectors, which divides the entire Java heap into separate areas of equal size (Region). Although the concept of Cenozoic and old age is preserved, the Cenozoic and old age are no longer physically isolated, they are region (no continuous sets are required).

In G1 collection, object references between region and the generation and age of other collectors, virtual machines use remembered set to avoid full heap scanning. Each region in the G1 has a corresponding remembered Set, and the Virtual machine Discovery program writes to the reference type of data, producing a write barrier to temporarily interrupt writes. Check to see if the object referenced by reference is in a different region (in the example of a generational, check if an object in the old age references a new generation of objects), and if so, The relevant reference information is recorded in the remembered set of the region which the reference object belongs to by Cardtable, when the memory recycle is, if the remembered set can guarantee that there is no omission in the enumeration scope of GC root node.

If you do not calculate the operation to maintain remembered set, the operation of the G1 collector can be roughly divided into the following steps: initial tag concurrency tag final tag filter Recycle