Java garbage Collection minor GC and major GC

The Java heap is described as follows:

Memory consists of perm and heap. where heap = {old + NEW = {Eden, from, to}}

The JVM memory model is divided into two chunks:

New Generation: The newly created object of the program is to allocate memory from the Cenozoic, and the Cenozoic is made up of Eden Space and two blocks of the same size survivor space (usually called S0 and S1 or from and to), which can be specified by the-XMN parameter to the Cenozoic size. You can also adjust the size of Eden space and survivor space by-xx:survivorration.

One is NEW Generation and the other is old Generation. In new generation, there is a space called Eden, which is mainly used for storing new objects, and two survivor Spaces (From,to), which are used to store objects that survive each garbage collection. In old Generation, a memory object with a long life cycle in the application, and a permanent Generation, are used primarily to put the JVM's own reflective objects, such as class objects and method objects.

Garbage Collection Description:

In the new generation block, garbage collection generally uses the copying algorithm , which is fast. At each GC, the surviving objects are first copied from Eden to a survivor space, and when the survivor space is full, the remaining live objects are copied directly to the old generation. Therefore, after each GC, the Eden memory block is emptied . In the old generation block, garbage collection generally uses the mark-compact algorithm , which is slower, but reduces memory requirements.

Garbage collection sub-level, Level 0 for all (full) garbage collection, the old section of garbage collection, 1 or more of the garbage collection, will only reclaim new garbage, memory overflow usually occurs after the old or perm segment garbage collection, There is still no memory space to accommodate new Java objects.

Now collectors are using generational collection algorithms, and the heap is divided into the new generation and the old age. The new generation primarily stores newly created objects and objects that have not yet entered the old age. The old age stores the objects that survived by several new generation GC (Minor GC).

　　

　　Minor GC: The new generation GC, refers to the garbage collection action occurring in the Cenozoic, because most of the Java objects have the characteristics of the emerging, so the Minor GC is very frequent, the general recovery speed is relatively fast.

　　

Laosheng generation: Used to store after a number of Cenozoic GC still surviving objects, such as cache objects, new objects may also be directly into the old age, there are two main cases: ① large objects, can be set by the start parameter-xx:pretenuresizethreshold=1024 (in bytes, The default is 0) to represent when more than the new generation is not allocated, but directly in the old age distribution. ② a large Array object, with no reference to the outer object in the tangent array. Older generations accounted for the memory size of-xmx corresponding to the value minus-xmn corresponding value.

　　Major gc/full GC: The old GC, a GC that occurred in the old age, appeared Major GC, often accompanied at least once minor GC (but not absolutely, in the Parallelscavenge Collector's collection strategy directly Major GC's policy selection process). The speed of the MAJORGC is generally 10 times times slower than the minor GC.

When a URL is accessed, the memory application process is as follows:

A. JVM tries to initialize a chunk of memory in Eden for related Java objects

B. When the Eden space is sufficient, the memory request ends. Otherwise to the next

C. The JVM tries to free all inactive objects in Eden (this is a garbage collection of 1 or more advanced), and attempts to put some of the active objects in Eden into the survivor area if Eden space is still insufficient to fit into the new object after release

D. The survivor area is used as an intermediate swap area for Eden and old, and when the old area is sufficiently large, the objects in the Survivor area will be moved to the old area, otherwise they will remain in the survivor area.

E. When there is not enough space in the old area, the JVM performs a full garbage collection in the old area (level 0)

F. After a complete garbage collection, "Out of memory error" occurs if the survivor and old areas still cannot hold portions of objects copied from Eden, causing the JVM to be unable to create an area for the new object in the Eden area

JVM Tuning Recommendations:

MS/MX: Defines the total size of the Young+old segment, MS is the memory size Young+old when the JVM starts, and MX is the maximum amount of young+old memory that can be occupied. These two values are generally set to the same on a user production environment to reduce the overhead that the system spends on memory requests during run time.

Newsize/maxnewsize: Defines the size of the young segment, NewSize the memory size of young when the JVM starts, and maxnewsize is the maximum amount of young memory that can be occupied. These two values are generally set to the same on a user production environment to reduce the overhead that the system spends on memory requests during run time.

Permsize/maxpermsize: Defines the size of the perm segment, permsize the memory size perm when the JVM starts, and maxpermsize the maximum amount of perm memory that can be occupied. These two values are generally set to the same on a user production environment to reduce the overhead that the system spends on memory requests during run time.

Survivorratio: Setting the proportions of the survivor Space and Eden space

Possibility of memory overflow

1. Old segment Overflow

This memory overflow is one of the most common scenarios, and may be caused by:

1) Set the memory parameters too small (ms/mx, newsize/maxnewsize)

2) Procedural issues

A single program continues to consume memory processing, such as string processing that loops thousands of times, and StringBuffer should be recommended for string processing. At this time will not report memory overflow error, but will make the system continuous garbage collection, unable to process other requests, the related problem program can be obtained through threaddump (see the system Problem Diagnosis Chapter) a single program request memory is too large, some programs will apply for dozens of or even hundreds of megabytes of memory, At this point, the JVM will also be unable to request a resource for memory overflow, the first to find the relevant functions, and then to the programmer to modify, to find the relevant program, must be found in the Apache log.

When the Java object is used, the object it references is not destroyed, making the JVM think that he is still an active object without recycling, so that the cumulative amount of memory is consumed and cannot be freed. Since there is no memory analysis tool that has little impact on the system, it can only be positioned with the programmer.

2. Perm Segment Overflow

The current workaround is because the perm segment is typically loaded with a large number of servlet classes that cause overflow:

1) Expand the PermSize, the general 256M can meet the requirements

2) If you have no choice, you can only add the path of the servlet to Classpath, but it is generally not recommended to do so

3. C Heap Overflow

The system has no restrictions on the C heap, so when the problem occurs with the C heap, the memory of the Java process continues to grow until all available system memory is consumed

Other:

The JVM has 2 GC threads. The first thread is responsible for recovering the young area of the heap. The second thread traverses the heap when the heap is insufficient and upgrades the young area to the older area. The size of the older area is equal to-xmx minus-xmn, and the value of the-XMS cannot be set too large because the second thread is forced to run to degrade the performance of the JVM.

Why do some programs frequently occur in GC? There are the following reasons:

L System.GC () or RUNTIME.GC () is called within the program.

L Some middleware software calls its own GC method, at which time you need to set parameters to prohibit these GC.

The heap in Java is too small, and the default heap values are generally small.

L Frequent instantiation of objects, release objects. At this point, try to save and reuse objects, such as using StringBuffer () and string ().

If you find that after each GC, the remaining space in the heap will be 50% of the total space, which means your heap is in a healthy state. Many server-side Java programs have a better 65% space left after each GC.

Experience:

1. The server-side JVM is best to set-XMS and-xmx to the same value. In order to optimize the GC, it is best to make the-XMN value approximately equal to-xmx 1/3[2].

2. A GUI program is best to run the GC once every 10-20 seconds, each time within half a second [2].

Attention:

1. Increasing the size of the heap decreases the frequency of the GC, but it also increases the time of each GC. And when the GC runs, all the user threads are paused, that is, during the GC, the Java application does not do any work.

2. The heap size does not determine the amount of memory used by the process. The memory usage of the process is greater than the value defined by-XMX because Java allocates memory for other tasks, such as the stack for each thread.

2. Stack settings

Each thread has his own stack.

-XSS stack size per thread

The size of the stack limits the number of threads. If the stack is too large, it will cause memory leaks. The-XSS parameter determines the stack size, such as-xss1024k. If the stack is too small, it can also cause the stack to spill.

3. Hardware environment

The hardware environment also affects the efficiency of the GC, such as the type of machine, memory, swap space, and number of CPUs.

If your program needs to create many transient objects frequently, it will cause the JVM to frequent GC. In this case you can increase the machine's memory to reduce the use of swap space [2].

4. 4 GC Types

The first is a single-threaded GC, which is also the default GC. , the GC applies to single-CPU machines.

The second is the throughput GC, which is a multi-threaded GC that is suitable for multi-CPU applications that use a large number of threads. The second GC is similar to the first GC, except that the GC is multithreaded in the collection of young, but in the old area it is still single-threaded, as in the first type. The-XX:+USEPARALLELGC parameter starts the GC.

The third, concurrent low Pause GC, is similar to the first, applies to multiple CPUs, and requires shortening the time that the GC causes the program to stall. This GC can run the application at the same time as the recycle in the old area. The-XX:+USECONCMARKSWEEPGC parameter starts the GC.

The fourth, incremental low Pause GC, is intended to shorten the time that the GC causes the program to stall. This GC can reclaim part of the old object while recovering from the young area. The-XINCGC parameter starts the GC.

1. Heap Settings and garbage collection

Java memory is divided into 3 zones, young,old and permanent. Young saves the object that was just instantiated. When the area is filled, the GC moves the object to the old area.

The first two areas are usually called heap areas, and the permanent area is responsible for preserving the reflected object, class meta information, and so on.

The exception for memory overflow in the heap area is: Java.lang.OutOfMemoryError:Java heap space,

A memory overflow occurred in the permanent area is: Outofmemoryerror:permgen space.

The heap allocation for the JVM can be set using the-x parameter,

-xms

Initial Heap Size

-xmx

Java Heap Maximum Value

-xmn

The heap size of young generation

The JVM has 2 GC threads. The first thread is responsible for recovering the young area of the heap. The second thread traverses the heap when the heap is insufficient and upgrades the young area to the older area. The size of the older area is equal to-xmx minus-xmn, and the value of the-XMS cannot be set too large because the second thread is forced to run to degrade the performance of the JVM.

Why do some programs frequently occur in GC? There are the following reasons:

L System.GC () or RUNTIME.GC () is called within the program.

L Some middleware software calls its own GC method, at which time you need to set parameters to prohibit these GC.

The heap in Java is too small, and the default heap values are generally small.

L Frequent instantiation of objects, release objects. At this point, try to save and reuse objects, such as using StringBuffer () and string ().

If you find that after each GC, the remaining space in the heap will be 50% of the total space, which means your heap is in a healthy state. Many server-side Java programs have a better 65% space left after each GC.

Experience:

1. The server-side JVM is best to set-XMS and-xmx to the same value. In order to optimize the GC, it is best to make the-XMN value approximately equal to-xmx 1/3[2].

2. A GUI program is best to run the GC once every 10-20 seconds, each time within half a second [2].

Attention:

1. Increasing the size of the heap decreases the frequency of the GC, but it also increases the time of each GC. And when the GC runs, all the user threads are paused, that is, during the GC, the Java application does not do any work.

2. The heap size does not determine the amount of memory used by the process. The memory usage of the process is greater than the value defined by-XMX because Java allocates memory for other tasks, such as the stack for each thread.

2. Stack settings

Each thread has his own stack.

-xss

stack for each thread

The size of the stack limits the number of threads. If the stack is too large, it will cause memory leaks. The-XSS parameter determines the stack size, such as-xss1024k. If the stack is too small, it can also cause the stack to spill.

3,permanent District

The Outofmemoryerror:permgen space,class that may be encountered when the program is released will be placed in PermGen space when it is loaded.

Unlike the heap area where the class instance (Instance) is stored, the GC (garbage Collection) does not operate on the main program

PermGen space for cleanup, so if you have a lot of classes in your app, you're likely to have permgen space errors,

This error is common when the Web server pre-compile the JSP.

Adjusted by-xx:permsize=64m-xx:maxpermsize=128m.

4. Hardware environment

The hardware environment also affects the efficiency of the GC, such as the type of machine, memory, swap space, and number of CPUs.

If your program needs to create many transient objects frequently, it will cause the JVM to frequent GC. In this case you can increase the machine's memory to reduce the use of swap space [2].

　　

Transferred from: http://wenku.baidu.com/link?url=lK0U3qmwLMDsUZe2rq65yzMKsbPADs72ovl78Hbg3dz-0n910QX5ZbSPLrTMWbG5efYaYG_ V8zmy4n-lspyl42jnqsctihzrlyvt6pvmp9s

Java garbage Collection minor GC and major GC