jvm内存优化详解及调优

摘自网上参考加总结的，比较乱，一直没有时间整理，如今是忙中茫，先贴着后期整理吧：

样例：

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 文档重复占用内存的目的。

2、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

=============================================================================

参考大型电商的 jvm参数配置，经过研究网上大牛们的优化经验建议，对于咱们本身的环境:

例8G内存，4核的 jvm优化建议及参数说明：

 1. 通常把Xms与Xmx两个值设成同样是最优的作法，Xmx最好不要超过可用物理内存的80%。 建议值 ：-Xmx6000m -Xms6000m

 对于年轻代Xmn的大小：整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代通常固定大小为64m，因此增大年轻代后，将会减少年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。可是也有建议为Xmx的1/4。（此值待定）

 2. - XX:LargePageSizeInBytes：指定 Java heap 的分页页面大小

         建议：内存页的大小，不可设置过大，会影响Perm的大小，JVM堆的设置是指java程序运行过程当中JVM能够调配使用的内存空间的设置，JVM在启动的时候会自动设置Heap size的值，其初始空间一般为是物理内存的1/64。 建议值为128m.

 4.   -XX:+DisableExplicitGC : 禁止 java 程序中的 full gc，如 System.gc() 的调用.

         建议：禁用掉，防止程序在代码里误用了。对性能形成冲击。

进阶优化：

 5. -XX：UseParNewGC：指定在 New Generation 使用 parallel collector，是 UseParallelGC 的 gc 的升级版本，有更好的性能或者优势，能够和 CMS gc 一块儿使用。

    -XX：CMSParallelRemarkEnabled  在使用 UseParNewGC 的状况下，尽可能减小 mark 的时间  

 6. -XX：UseConcMarkSweepGC  指定在 Old Generation 使用 concurrent cmark sweep gc,gc thread 和 app thread 并行 ( 在 init-mark 和 remark 时 pause app thread)。app pause 时间较短，适合交互性强的系统，如 web server

 7. UseFastAccessorMethods  get,set 方法转成本地代码。

 8. UseCMSCompactAtFullCollection 在使用 concurrent gc 的状况下，防止 memory fragmention，对 live object 进行整理，使 memory 碎片减小。 建议增长.

 9. UseCMSInitiatingOccupancyOnly  仅仅使用手动定义初始化定义开始CMS收集，禁止hostspot自行触发CMS GC

      网上建议：查了不少文章，发现引发promotion failed错误的缘由是CMS来不及回收（CMS默认在年老代占到90%左右才会执行），

年老代又没有足够的空间供GC把一些活的对象从年轻代移到年老代，因此执行Full GC

-XX:CMSInitiatingOccupancyFraction=70  CMS堆上，使用70％后开始CMS收集，表示年老代占到约70%时就开始执行CMS，这样就不会出现Full GC了。 建议增长.

 11. UseCompressedOops 指针压缩，在64位HotSpot中使用32位指针，默认64位会比32位的内存使用多出1.5倍，启用CompressOops后，会压缩的对象：

     每一个Class的属性指针（静态成员变量）

     每一个对象的属性指针

     普通对象数组的每一个元素指针

     好比指向PermGen的Class对象指针，本地变量，堆栈元素，入参，返回值，NULL指针不会被压缩

建议增长.

 12. ReduceInitialCardMarks  避免java 6 中CMS的一个bug,致使 jvm crash。 该bug在Java6 update25中获得修复

建议增长.

我的经验理解也许不必定正确：增大年轻代大小后将会减小年老代大小，将其比例值调到差很少1：1参考值为好； 整个jvm堆内存大小Xmx分配：去除给系统及其它服务所需的内存值后的90%。Xmx和Xms设置同样便可。

假若系统硬件资源很少，由于内存分配的不足，回收的频率相对高了，tomcat所消耗CPU资源就多了，系统负载就上去了。 此时最简单的办法扩增CPU核数或内存。