JVM Memory Model and garbage collection

The Java heap is described as follows:

Heap = {old + new = {Eden, from, }}


Memory is composed of perm and heap.

Heap = {old + new = {Eden, from, }}

JVM

The memory model has two major blocks:

New generation,

The other is

Old Generation.

In

New Generation

Is called

Eden

Space, mainly used to store new objects, there are two more

Specified vor spaces (from, ),

They are used to store objects that survive each garbage collection. In

Old Generation

, Mainly stores memory objects with a long life cycle in the application.

Permanent generation

, Mainly used to put

JVM

Reflection objects, such as class objects and method objects.

 

Description of garbage collection:

In

New Generation

Block, garbage collection is generally used

Copying

. Each time

GC

When the object is alive

Eden

Copy to

Using vor space,

When

Survivor Space

When the space is full

,

The rest

Live

The object is directly copied

Old Generation

. Therefore

GC

After,

Eden

The memory block is cleared. In

Old Generation

Block, garbage collection is generally used

Mark-compact

But reduces memory requirements.


Garbage collection is divided into multiple levels. garbage collection in the old section will be collected when the level 0 is full. garbage collection in the Level 1 or above will only be collected in the new section, memory overflow usually occurs in the old segment or perm
After garbage collection, there is still no memory space to accommodate new Java objects.

When a URL is accessed, the memory application process is as follows:
A. JVM will try to initialize a memory area for the relevant Java object in Eden
B. When the Eden space is sufficient, the memory application is completed. Otherwise, go to the next step.
C. JVM tries to release all inactive objects in Eden (which belongs to 1 or more advanced garbage collection). If the Eden space is not enough to put new objects, try to put some active objects in Eden into the same vor Area
D. The primary vor area is used as the intermediate swap area of Eden and old. When the old area has sufficient space, objects in the primary vor area will be moved to the old area. Otherwise, objects in the primary vor area will be retained.
E. When there is not enough space in the old area, JVM will perform full garbage collection in the old area (Level 0)
F. after full garbage collection, if the primary VOR and old areas still cannot store some objects copied from Eden, the JVM cannot create a memory area for the new object in the Eden area, "Out of memory error" appears"

JVM optimization suggestions:

MS/MX: defines the total size of the Young + old segment, Ms is the size of the Young + old memory at JVM startup, and MX is the maximum size of the Young + old memory that can be occupied. In the user production environment, these two values are generally set to the same, to reduce the overhead of the system in the memory application during running.
Newsize/maxnewsize: defines the size of the young segment. newsize is the memory size of young when JVM is started, and maxnewsize is the maximum memory size of young. In the user production environment, these two values are generally set to the same, to reduce the overhead of the system in the memory application during running.
Perm
Size/maxperm
Size: defines perm.
Segment Size, perm
Size: perm at JVM startup
Memory size; maxperm
The size is the maximum available perm
Memory size. In the user production environment, these two values are generally set to the same, to reduce the overhead of the system in the memory application during running.
Survivorratio: Set the ratio of VOR space to Eden space.

Possibility of memory overflow

1. Old segment Overflow
This memory overflow is one of the most common causes, which may be caused:
1) The set memory parameter is too small (MS/MX, newsize/maxnewsize)
2) program Problems
A single program continues to process memory consumption, such as string processing thousands of times. stringbuffer is recommended for string processing. At this time, no memory overflow error will be reported, but the system will continue to crash
Other requests cannot be processed.
Dump acquisition (see system issue diagnosis). The memory size applied by a single program is too large. Some programs apply for dozens or even hundreds of megabytes of memory, at this time, the JVM will also experience memory overflow because it cannot apply for resources.
You must first find the relevant functions and then hand them to the programmer for modification. To find the relevant program, you must search for them in the Apache log.
After a Java object is used up, the referenced object is not destroyed, so that the JVM considers it to be an active object and does not recycle it. In this way, it occupies a large amount of memory and cannot be released. As there is no memory analysis tool on the market that has little impact on the system, it can only be located with programmers.

2. perm
Segment Overflow
Generally, perm
The current solution is as follows:
1) Change perm
The size is expanded. Generally, MB can meet the requirements.
2) If you have no choice, you can only add the Servlet Path to the classpath. However, this is generally not recommended.

3. c Heap Overflow
The system has no restrictions on C heap. Therefore, when a problem occurs in C heap, the memory occupied by Java processes will continue to grow until all available system memory is occupied.

Others:

JVM has two GC threads. The first thread is responsible for revoking heap's young zone. When the heap is insufficient, the second thread traverses the heap 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-XMS cannot be set too large, because the second thread is forced to run will reduce JVM performance.

Why does GC occur frequently in some programs? There are the following reasons: l
The program calls system. GC () or runtime. GC (). L
Some middleware software calls their own GC methods. In this case, you need to set parameters to disable these GC methods. L
Java heap is too small. Generally, the default heap value is very small. L
Objects that are frequently instantiated are release objects. In this case, try to save and reuse objects, for example, using stringbuffer () and string (). If you find that after each GC, the remaining heap space will be 50% of the total space, which indicates that your heap is healthy. Many Java programs on the server end have a better free space of 65% after each GC. Experience: 1. server-side JVM should set-XMS and-xmx to the same value. To optimize GC, it is recommended that the-xmn value be equal to 1/3 [2] of-xmx. 2. It is best for a GUI program to run GC every 10 to 20 seconds and complete GC every time within half a second [2]. Note: 1. Increasing the heap size reduces the GC frequency, but also increases the GC time. When GC is run, all user threads are paused, that is, Java applications do not work during GC. 2. The heap size does not determine the memory usage of the process. The memory usage of a process must be greater than the value defined by-xmx, Because Java allocates memory for other tasks, such as the stack of each thread. 2. stack settings each thread has its own stack.

-XSS	For each thread Stack Size

The stack size limits the number of threads. If the stack is too large, the memory may leak. -The XSS parameter determines the stack size, for example,-xss1024k. If the stack is too small, the stack may leak. 3. The hardware environment also affects GC efficiency, such as the machine type, memory, swap space, and number of CPUs. If your program needs to frequently create many transient objects, this will lead to frequent jvm gc. In this case, you can increase the machine memory to reduce the use of swap space [2]. The first type of GC is single-thread GC, which is also the default GC ., This GC is applicable to single-CPU machines. The second type is throughput GC, which is a multi-thread GC. It is suitable for programs with multiple CPUs and a large number of threads. The second type of GC is similar to the first type of GC. The difference is that the GC is multi-threaded in the young area, but in the old area and the first one, the single thread is still used. -XX: + useparallelgc parameter to start the GC. The third type is concurrent low pause GC, which is similar to the first type. It is suitable for multiple CPUs and requires shorter time for program stagnation caused by GC. This GC can be used to run applications in the old zone. -XX: + useconcmarksweepgc parameter to start the GC. The fourth type is incremental low pause GC, which is applicable to the requirement to shorten the time of program stagnation caused by GC. This GC can be used to reclaim some old objects in the young area. -The xincgc parameter starts the GC.