首先各个版本的JDK的ＪＶＭ的参数是不一样的，我在刚开始就吃了这个亏，基本上１.４以后的ＪＶＭ参数差不多，各位在查ＧＣ参数时注意：

下面一个网址可以看一下，如果不想去看ＪＤＫ文档的http://blog.csdn.net/zsuguangh/article/details/6429667

我在输出日志的时候，一个朋友提供了两种途径：

上面两种我还没来的及实验，料想应该都差不多吧，而我用的是下面的方法：

将参数设在：echo JAVA Memory arguments: %MEM_ARGS%之前这样你就可以看到你的设置在管理服务器启动时的命令界面里了

下面摘抄的一段关于基本参数的意思：

-Xms 设定一开始的Heap Size(堆大小)
-Xmx 设定Heap Size的最大值
-XX:NewSize 调整JVM的Young Generation 的size大小
-XX:MaxNewSize 调整JVM的Young Generation 的size最大值
-Xmn  Young Generation的size，NewSize 和 MaxNewSize设定为一样。
-XX:NewRatio 控制Young generation的比例，如-XX:NewRatio=3表示Young generation与Old generation的比例为1:3,即Young generation佔1/4,Old generation佔3/4。
如果将Heap Size设的越大，GC的週期就会拉长，而且每次GC的时间也会越长。

-XX:PermSize 这一部分是用於存放Class和Meta的讯息，Class在被 Load的时候被放入PermGen space区域，它和和存放Instance的Heap区域不同，GC(Garbage Collection)不会在主程式运行期间对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话，就很可能出现PermGen space错误。这种错误常见在web伺服器对JSP进行pre compile的时候。
整个记忆体配置会像这样

-XX:+DisableExplicitGC 加了这个参数会停止掉WLS或是程式内直接呼叫GC，减少不必要的GC，将GC交由JVM去执行。
Garbage Collection描述：
Garbage Collection分多种等级，0级就是全部的垃圾回收(Full GC)，会回收Old generation中的垃圾；1级或以上为部分垃圾回收，只会回收Young中的垃圾，会发生OutOfMemory通常是產生於Old generation或Perm段垃圾回收后，仍然没有记忆体空间来存放新的Java 物件的情况。
当一个URL被访问时，记忆体的配置过程如下：
A. JVM会试图为Java的相关对象在Eden中初始化一块记忆体空间
B. 当Eden空间足够时，记忆体配置结束。否则到下一步
C. JVM会试图释放在Eden中所有不活跃的对象（这是属於1或更高级的垃圾回收）；释放后若Eden空间仍然不足以放入新对象，则会试图将部分Eden中活跃的对象放入Survivor区/OLD区
D. Survivor区被用来作为Eden及OLD的中间交换区域，当OLD区空间足够，Survivor区的对象会被移到Old区，否则被保留在Survivor区
E. 当OLD区空间不足时，JVM会在OLD区进行完全的垃圾收集（0级）
F. 完全垃圾收集后，若Survivor及OLD区仍然无法存放从Eden复製过来的部分对象，就会导致JVM无法在Eden区为新的对象配置出记忆体区块，產生"out of memory的错误"
但千万不要完全按照上面的，版本不同会有一些不同的地方，建议最好查ＪＤＫ文档

并且对于日志分析工具gcviewer-1.32请注意也有限制并不是每个版本的都可以分析，下面是它支持的格式。

下面是我的分析结果 可惜我看不懂：

主要是归为两大系列：源自Sun的按代的做法，和IBM的按簇的做法。。。