Why to divide
The generational garbage collection strategy is based on the fact that the life cycle of different objects is not the same . Therefore, different life cycle objects can be collected in different ways to improve the efficiency of recycling.
In the course of running a Java program, a large number of objects are generated, some of which are related to business information, such as session objects, threads, and socket connections in HTTP requests, which are directly linked to the business and therefore have a longer life cycle. However, there are some objects, mainly the temporary variables generated during the run of the program, which are shorter life cycles, such as: string objects, because of their invariant class characteristics, the system will produce a large number of these objects, some objects even once can be recycled.
Imagine that, in the absence of a distinction between object survival time, each garbage collection is to reclaim the entire heap space, take a relatively long time, and because each collection needs to traverse all the surviving objects, but in fact, for the long life cycle of the object, this traversal is not effective, because it may have been traversed many times , but they still exist. Therefore, the generational garbage collection uses the idea of divide and conquer, divides the generations, puts the objects of different life cycles on different generations, and uses the garbage collection method which is most suitable for it in different generations.
How to divide and substitute
:
The total of the virtual machines is divided into three generations: young Generation, old Generation, and persistent (Permanent Generation) . The persistent generation primarily stores the class information of the Java class, which is not related to the Java objects collected by garbage collection. The division of the younger generation and the old generation is more significant for garbage collection.
Young generations:
All newly generated objects are first placed in the younger generation. The goal of the young generation is to collect as quickly as possible those objects with short life cycles. The young generation is divided into three districts. One Eden area, two survivor districts (in general). Most objects are generated in the Eden area. When the Eden Zone is full, the surviving objects will be copied to the Survivor area (one of two), and when the survivor area is full, the surviving objects of this area will be copied to another survivor area, when the survivor is full, Objects that are copied from the first survivor area and that are still alive will be duplicated in the old Age zone (tenured). It should be noted that the two areas of the survivor are symmetrical and have no relationship, so the same area may exist at the same time from Eden copied objects, and from the previous survivor copied objects, and copied to the old quarter only from the first survivor to come over the object. Moreover, there is always an empty survivor area. At the same time, according to the program needs, the survivor area can be configured as multiple (more than two), which can increase the time of the object in the younger generation, reduce the possibility of being put into the old generation.
Old generation:
Objects that survived after n garbage collection in the younger generation will be placed in the old age. Therefore, it can be considered that older generations are storing objects with longer life cycles.
Persistent Generations:
Used to store static files, now Java classes, methods, and so on. The persistence generation has no significant impact on garbage collection, but some applications may dynamically generate or invoke some classes, such as Hibernate, at which point a large, persistent generation space is required to store the new class in these runs. The persistent generation size is set by-xx:maxpermsize=<n>.
what happens when garbage collection is triggered
Because objects are processed in a generational way, garbage collection areas and times are different. There are two types of GC:scavenge GC and full GC .
Scavenge GC
In general, when a new object is generated and the Eden application space fails, the scavenge GC is triggered, GC is performed on the Eden Zone, the non-surviving objects are cleared, and the surviving objects are moved to the survivor area. Then tidy up the two districts of survivor. This method of GC is carried out on the young generation of the Eden area and does not affect the old generation. Because most objects start in the Eden area, and the Eden area is not very large, GC in the Eden area is frequent. Thus, it is generally necessary to use fast and efficient algorithms, so that Eden can be free as soon as possible.
Full GC
Organize the entire heap, including young, tenured and perm. The full GC is slower than the scavenge GC because it needs to be recycled for the entire pair, so it should be as low as possible. In the process of tuning the JVM, a large part of the work is to adjust the FULLGC. The full GC may be caused by the following reasons:
The old generation (tenured) was written full
Persistent generation (Perm) is full
System.GC () is displayed call
Dynamic changes in the domain allocation policy of the heap after the last GC
Generation of garbage collection process schematic
Choosing the right garbage collection algorithm
The garbage collection mechanism can also work on multiple threads, so there are three types of collectors:
Serial collector
Single-threaded processing of all garbage collection work, because there is no need for multi-threaded interaction, so the efficiency is higher. However, it is also not possible to use the advantages of multiple processors, so this collector is suitable for single processor machines. Of course, this collector can also be used on multiprocessor machines with a small amount of data (around 100M). Can be opened using-XX:+USESERIALGC.
Parallel collector
Parallel garbage collection for younger generations, so you can reduce garbage collection time. Typically used on multi-threaded multiprocessor machines. Use-XX:+USEPARALLELGC. Open. The parallel collector, introduced in the j2se5.0 66th update, has been enhanced in Java SE6.0-which can be collected in parallel for older generations. If the older generation does not use concurrent collection, the default is to use a single thread for garbage collection, thereby restricting the ability to scale. Open with-XX:+USEPARALLELOLDGC.
Use-xx:parallelgcthreads=<n> to set the number of threads for parallel garbage collection. This value can be set equal to the number of machine processors.
This collector can be configured as follows:
Max garbage Collection pause: Specifies the maximum pause time for garbage collection, specified by-xx:maxgcpausemillis=<n>. <N> is milliseconds. If this value is specified, the heap size and garbage collection related parameters are adjusted to reach the specified value. Setting this value may reduce the throughput of your app.
throughput: The throughput is the ratio of garbage collection time to non-garbage collected time, set by-xx:gctimeratio=<n>, with a formula of 1/(1+n). For example,-xx:gctimeratio=19 indicates that 5% of the time is used for garbage collection. The default is 99, which is 1% of the time used for garbage collection.
Concurrent Collectors
Can ensure that most of the work is concurrent (the application does not stop), garbage collection only pause for a very small amount of time, this collector is suitable for the response time requirements of high-scale applications. Open with-XX:+USECONCMARKSWEEPGC.
The concurrent collector mainly reduces the time of the old generation to pause, and he uses a separate garbage collection thread to track the available objects without stopping the application. In each old generation garbage collection cycle, the concurrency collector briefly pauses the entire application during the collection, and pauses it again in the collection. The second pause is slightly longer than the first, during which multiple threads are garbage collected at the same time.
The concurrent collector uses the processor for a short pause time. On a system of N processors, the concurrent collection portion is recycled using k/n available processors, typically 1<=K<=N/4.
The concurrent collector is used on a host with only one processor, and a short pause time can also be set to incremental mode mode.
floating garbage: because garbage collection occurs while the app is running, some of the garbage may be generated when the garbage collection is complete, resulting in "floating garbage", which can be reclaimed at the next garbage collection cycle. Therefore, the concurrent collector typically requires 20% of the reserved space for these floating garbage.
Concurrent Mode Failure: The concurrent collector collects when the application is running, so it is necessary to ensure that the heap has sufficient space for the program to use during the garbage collection period, otherwise, the garbage collection is not completed and the heap space is first full. In this case, a "concurrency mode failure" will occur and the entire app will be paused for garbage collection.
Start the concurrency collector: because concurrent collections are collected when the app is running, you must ensure that there is enough memory space for the program to use before the collection is complete, or "Concurrent Mode Failure" will appear. To start a concurrent collection when you specify how many remaining heaps are-xx:cmsinitiatingoccupancyfraction=<n> by setting the
Summary
Serial Processor:
-Applicable: Small data volume (around 100M), single processor and no response time requirements of the application.
--Cons: Only for small applications
Parallel Processor:
--Application: "High throughput Requirements", multi-CPU, application response time is not required for medium and large-scale applications. Examples: Background processing, scientific calculation.
--Cons: Application response time may be extended during garbage collection
Concurrent processors:
-Application: "High response time Requirements", multi-CPU, the application response time has a high demand for medium and large-scale applications. Examples: Web server/Application server, Telecom Exchange, integrated development environment.
JVM garbage Collection Mechanism summary (3): Garbage collector by generation