set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=512m最小内存设为128 最大512, 最下PERM内存视为 128 最大设为 512Explaining java.lang.OutOfMemoryError: PermGen space Thu, 05/19/2005 - 07:00. Tags: * java * performanceMost probably, a lot of Java developers have seen OutOfMemory error one time or other. However these errors come in different forms and shapes. The more common is: "Exception in thread "main" java.lang.OutOfMemoryError: Java heap space" and indicates that the Heap utilization has exceeded the value set by -Xmx. This is not the only error message, of this type, however.One more interesting flavor of the same error message, less common but hence even more troublesome is: "java.lang.OutOfMemoryError: PermGen space". Most of the memory profiler tools are unable to detect this problem, so it is even more troublesome and therefor - interesting.To understand this error message and fix it, we have to remember that, for optimized, more efficient garbage-collecting Java Heap is managed in generations - memory segments holding objects of different ages.Garbage collection algorithms in each generation are different. Objects are allocated in a generation for younger objects - the Young Generation, and because of infant mortality most objects die there. When the young generation fills up it causes a Minor Collection. Assuming high infant mortality, minor collections are garbage-collected frequently.Some surviving objects are moved to a Tenured Generation. When the Tenured Generation needs to be collected there is a Major Collection that is often much slower because it involves all live objects. Each generation contains variables of different length of life and different GC policies are applied to them.There is a third generation too - Permanent Generation. The permanent generation is special because it holds meta-data describing user classes (classes that are not part of the Java language). Examples of such meta-data are objects describing classes and methods and they are stored in the Permanent Generation.Applications with large code-base can quickly fill up this segment of the heap which will cause java.lang.OutOfMemoryError: PermGen no matter how high your -Xmx and how much memory you have on the machine.Sun JVMs allow you to resize the different generations of the heap, including the permanent generation. On a Sun JVM (1.3.1 and above) you can configure the initial permanent generation size and the maximum permanent generation size.To set a new initial size on Sun JVM use the -XX:PermSize=64m option when starting the virtual machine. To set the maximum permanent generation size use -XX:MaxPermSize=128m option. If you set the initial size and maximum size to equal values you may be able to avoid some full garbage collections that may occur if/when the permanent generation needs to be resized. The default values differ from among different versions but for Sun JVMs upper limit is typically 64MB.Some of the default values for Sun JVMs are listed below. Some of the default values for Sun JVMs are listed below. JDK 1.3.1_06 Initial Size Maximum Size Client JVM 1MB 32MB Server JVM 1MB 64MBJDK 1.4.1_01 Initial Size Maximum Size Client JVM 4MB 64MB Server JVM 4MB 64MBJDK 1.4.2 Initial Size Maximum Size Client JVM 4MB 64MB Server JVM 16MB 64MBJDK 1.5.0 Initial Size Maximum Size Client JVM 8MB 64MB Server JVM 16MB 64MBset JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m -XX:PermSize=64M -XX:MaxPermSize=128M Following is a JSP code you can use to monitor memory utilization in different generations (including PermGen):<%@ page import="java.lang.management.*" %> <%@ page import="java.util.*" %> <html> <head> <title>JVM Memory Monitor</title> </head><% Iterator iter = ManagementFactory.getMemoryPoolMXBeans().iterator(); while (iter.hasNext()) { MemoryPoolMXBean item = (MemoryPoolMXBean) iter.next(); %><table border="0" width="100%"> <tr><td colspan="2" align="center"><h3>Memory MXBean</h3></td></tr> <tr><td width="200">Heap Memory Usage</td><td><%= ManagementFactory.getMemoryMXBean().getHeapMemoryUsage() %></td></tr> <tr><td>Non-Heap Memory Usage</td><td><%= ManagementFactory.getMemoryMXBean().getNonHeapMemoryUsage() %></td></tr></body> <tr><td colspan="2"> </td></tr> <tr><td colspan="2" align="center"><h3>Memory Pool MXBeans</h3></td></tr> <% Iterator iter = ManagementFactory.getMemoryPoolMXBeans().iterator(); while (iter.hasNext()) { MemoryPoolMXBean item = (MemoryPoolMXBean) iter.next(); %> <tr><td colspan="2"> <table border="0" width="100%" style="border: 1px #98AAB1 solid;"> <tr><td colspan="2" align="center"><b><%= item.getName() %></b></td></tr> <tr><td width="200">Type</td><td><%= item.getType() %></td></tr> <tr><td>Usage</td><td><%= item.getUsage() %></td></tr> <tr><td>Peak Usage</td><td><%= item.getPeakUsage() %></td></tr> <tr><td>Collection Usage</td><td><%= item.getCollectionUsage() %></td></tr> </table> </td></tr> <tr><td colspan="2"> </td></tr> <% } %></table>As of JBoss v3.2.8/4.0.2, the ServerInfo MBean registered under the name jboss.system:type=ServerInfo has been enhanced with a new operation listMemoryPools(boolean fancy) that presents information about the memory pools managed by the JVM.
1．对于吞吐量的调优。机器配置：4G的内存，32个线程并发能力。
java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
-Xmx3800m -Xms3800m 配置了最大Java Heap来充分利用系统内存。
-Xmn2g 创建足够大的青年代（可以并行被回收）充分利用系统内存，防止将短期对象复制到老年代。
-Xss128 减少默认最大的线程栈大小，提供更多的处理虚拟内存地址空间被进程使用。
-XX:+UseParallelGC 采用并行垃圾收集器对年青代的内存进行收集，提高效率。
-XX:ParallelGCThreads=20 减少垃圾收集线程，默认是和服务器可支持的线程最大并发数相同，往往不需要配置到最大值。
2．尝试采用对老年代并行收集
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC
-Xmx3550m -Xms3550m 内存分配被减小，因为ParallelOldGC会增加对于Native Heap的需求，因此需要减小Java Heap来满足需求。
-XX:+UseParallelOldGC 采用对于老年代并发收集的策略，可以提高收集效率。
3．提高吞吐量，减少应用停顿时间
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=31
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC 选择了并发标记交换收集器，它可以并发执行收集操作，降低应用停止时间，同时它也是并行处理模式，可以有效地利用多处理器的系统的多进程处理。
-XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=31 表示在青年代中Eden和Survivor比例，设置增加了Survivor的大小，越大的survivor空间可以允许短期对象尽量在年青代消亡。
-XX:TargetSurvivorRatio=90 允许90%的空间被占用，超过默认的50%，提高对于survivor的使用率。
Thu, 05/19/2005 - 07:00.
Tags: * java
* performanceMost probably, a lot of Java developers have seen OutOfMemory
error one time or other. However these errors come in different forms
and shapes. The more common is: "Exception in thread "main"
java.lang.OutOfMemoryError: Java heap space" and indicates that the
Heap utilization has exceeded the value set by -Xmx. This is not the
only error message, of this type, however.One more interesting
flavor of the same error message, less common but hence even more
troublesome is: "java.lang.OutOfMemoryError: PermGen space". Most of
the memory profiler tools are unable to detect this problem, so it is
even more troublesome and therefor - interesting.To
understand this error message and fix it, we have to remember that, for
optimized, more efficient garbage-collecting Java Heap is managed in
generations - memory segments holding objects of different ages.Garbage
collection algorithms in each generation are different. Objects are
allocated in a generation for younger objects - the Young Generation,
and because of infant mortality most objects die there. When the young
generation fills up it causes a Minor Collection. Assuming high infant
mortality, minor collections are garbage-collected frequently.Some
surviving objects are moved to a Tenured Generation. When the Tenured
Generation needs to be collected there is a Major Collection that is
often much slower because it involves all live objects. Each generation
contains variables of different length of life and different GC
policies are applied to them.There is a third generation too -
Permanent Generation. The permanent generation is special because it
holds meta-data describing user classes (classes that are not part of
the Java language). Examples of such meta-data are objects describing
classes and methods and they are stored in the Permanent Generation.Applications
with large code-base can quickly fill up this segment of the heap which
will cause java.lang.OutOfMemoryError: PermGen no matter how high your
-Xmx and how much memory you have on the machine.Sun JVMs allow
you to resize the different generations of the heap, including the
permanent generation. On a Sun JVM (1.3.1 and above) you can configure
the initial permanent generation size and the maximum permanent
generation size.To set a new initial size on Sun JVM use the -XX:PermSize=64m option when starting the virtual machine. To set the maximum permanent generation size use -XX:MaxPermSize=128m
option. If you set the initial size and maximum size to equal values
you may be able to avoid some full garbage collections that may occur
if/when the permanent generation needs to be resized. The default
values differ from among different versions but for Sun JVMs upper
limit is typically 64MB.Some of the default values for Sun JVMs are listed below.
Some of the default values for Sun JVMs are listed below.
JDK 1.3.1_06 Initial Size Maximum Size
Client JVM 1MB 32MB
Server JVM 1MB 64MBJDK 1.4.1_01 Initial Size Maximum Size
Client JVM 4MB 64MB
Server JVM 4MB 64MBJDK 1.4.2 Initial Size Maximum Size
Client JVM 4MB 64MB
Server JVM 16MB 64MBJDK 1.5.0 Initial Size Maximum Size
Client JVM 8MB 64MB
Server JVM 16MB 64MBset JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m -XX:PermSize=64M -XX:MaxPermSize=128M
Following is a JSP code you can use to monitor memory utilization in different generations (including PermGen):<%@ page import="java.lang.management.*" %>
<%@ page import="java.util.*" %>
<html>
<head>
<title>JVM Memory Monitor</title>
</head><%
Iterator iter = ManagementFactory.getMemoryPoolMXBeans().iterator();
while (iter.hasNext()) {
MemoryPoolMXBean item = (MemoryPoolMXBean) iter.next();
%><table border="0" width="100%">
<tr><td colspan="2" align="center"><h3>Memory MXBean</h3></td></tr>
<tr><td
width="200">Heap Memory Usage</td><td><%=
ManagementFactory.getMemoryMXBean().getHeapMemoryUsage()
%></td></tr>
<tr><td>Non-Heap Memory
Usage</td><td><%=
ManagementFactory.getMemoryMXBean().getNonHeapMemoryUsage()
%></td></tr></body>
<tr><td colspan="2"> </td></tr>
<tr><td colspan="2" align="center"><h3>Memory Pool MXBeans</h3></td></tr>
<%
Iterator iter = ManagementFactory.getMemoryPoolMXBeans().iterator();
while (iter.hasNext()) {
MemoryPoolMXBean item = (MemoryPoolMXBean) iter.next();
%>
<tr><td colspan="2">
<table border="0" width="100%" style="border: 1px #98AAB1 solid;">
<tr><td colspan="2" align="center"><b><%= item.getName() %></b></td></tr>
<tr><td width="200">Type</td><td><%= item.getType() %></td></tr>
<tr><td>Usage</td><td><%= item.getUsage() %></td></tr>
<tr><td>Peak Usage</td><td><%= item.getPeakUsage() %></td></tr>
<tr><td>Collection Usage</td><td><%= item.getCollectionUsage() %></td></tr>
</table>
</td></tr>
<tr><td colspan="2"> </td></tr>
<%
}
%></table>As of JBoss v3.2.8/4.0.2, the ServerInfo MBean registered under the name
jboss.system:type=ServerInfo has been enhanced with a new operation
listMemoryPools(boolean fancy) that presents information about the
memory pools managed by the JVM.
com.sun.management.HotSpotDiagnosticMXBeanAPI文档
http://www.docjar.com/html/api/com/sun/management/HotSpotDiagnosticMXBean.java.htmlsun给出的一个实现类（当然楼主可以自己实现上面的接口）
com.sun.management.HotSpotDiagnosticAPI文档
http://www.docjar.com/docs/api/sun/management/HotSpotDiagnostic.html这个类有个VMOption getVMOption(String name)方法，可以得到，具体方法请看API文档不过这是 Java 的底层类库，是未文档化的。
sun 开头包，都是与平台相关的，不推荐使用。所以API文档是第三方的。