Java Virtual memory settings

This problem is mainly caused by the Java.lang.OutOfMemoryError:Java heap space.

There are two workarounds: 1. Setting environment variables

Workaround: Manually set the heap size
Modify Tomcat_home/bin/catalina.sh
Set java_opts=-xms32m-xmx512m
Can be changed according to the memory of your machine.

2, java-xms32m-xmx800m ClassName

is to add this parameter when executing the Java class file, where ClassName is required to perform the real class name. (including package name)
This solves the problem. And the speed of execution is much faster than when it is not set.

If you can use Eclispe at the time of testing, you will need to enter-xms32m-xmx800m This parameter in the VM arguments in Eclipse->run-arguments.

The startup parameters were later modified in Eclilpse, and the-xms32m-xmx800m was added to the VM arguments to solve the problem.

One, Java.lang.OutOfMemoryError:PermGen space

the full name of PermGen space is permanent Generation space, which refers to the permanent storage area of memory,
this memory is primarily stored by the JVM with class and meta information, and class is placed in PermGen space when it is loader .
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. If you use a large number of third-party jars under your web app, its size
The default size of the JVM (4M) is exceeded, and this error message is generated.
Workaround: Manually set the MaxPermSize size

Modify Tomcat_home/bin/catalina.sh
Add the following line to the "echo" Using catalina_base: $CATALINA _base "":
Java_opts= "-server-xx:permsize=64m-xx:maxpermsize=128m
Recommendation: Move the same third-party jar files to the Tomcat/shared/lib directory, which can reduce the memory consumption of the jar document.

Second, Java.lang.OutOfMemoryError:Java heap space

Heap Size Setting
The JVM heap setting is the set of memory space that the JVM can provision during the run of the Java program. The JVM automatically sets the value of the heap size when it is started.
Its initial space (that is,-XMS) is 1/64 of the physical memory, and the maximum space (-XMX) is 1/4 of the physical memory. You can use options such as the-XMN-XMS-XMX provided by the JVM to
To set. The size of Heap size is the sum of young Generation and tenured generaion.
Tip: This exception message is thrown in the JVM if 98% of the time is used for GC and the available heap size is less than 2%.
Tip: The Heap Size does not exceed 80% of the available physical memory, generally the-XMS and-XMX options are set to the same, and the-XMX value of-xmn is 1/4.
Workaround: Manually set the heap size
Modify Tomcat_home/bin/catalina.sh
Add the following line to the "echo" Using catalina_base: $CATALINA _base "":
Java_opts= "-server-xms800m-xmx800m-xx:maxnewsize=256m"

example, the following gives a reference to the parameter setting of the Java JVM in the 1G memory environment:

Java_opts= "-server-xms800m-xmx800m-xx:permsize=64m-xx:maxnewsize=256m-xx:maxpermsize=128m-djava.awt.headless= True "

A large Web project, the default allocated memory space with Tomcat cannot be started, and if not started in MyEclipse Tomcat can be set for Tomcat:

Add such a sentence in Tomcat_home\bin\catalina.bat:

Set java_opts=-xmx1024m-xms512m-xx:maxpermsize=256m

If you want to start in MyEclipse, the above modifications will not work, and can be set as follows:

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

Optional Java VM arguments added:-xmx1024m-xms512m-xx:maxpermsize=256m

The above is the repost, but I met the problem is: in MyEclipse start Tomcat, prompted "Ava.lang.OutOfMemoryError:Java heap space", the solution is:

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

Optional Java VM arguments added:-xmx1024m-xms512m-xx:maxpermsize=256m

It's very spiritual.

Problem description
Exception in thread "main" Java.lang.OutOfMemoryError:Java heap space

Solution [Go]

Always know you can set the JVM heap size and always write/debug Java programs with Eclipse. Always use the command line or console plus parameters to run the program. Symptom: Set-vmargs-xms500m-xmx1024m in Eclipse configuration file Eclipse.ini, run directly in eclipse Or debug some memory-consuming program still Java.lang.OutOfMemoryError:Java Heap space error, that is generally considered insufficient memory, Java virtual machine memory is not enough. Adding these parameters to the command line is effective and does not make an error. This illustrates a problem where these parameters do not work at all. Today needs to debug the program in eclipse, not to need to debug where the heap error, search the Internet a lot of places, got the final answer:
Select the class to be run, click on the menu ' Run->run ... ', select (x) =argument the VM Under the tab page arguments box
Enter-xmx800m, save run.
The original also needs to be set separately for each project, Khan ...

There are three possible causes of OutOfMemoryError.

First, this JVM has a real memory leak.

Causes this JVM heap to generate a bug when it is implemented internally. This is extremely unreliable. All JVMs are fully tested and, if anyone finds such a bug, it will definitely be the highest priority. So you can eliminate this possibility very carefully.

Second, there is not enough memory available for your application to run.

In this case, there are two possible scenarios, either increasing the size of the JVM heap available, or reducing the amount of memory required by your application. The JVM's-xmx parameters can be easily used to increase the available heap size of the JVM. If you set this parameter as large as possible (the free memory limit does not exceed the system physical memory, your application will be paged and paused), and still have the memory problems mentioned above, then you need to reduce the amount of memory that your application may use. Reducing application memory may be simple, and you may allow some collections to be too large, such as using many large buffers. Or it's overly complex, requiring you to re-implement some classes and even redesign your application.

Reader Jams Stauffer points out that some jvms, such as Sun's JVMs, also have a "Perm" parameter to handle JVM structures and class objects. If you are using a very large set of classes, it is possible to run outside of the "Perm" space, and then you need to increase the size of this space, for example, the Sun's JVM uses the-xx:permsize and-xx:maxpermsize options.

Third, the unintentional object reference is maintained.

You don't have an unmistakable release object so that your heap grows again, until you have no extra space.

Handling OutOfMemoryError:

Is it a bug inside the JVM? It's not likely. If so, this is the highest priority bug (why hasn't anyone found it yet, and you ran into it?) ）。

Not enough memory allocated to the actual running application?　Two options: Use the-XMX parameter to increase the maximum memory usage of the heap (or increase the perm space size using the-xx:maxpermsize parameter); Or use a smaller collection/buffer/tablespace/object ... to reduce the amount of memory needed, that is, you can resize the object, redesign and re-implement your application.

Unintentional object reference hold? Locate the source object that holds these unintentional references, change it, and release the objects. The article in the IBM developer community outlines such a common process. The process is to wait until the application arrives at a constant state-the most newly created object you will expect is a temporary object and can be collected by the garbage collector. This is often done after all initialization work for the application is complete.

Force garbage collection to get a heap of object snapshots.
Doing any work may be leading to unintentional object reference retention.
Force another garbage collection and get an object snapshot of the second heap.
Compare these two snapshots to see which objects are increasing in number from the first snapshot to the second snapshot. Because you force garbage collection before the snapshot, the remainder will be all objects referenced by the application, and a comparison of two snapshots will accurately identify the newly created objects that remain in the application.
Based on your understanding of the application, determine which objects are inadvertently holding object references in two snapshot comparisons.
Trace leading references to find which objects are referencing these unintentional persisted objects until you find the source object that is causing the problem

Summarize the workaround

When you start the virtual machine, add a parameter:-xms800m-xmx800m is good.
-xms <size>
Set JVM initialization heap memory size

-xmx <size>
To set the maximum heap memory size for the JVM

If it is an application, then: java-xms800m-xmx800m Your class name
If it is a Web server such as tomcat, add this parameter to the server's startup file.

Reprinted from http://blog.csdn.net/sunrainy10/article/details/6686197

Java Virtual memory settings