有没有知道显示JVM内存设置的JAVA命令.就是显示Xmx,-Xms 那几个参数是多少的命令.不是设置.是显示.查看哦.

[lgh2626]

有没有知道显示JVM内存设置的JAVA命令.就是显示XMS 那几个参数是多少的命令.不是设置.是显示.查看哦.

[qsrock]

以下是sun公司的性能优化白皮书中提到的几个例子：
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的使用率。

[tohmin]

set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=512m

最小内存设为128 最大512, 最下PERM内存视为 128 最大设为 512

Explaining java.lang.OutOfMemoryError: PermGen space
Thu, 05/19/2005 - 07:00.
Tags:

* java
* performance

Most 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 64MB

JDK 1.4.1_01 Initial Size Maximum Size
Client JVM 4MB 64MB
Server JVM 4MB 64MB

JDK 1.4.2 Initial Size Maximum Size
Client JVM 4MB 64MB
Server JVM 16MB 64MB

JDK 1.5.0 Initial Size Maximum Size
Client JVM 8MB 64MB
Server JVM 16MB 64MB

set 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.

[kingssman]

没看到怎么显示阿

[myairland]

接口为
com.sun.management.HotSpotDiagnosticMXBean

API文档
http://www.docjar.com/html/api/com/sun/management/HotSpotDiagnosticMXBean.java.html

sun给出的一个实现类（当然楼主可以自己实现上面的接口）
com.sun.management.HotSpotDiagnostic

API文档
http://www.docjar.com/docs/api/sun/management/HotSpotDiagnostic.html

这个类有个VMOption getVMOption(String name)方法，可以得到，具体方法请看API文档

不过这是 Java 的底层类库，是未文档化的。
sun 开头包，都是与平台相关的，不推荐使用。所以API文档是第三方的。

[lgh2626]

myairland 说的看来有显示办法...我去试试.先谢谢各位了.

[MT502]

java -X

[loveunittesting]

jdk/bin/jconsole这个程序应该可以看