Tomcat memory overflow analysis and solution _java

The JVM manages two types of memory, heaps, and not heaps. The heap is for developers, it is created when the JVM is started, and not the heap is left to the JVM itself to hold the class information. Unlike heaps, the GC does not release space during the runtime.

One, memory overflow type
1, Java.lang.OutOfMemoryError:PermGen Space
The JVM manages two types of memory, heaps, and not heaps. The heap is for developers, it is created when the JVM is started, and not the heap is left to the JVM itself to hold the class information. Unlike heaps, the GC does not release space during the runtime. If the Web app uses a large number of third-party jars or if the application has too many class files and happens to have a small set of maxpermsize settings, it can cause this memory to overflow too much, or it will not clean up the previously loaded environment when the tomcat is hot deployed. will only change the context to a new deployment, the contents of the non-dump will be more and more.

PermGen space is the full name of permanent Generation spaces, refers to the permanent storage area of memory, this memory is mainly by the JVM storage class and meta information, class in the loader will be placed in the PermGen In space, it differs from the heap region of the class instance (Instance), and GC (garbage Collection) does not clean up permgen spaces during the runtime of the main program, so if you have a class in your application, PermGen space errors are most likely to occur when the Web server makes pre compile for JSPs. If your web app uses a large number of third-party jars that are larger than the JVM default size (4M), this error message is generated.
One of the best configuration examples: (after my verification, since the use of this configuration, there has been no Tomcat dead)

Set java_opts=-xms800m-xmx800m-xx:permsize=128m-xx:maxnewsize=256m-xx:maxpermsize=256m
In Linux, add a code like red to the tomcathome/conf/catalina.sh: You can increase the memory of the Tomcat JVM, which is not prone to memory overflow!
#-----Execute The requested Command-----------------------------------------
Java_opts= "-server-xms512m-xmx2048m-xx:permsize=128m-xx:maxnewsize=256m-xx:maxpermsize=256m"
# Bugzilla 37848:only Output This if we have a TTY
2, Java.lang.OutOfMemoryError:Javaheap space
The first is a supplement, and the main problem is that it appears in this case. Its default space (that is,-XMS) is 1/64 of the physical memory, and the maximum space (-XMX) is 1/4 of the physical memory. If the memory remains less than 40%,JVM, the value of the heap to the XMX setting is increased, and the memory surplus exceeding 70%,JVM reduces the heap to XMS setting. Therefore, the server's xmx and XMS settings should generally be set to the same to avoid the size of the virtual machine heap after each GC. Assuming that the physical memory is infinite, then the maximum JVM memory is related to the operating system, the average 32-bit machine is between 1.5g and 3g, and 64-bit will not have a limit.

Note:If the XMS exceeds the XMX value, or if the sum of the heap maximum and non heap maximum exceeds the physical memory or the maximum operating system limit, the server will not start up.

Garbage Collection Role of GC
The frequency with which the JVM invokes GC is still high, with two main cases of garbage collection:
When the application thread is idle, and the other is insufficient for the Java memory heap, the GC is invoked continuously, and an out of memory error is reported if the continuous collection does not solve the problem of insufficient memory heap. Because this exception is determined by the system's operating environment, it is not possible to anticipate when it will appear.
According to the mechanism of GC, the operation of the program will cause the change of the system operating environment and increase the chance of the GC's triggering.
To avoid these problems, programs should be designed and written to avoid the memory footprint of garbage objects and the cost of GC. displaying call System.GC () only suggests that the JVM need to recycle garbage objects in memory, but not immediately.
One is not able to solve the situation of memory resource depletion, in addition, it will increase the consumption of GC.

Second, the JVM memory area composition
Simply say heap and Stack in Java
Java is divided into two types of memory: one is stack memory, the other is heap memory
1, the basic types of variables defined in the function and object reference variables are allocated in the function stack memory;
2, heap memory is used to store objects and arrays created by new
When you define a variable in a function (code block), Java allocates memory space for this variable in the stack, and when the scope of the variable is exceeded, Java automatically releases the memory space allocated for the variable; the memory allocated in the heap is managed by the Java Virtual machine's automatic garbage collector
The advantage of the heap is that the memory size can be dynamically allocated, and the lifetime does not have to be told to the compiler beforehand because it allocates memory dynamically at run time. The disadvantage is to dynamically allocate memory at runtime, and access speed is slow;
The advantage of the stack is that the access speed is faster than the heap, and the disadvantage is that the data size in the stack and the lifetime must be determined without flexibility.

the Java heap is divided into three areas: New, old, and permanent
The GC has two threads:
The newly created object is assigned to the new area and is moved to the old area by the GC worker thread when it fills up, and when the old is filled, it triggers all the objects in the heap memory that the GC main thread traverses. The size of the old area equals Xmx minus-xmn
Java Stack Storage
Stack adjustment: Parameters are +usedefaultstacksize-xss256k, indicating that each thread can request 256k of stack space
Every thread has his own stack.

Iii. How the JVM sets virtual memory
Tip: This exception message is thrown in the JVM if 98% of the time is for GC and the available heap size is less than 2%.
Tip: Heap Size is not greater than 80% of the available physical memory, typically to set the-XMS and-XMX options to the same, and-xmn to the-XMX value of 1/4.
Tip: The initial memory allocated by the JVM is specified by-XMS, which defaults to 1/64 of the physical memory; The maximum allocated memory of the JVM is specified by-XMX, which defaults to 1/4 of the physical memory.
When the default free heap memory is less than 40%, the JVM increases the maximum limit for the heap until-xmx, and when the free heap memory is greater than 70%, the JVM reduces the heap until the minimum limit of-XMS. Therefore, the server generally sets-xms and-xmx equal to avoid resizing the heap after each GC.
Tip: The maximum value of JVM memory is related to the operating system, assuming that the physical memory is infinitely large.
To put it simply, the 32-bit processor, while the controllable memory space has 4GB, will give a limit to the specific operating system
This limitation is generally 2GB-3GB (generally the Windows system under the 1.5g-2g,linux system is 2g-3g), and more than 64bit of processors will not have a limit

Note:If the XMS exceeds the XMX value, or if the sum of the heap maximum and non heap maximum exceeds the physical memory or the maximum operating system limit, the server will not start up.

Tip:Set newsize, Maxnewsize equal, "new" size is best not greater than "old" half, because old area if not enough General Assembly frequently trigger "main" GC, greatly reduce performance
The JVM uses-xx:permsize to set a heap-memory initial value, which defaults to 1/64 of physical memory;
The maximum amount of xx:maxpermsize memory is set by the default, which is 1/4 of the physical memory.
Workaround: Manually set heap Size
Modify Tomcat_home/bin/catalina.bat
In the "echo" Using catalina_base: $CATALINA _base "", add the following line:
Java_opts= "-server-xms800m-xmx800m-xx:maxnewsize=256m"

Iv. use of performance inspection tools
To locate a memory leak:
The Jprofiler tool is primarily used to check and track the performance of the system (which is limited to Java development). Jprofiler can monitor the usage of garbage collection, thread running condition and so on, so as to monitor the operation of the JVM and its performance well.
1. Application server memory for a long time unreasonable occupation, memory is often high occupancy, it is difficult to reclaim to low.