Java memory overflow and tomcat memory configuration

Java Memory Overflow Detailed

One, the common Java memory overflow has the following three kinds:

1. Java.lang.OutOfMemoryError:Java heap Space----JVM heap (heap) overflow
The JVM will automatically set the JVM heap value when it is started, and its initial space (that is,-XMS) is 1/64 of the physical memory, and the maximum space (-XMX) cannot exceed the physical memory.

You can use options such as the-XMN-XMS-XMX provided by the JVM to set it up. The size of the heap is the sum of young Generation and tenured generaion.

This exception information is thrown in the JVM if 98% of the time is used for GC, and the available heap size is less than 2%.

Workaround: Manually set the size of the JVM heap (heap).

2. Java.lang.OutOfMemoryError:PermGen space----permgen space overflow.
The full name of PermGen space is permanent Generation space, which refers to the permanent storage area of memory.

Why memory overflow, this is because the memory is mainly stored by the JVM class and meta information, class in the load is loaded into the PermGen space area, which is stored in the instance heap area, sun The GC does not clean up permgen space during the main program's run time, so if your app loads many classes, there's a good chance that permgen space will overflow.

Workaround: Manually set the MaxPermSize size

3. Java.lang.StackOverflowError----Stack Overflow
Stack overflows, the JVM is still a stack-based virtual machine, which is the same as C and Pascal. The procedure for calling a function is on the stack and on the fallback.
There are too many "layers" of calls to the constructor to overflow the stack area.
Generally speaking, the general stack area is much smaller than the heap area, because the function call process is often not more than thousands of layers, and even if each function call requires 1K of space (this is approximately equivalent to a C function declared 256 int type variable), then the stack area is just need 1MB of space. The size of the stack is usually 1-2mb.
Often recursion does not have too many levels of recursion, it is easy to overflow.

Workaround: Modify the program.

Second, the solution

In a production environment, Tomcat memory settings are not good enough to be prone to JVM memory overflow.

1 . Tomcat under Linux:

Modify Tomcat_home/bin/catalina.sh
Position Cygwin=false before.
Java_opts= "-server-xms256m-xmx512m-xx:permsize=64m-xx:maxpermsize=128m"

2 . If Tomcat 5 is registered as a Windows service and is started by services, you need to modify the corresponding key values in the registry.

Modify the registry Hkey_local_machine\software\apache software Foundation\tomcat Service Manager\tomcat5\parameters\java, Options on the right
The original value is
-dcatalina.home= "C:\ApacheGroup\Tomcat 5.0"
-djava.endorsed.dirs= "C:\ApacheGroup\Tomcat 5.0\common\endorsed"
-xrs
Join-XMS256M-XMX512M
Restart Tomcat service, set to take effect

3. If Tomcat 6 is registered as a Windows service, or WINDOWS2003 is installed under Tomcat,

It can be changed in/bin/tomcat6w.exe.

4, if you want to start Tomcat in MyEclipse, the above modification will not work, can be set as follows:

In the MYECLIPSE->PREFERENCES->MYECLIPSE->SERVERS->TOMCAT->TOMCATX.X->JDK panel

Optional Java VM arguments added:-xms256m-xmx512m-xx:permsize=64m-xx:maxpermsize=128m

Third, JVM parameter description:

-server: Must be the first parameter, good performance on multiple CPUs
-xms:java Heap Initial size. The default is 1/64 of physical memory.
-xmx:java heap Maximum value. The recommendations are set to half of physical memory. Do not exceed physical memory.

-xx:permsize: Sets the initial size of the memory's permanent save, the default value is 64M. (I use Visualvm.exe to view)

-xx:maxpermsize: Sets the maximum size of the memory's permanent save, the default value is 64M. (I use Visualvm.exe to view)

-xx:survivorratio=2: The size of the survivor pool, default is 2, if garbage collection becomes a bottleneck, you can try to customize the build pool settings

-xx:newsize: The initial size of the newly generated pool. The default value is 2M.

-xx:maxnewsize: The maximum size of the newly generated pool. The default value is 32M.

If the JVM has a heap size greater than 1GB, you should use the value:-xx:newsize=640m-xx:maxnewsize=640m-xx:survivorratio=16, or allocate 50% to 60% of the total size of the heap to the newly generated pool. Adjust the DA object area to reduce the number of full GC.

+xx:aggressiveheap will make XMS meaningless. This parameter allows the JVM to ignore the XMX parameter, frantically eating a g of physical memory, and then eating a G swap.
-XSS: Stack size per thread, "-XSS 15120" This causes JBoss to consume 15M of memory as soon as each additional thread is added (thread), and the best value should be 128K, and the default value seems to be 512k.

-VERBOSE:GC Reality Garbage Collection Information
-xloggc:gc.log specifying garbage collection log files
The heap size of the-xmn:young generation, typically set to one of the 3, 4 points of Xmx
-XX:+USEPARNEWGC: Shortening the time of minor collection
-XX:+USECONCMARKSWEEPGC: Shorten major collection time this option is more appropriate if the heap size is large and major collection time is longer.

-XX:USERPARNEWGC can be used to set up parallel collection "multi-CPU"
-xx:parallelgcthreads can be used to increase the degree of parallelism "multi-CPU"
-XX:USEPARALLELGC can be set to use parallel purge collector "multi-CPU"

Java memory overflow and tomcat memory configuration