摘自网上参考加总结的，比较乱，一直没有时间整理，现在是忙中茫，先贴着后期整理吧：
样例：
JAVA_OPTS="$JAVA_OPTS -Djava.awt.headless=true \
-server -Xmx2600m -Xms2600m -Xmn2000m \
-XX:SurvivorRatio=8 \
-XX:PermSize=256m \
-XX:MaxPermSize=256m \
-Xss128k \
-XX:MaxTenuringThreshold=7 \
-XX:ParallelGCThreads=8 \
-XX:GCTimeRatio=19 \
-Xnoclassgc \
-XX:+DisableExplicitGC \
-XX:+UseParNewGC \
-XX:+UseConcMarkSweepGC \
-XX:+CMSPermGenSweepingEnabled \
-XX:+UseCMSCompactAtFullCollection \
-XX:CMSFullGCsBeforeCompaction=0 \
-XX:CMSInitiatingOccupancyFraction=70 \
XX:+PrintClassHistogram \
-XX:+PrintGCDetails \
-XX:+PrintGCTimeStamps \
-XX:+PrintGCApplicationConcurrentTime \
-XX:+PrintGCApplicationStoppedTime \
-XX:+PrintTenuringDistribution \
-Xloggc:/home/saas/apache-tomcat-6.0.36/log/tomcat_gc.log \
-Doracle.jdbc.V8Compatible=true"
tomcat内存溢出总结
在生产环境中tomcat内存配置不好很容易出现内存溢出。造成内存原由是不一样的，当然处理方式也不一样。
这里根据平时遇到的情况和有关资料执行 一个总结。多见的一般会有下面三种情况：
1.OutOfMemoryError: Java heap space
2.OutOfMemoryError: PermGen space
3.OutOfMemoryError: unable to create new native thread.
对于前两种情况，在运用 本身没有内存泄露的情况下可以用配置 tomcat jvm参数来处理。（-Xms -Xmx -XX:PermSize -XX:Maxp ermSize）
最后一种可能须要调整操作系统和tomcat jvm参数同时调整才能达到目的。
第一种：是堆溢出。
在JVM中如果98％的时间是用于GC且可用的 Heap size 不足2％的时候将抛出此异常信息。
没有内存泄露的情况下，调整-Xms -Xmx参数可以处理。
-Xms:原始堆大小
-Xmx:最大堆大小
但堆的大小受下面三方面影响：
1.有关操作系统的数据模型（32-bt还是64-bit）限定；（32位系统下，一般限定在1.5G~2G；我在2003 server 系统下（物理内存：4G和6G，jdk：1.6）测试 1612M，64为操作系统对内存无限定。）
2.系统的可用虚拟内存限定；
3.系统的可用物理内存限定。
堆的大小可以运用 java -Xmx***M version 命令来测试。支持的话会出现jdk的版本号，不支持会报错。
-Xms -Xmx一般配置成一样比较好比如set JAVA_OPTS= -Xms1024m -Xmx1024m
第二种：长久保存区域溢出
PermGen space的全称是Permanent Generation space,是指内存的长久保存区域。这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域，它和和存放Instance的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space执行 清理，所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space不正确。这种不正确多见在web服务器对JSP执行 pre compile的时候。但目前的hibernate和spring项目中也很容易出现这样的疑问。http://www.javaeye.com/topic/80620?page=1 的帖子有讨论的这个疑问。可能是由于这些框架会动态class，而且jvm的gc是不会清理PemGen space的，导致内存溢出。
-XX:MaxpermSize 来处理疑问。
-XX:PermSize 长久保存区域原始大小
-XX:PermSize 长久保存区域原始最大值
这一般结合第一条运用，比如 set JAVA_OPTS= -Xms1024m -Xmx1024m -XX:PermSize=128M -XX:PermSize=256M
有一点须要留心：java -Xmx***M version 命令来测试的最大堆内存是 -Xmx与 -XX:PermSize的和 比如系统支持最大的jvm堆大小事1.5G，那 -Xmx1024m -XX:PermSize=768M 是不能运行的。
第三种：不能建立新的线程。
这种现象比较少见，也比较奇怪，主要是和jvm与系统内存的比例有关。
这种怪事是因为JVM已经被系统分配了大量的内存(比如1.5G)，并且它至少要占用可用内存的一半。有人发觉，在线程个数很多的情况下，你分配给JVM的内存越多，那么，上述不正确发生的可能性就越大。
产生这种现象的原由如下（从这个blog中了解到原由：http://hi.baidu.com/hexiong/blog/item/16dc9e518fb10c2542a75b3c.html）：
每一个32位的进程最多可以运用 2G的可用内存，因为另外2G被操作系统保留。这里假设运用 1.5G给JVM，那么还余下500M 可用内存。这500M内存中的一部分必须用于系统dll的加载，那么真实剩下的也许只有400M，现在关键的地点出现了：当你运用 Java建立一个线程，在JVM的内存里也会建立一个Thread对象，但是同时也会在操作系统里建立一个真实的物理线程(参考JVM规范)，操作系统会在余下的400兆内存里建立这个物理线程，而不是在JVM的1500M的内存堆里建立。在jdk1.4里头，默认的栈大小是256KB，但是在jdk1.5里头，默认的栈大小为 1M每线程，因此，在余下400M的可用内存里边我们最多也只能建立 400个可用线程。
这样结论就出来了，要想建立更多的线程，你必须减少分配给JVM的最大内存。还有一种做法是让JVM宿主在你的JNI代码里边。
给出一个有关能够建立线程的最大个数的估算公式：
(Maxp rocessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads
对于jdk1.5而言，假设操作系统保留120M内存：
1.5GB JVM: (2GB-1.5Gb-120MB)/(1MB) = ~380 threads
1.0GB JVM: (2GB-1.0Gb-120MB)/(1MB) = ~880 threads
在2000/xp /2003的boot.ini里头有一个启动选项，好像是：/PAE /3G ，可以让用户进程最大内存扩充至3G，这时操作系统只能占用最多1G的虚存。那样应该可以让JVM建立更多的线程。
因此这种情况须要结合操作系统执行 有关调整。
因此：我们须要结合不同情况对tomcat内存分配执行 不同的诊断才能从根本上处理疑问
一些优化参数说明：
LargePageSizeInBytes 指定 Java heap 的分页页面大小， 内存页的大小， 不可设置过大， 会影响Perm的大小
DisableExplicitGC 禁止 java 程序中的 full gc，如 System.gc() 的调用. 最好加上么，防止程序在代码里误用了。对性能造成冲击
UseParNewGC 指定在 New Generation 使用 parallel collector，是 UseParallelGC 的 gc 的升级版本，有更好的性能或者优点，可以和 CMS gc 一起使用。
CMSParallelRemarkEnabled 在使用 UseParNewGC 的情况下，尽量减少 mark 的时间
UseConcMarkSweepGC 指定在 Old Generation 使用 concurrent cmark sweep gc,gc thread 和 app thread 并行 ( 在 init-mark 和 remark 时 pause app thread)。app pause 时间较短，适合交互性强的系统，如 web server。
UseCMSCompactAtFullCollection 在使用 concurrent gc 的情况下，防止 memory fragmention，对 live object 进行整理，使 memory 碎片减少。
UseFastAccessorMethods get,set 方法转成本地代码。
UseCMSInitiatingOccupancyOnly 指示只有在 old generation 在使用了初始化的比例后 concurrent collector 启动收集
-XX:+UseCMSInitiatingOccupancyOnly 仅仅使用手动定义初始化定义开始CMS收集，禁止hostspot自行触发CMS GC
-XX:CMSInitiatingOccupancyFraction=70 CMS堆上， 使用70％后开始CMS收集
相比之下，还是并发回收比较好，性能比较高，只要能解决ParNewGC（并行回收年轻代）时的promotion failed错误就一切好办了，
查了很多文章，发现引起promotion failed错误的原因是CMS来不及回收（CMS默认在年老代占到90%左右才会执行），
年老代又没有足够的空间供GC把一些活的对象从年轻代移到年老代，所以执行Full GC。
CMSInitiatingOccupancyFraction=70表示年老代占到约70%时就开始执行CMS，这样就不会出现Full GC了。。
CMSInitiatingOccupancyFraction，这个参数设置有很大技巧，基本上满足(Xmx-Xmn)*(100- CMSInitiatingOccupancyFraction)/100>=Xmn就不会出现promotion failed。
假如应用中Xmx是6000，Xmn是512，那么Xmx-Xmn是5488兆，也就是年老代有5488 兆，CMSInitiatingOccupancyFraction=90说明年老代到90%满的时候开始执行对年老代的并发垃圾回收（CMS），这时还剩10%的空间是5488*10%=548兆，所以即使Xmn（也就是年轻代共512兆）里所有对象都搬到年老代里，548兆的空间也足够了，所以只要满 足上面的公式，就不会出现垃圾回收时的promotion failed；
因此这个参数的设置必须与Xmn关联在一起。
二.调整 jvm参数
A：JVM启动参数共分为三类：
其一是标准参数（-），所有的JVM实现都必须实现这些参数的功能，而且向后兼容；
其二是非标准参数（-X），指的是JVM底层的一些配置参数，这些参数在一般开发中默认即可，不需要任何配置。但是在生产环境中，并不保证所有jvm实现都满足，所以为了提高性能，往往需要调整这些参数，以求系统达到最佳性能。另外这些参数不保证向后兼容，也即是说“如有变更，恕不在后续版本的JDK通知”（这是官网上的原话）；
其三是非Stable参数（-XX），这类参数在jvm中是不稳定的，不适合日常使用的，后续也是可能会在没有通知的情况下就直接取消了，需要慎重使用。
B：而JVM 内存又可分为三个主要的域 ：
新域、旧域以及永久域。JVM生成的所有新对象放在新域中。一旦对象经历了一定数量的垃圾收集循环后，便进入旧域。而在永久域中是用来存储JVM自己的反射对象的，如class和method对象，而且GC(GarbageCollection)不会在主程序运行期对永久域进行清理。其中新域和旧域属于堆，永久域是一个独立域并且不认为是堆的一部分。
C：各主要参数的作用如下 ：
====================
1.堆设置
-Xms：设置jvm内存的初始大小
-Xmx：设置jvm内存的最大值
-Xmn：设置新域的大小（这个似乎只对 jdk1.4来说是有效的，后来就废弃了）；年轻代大小
整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。
此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8
-Xss：设置每个线程的堆栈大小(也就是说,在相同物理内存下，减小这个值能生成更多的线程)
-XX：NewRatio :设置新域与旧域之比，如-XX：NewRatio = 4就表示新域与旧域之比为1：4
设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5
-XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。
设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6
-XX:NewSize：设置新域的初始值
-XX:MaxNewSize ：设置新域的最大值
-XX:PermSize：设置永久域的初始值
-XX:MaxPermSize：设置永久域的最大值
-XX:SurvivorRatio=n:设置新域中Eden区与两个Survivor区的比值。（Eden区主要是用来存放新生的对象，而两个 Survivor区则用来存放每次垃圾回收后存活下来的对象）
-XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。
D：常见的错误 ：
java.lang.OutOfMemoryError相信很多开发人员都用到过，这个主要就是JVM参数没有配好引起的，但是这种错误又分两种：java.lang.OutOfMemoryError:Java heap space和java.lang.OutOfMemoryError: PermGenspace(Permanent Generation space永久保存区域)，其中前者是有关堆内存的内存溢出，可以同过配置-Xms和-Xmx参数来设置，而后者是有关永久域的内存溢出，可以通过配置 -XX:MaxPermSize来设置。
下面是个例子,请根据实际情况进行修改,修改run.conf文件中的如下内容：
JAVA_OPTS="-Xms256m-Xmx2048m -XX:NewSize=256m -XX:MaxNewSize=512m -XX:PermSize=128m-XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled-XX:+CMSClassUnloadingEnabled -Djboss.platform.mbeanserver"
说说为什么会内存益出：
PermGen space这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域，它和和存放Instance的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误,这种错误常见在web服务器对JSP进行pre compile的时候。
如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。
解决方法： 手动设置MaxPermSize大小修改TOMCAT_HOME/bin/catalina.sh 在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行： JAVA_OPTS="-server -XX:PermSize=64M -XX:MaxPermSize=128m
建议：将相同的第三方jar文件移置到tomcat/shared/lib目录下，这样可以达到减少jar 文档重复占用内存的目的。
二、java.lang.OutOfMemoryError: Java heap space Heap size 设置 JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.
JVM在启动的时候会自动设置Heap size的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。
可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。
提示：在JVM中如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。
提示：Heap Size 最大不要超过可用物理内存的80％，
一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值
===========================================================================================
优化进价篇：
===========================================================================================
2.收集器设置
吞吐量优先的并行收集器：
并行收集器主要以到达一定的吞吐量为目标，适用于科学技术和后台处理等
典型配置：
-XX:+UseParallelGC：选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下，年轻代使用并发收集，而年老代仍旧使用串行收集。
-XX:ParallelGCThreads=20：配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。
-XX:+UseParallelOldGC：配置年老代垃圾收集方式为并行收集。JDK6.0支持对年老代并行收集。
-XX:MaxGCPauseMillis=100:设置每次年轻代垃圾回收的最长时间，如果无法满足此时间，JVM会自动调整年轻代大小，以满足此值。
-XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会自动选择年轻代区大小和相应的Survivor区比例，以达到目标系统规定的最低相应时间或者收集频率等，此值建议使用并行收集器时，一直打开。
响应时间优先的并发收集器：
并发收集器主要是保证系统的响应时间，减少垃圾收集时的停顿时间。适用于应用服务器、电信领域等。
典型配置：
-XX:+UseConcMarkSweepGC：设置年老代为并发收集。测试中配置这个以后，-XX:NewRatio=4的配置失效了，原因不明。所以，此时年轻代大小最好用-Xmn设置。
-XX:+UseParNewGC:设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此值。
-XX:CMSFullGCsBeforeCompaction：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。
-XX:+UseCMSCompactAtFullCollection：打开对年老代的压缩。可能会影响性能，但是可以消除碎片
3.垃圾回收统计信息
■-XX:+PrintGC
■-XX:+PrintGCDetails
■-XX:+PrintGCTimeStamps
■-Xloggc:filename
=============================================================================
对于年轻代Xmn的大小：整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。但是也有建议为Xmx的1/4。（此值待定）
个人经验理解也许不一定正确：增大年轻代大小后将会减少年老代大小，将其比例值调到差不多1：1参考值为好； 整个jvm堆内存大小Xmx分配：去除给系统及其它服务所需的内存值后的90%。Xmx和Xms设置一样即可。
倘若系统硬件资源不多，因为内存分配的不足，回收的频率相对高了，tomcat所消耗CPU资源就多了，系统负载就上去了。 此时最简单的办法扩增CPU核数或内存。