JVM参数对J2EE性能优化的影响

怼烎@ 2021-09-10 06:32 467阅读 0赞

一切J2EE应用都是基于JVM的，那么对于JVM的设置和监控，成为J2EE应用程序性能分析和性能优化的必然手段。今天Sincky和大家交流该话题。这里以Tomcat环境为例，其它WEB服务器如Jboss、Weblogic、Websphere完全一致。

【认识JVM】

首先我们来看一张图，这是目前JDK1.6版本自带的JVM性能监控工具VisualVM的一个插件VisualGC的显示情况。让我们先来了解JVM的内存堆Heap管理模式，要调整JVM，自然要知道它的内部结构和运作，此乃“知己知彼，百战不殆”！

[![128d719ff9cg215.jpg][]][128d719ff9cg215.jpg 1]JVM的Heap包括三部分，分别是Permanent Generation（简称PermGen）、New Generation和Tenured Generation（又叫Old ）。

PermGen是JVM自用的区域，是内存的永久保存区，用于存放反射代理和Class，Class在被装载时就会被放到PermGen中；所以如果WEB服务器里应用的Class相当多时，就可以考虑将这一块区域放大一些。

New和Old是Java应用的Heap区，用来存放类的实例Instance的；其中New Generation的目标就是尽可能快速的收集掉那些生命周期短的对象；New Generation又分为Eden Space，From Space和To Space三块，Eden Space用于存放新创建的对象，From区和To区都是救助空间Survivor Space（图中的S0和S1）；当Eden区满时，JVM执行垃圾回收GC（Garbage Collection），垃圾收集器暂停应用程序，并会将Eden Space还存活的对象复制到当前的From救助空间，一旦当前的From救助空间充满，此区的存活对象将被复制到另外一个To区，当To区也满了的时候，从From区复制过来并且依然存活的对象复制到Old区，从而From和To救助空间互换角色，维持活动的对象将在救助空间不断复制，直到最终转入Old域。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时存在从Eden复制过来对象，和从前一个Survivor复制过来的对象，而且，Survivor区总有一个是空的。同时，根据程序需要，Survivor区是可以配置为多个的(多于两个)，这样可以增加对象在年轻代中的存在时间，减少被放到年老代的可能。每一次垃圾回收后，Eden Space都会被清空。

Old区用于存放长寿的对象，在New区中经历了N次垃圾回收后仍然存活的对象，就会被放到Old区中；如那些与业务信息相关的对象，包括Http请求中的Session对象、线程、Socket连接，这类对象跟业务直接挂钩，因此生命周期比较长。当任何一个空间不够用时，都会促使JVM执行垃圾回收，而垃圾回收也需要消耗一定的时间，从而造成应用程序卡住；因此，合理的设置各个区的大小，可以进行快速GC即Mimor GC，避免频繁的Full GC。

所谓Minor GC，一般情况下，当新对象生成，并且在Eden申请空间失败时，就会触发Minor GC，对Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区，然后整理Survivor的两个区。这种方式的GC是对New区的Eden区进行，不会影响到Old区。因为大部分对象都是从Eden区开始的，同时Eden区不会分配的很大，所以Eden区的Minor GC会频繁进行。因而，一般在这里需要使用速度快、效率高的算法，使Eden去能尽快空闲出来。

而Full GC要对整个Heap区进行回收，包括New、Old和PermGen，所以比Minor GC要慢，因此应该尽可能减少Full GC的次数。在对JVM性能调优的过程中，很大一部分工作就是对于Full GC的调节。有如下原因可能导致Full GC：  
·Tenured区被写满  
·PermGen区被写满  
·System.gc()被显示调用  
·上一次GC之后Heap的各域分配策略动态变化

【JVM参数实例一】JVM PermGen溢出：

> java.lang.OutOfMemoryError PermGen space

由于GC不会在主程序运行期对PermGen进行清理，所以如果你的应用中有很多CLASS的话，就很可能出现PermGen space错误，这种错误常见在WEB服务器对JSP进行预编译的时候发生。如果你的WEB APP下都用了大量的第三方JAR包, 其大小超过了JVM默认的大小(4M)那么就会产生此错误信息了。

解决方法： 手动设置MaxPermSize大小。修改TOMCAT\_HOME/bin/catalina.bat，在echo Using CATALINA\_base:%CATALINA\_base%上面加入以下行：

> JAVA\_OPTS=%JAVA\_OPTS% -server -XX:PermSize=64M -XX:MaxPermSize=128m

建议：将相同的第三方jar文件移置到tomcat/shared/lib目录下，这样可以达到减少jar 文档重复占用内存的目的。

【JVM参数实例二】JVM Heap溢出：

> java.lang.OutOfMemoryError: Java heap space

JVM Heap堆的设置是指java程序运行过程中JVM可以调配使用的内存空间。JVM在启动的时候会自动设置Heap size的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。提示：在JVM中如果98％的时间是用于GC且可用的Heap大小不足2％的时候将抛出此异常信息。Heap最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。   
解决方法：手动设置Heap size，例如：

> JAVA\_OPTS=%JAVA\_OPTS% -server -Xms800m -Xmx800m

但是有的时候可能这样的设置还会不生效，例如当JVM加载大量Class类时，永久域中的对象急剧增加，从而

使JVM不断调整永久域大小。为了避免自动调整，可以使用前面的参数结合设置，如：

> JAVA\_OPTS=%JAVA\_OPTS% -server -Xms800m -Xmx800m -XX:PermSize=64m -XX:MaxPermSize=128m

基于Sun 的Java的垃圾回收机制，允许分隔内存池以包含不同时效的对象，垃圾回收循环根据时效收集与其他对象彼此独立的对象。使用其他参数，您可以单独设置内存池的大小。为了实现更好的性能，可以对包含短期存活对象的池的大小进行设置，以使该池中的对象的存活时间不会超过一个垃圾回收循环。新生成的池的大小由 NewSize和MaxNewSize参数确定。如：

> JAVA\_OPTS=%JAVA\_OPTS% -server -Xms800m -Xmx800m -XX:PermSize=64m -XX:MaxPermSize=128m -XX:NewSize=8m -XX:MaxNewSize=16m

【JVM参数实例三】垃圾回收时promotion failed:

这个问题一般由两种原因引起，第一个原因是Survivor空间不够，里面的对象还不应该被移动到Old区，但New区又有很多对象需要放入Survivor；第二个原因是Old区没有足够的空间接纳来自New区的对象；这两种情况都会转向Full GC，造成系统卡住时间较长。第一个原因可以通过去掉救助空间解决，设置-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0即可，第二个原因可以设置CMSInitiatingOccupancyFraction为某个值（假设70），这样Old区的70%时就开始执行CMS，Old区有足够的空间接纳来自New的对象。但是不管怎样，PermGen还是会逐渐变满，所以隔三差五重起java服务器是必要的。需要注意的是，Old区用的是并发回收，可以设置New区小一点，Old区大些，可以减少系统的卡住。

解决方法：

> $JAVA\_ARGS .= " -Dresin.home=$SERVER\_ROOT -server -Xms6000M -Xmx6000M -Xmn500M -XX:PermSize=500M -XX:MaxPermSize=500M -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0 -Xnoclassgc -XX:+DisableExplicitGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:-CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=90 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log"

\-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0 就是去掉了救助空间  
\-Xnoclassgc 禁用类垃圾回收，性能会高一点  
\-XX:+DisableExplicitGC 禁止System.gc()，免得程序员误调用gc方法影响性能  
\-XX:+UseParNewGC 对New采用多线程并行回收，这样收得快  
带CMS参数的都是和并发回收相关的:  
CMSInitiatingOccupancyFraction，这个参数设置有很大技巧，基本上满足(Xmx-Xmn)\*(100-CMSInitiatingOccupancyFraction)/100>=Xmn 就不会出现promotion failed。在这里Xmx是6000，Xmn是500，那么Xmx-Xmn是5500m，也就是Old有5500m，CMSInitiatingOccupancyFraction=90说明Old到90%满的时候开始执行对Old区的并发垃圾回收（CMS），这时还剩10%的空间是5500\*10%=550m，所以即使Xmn（也就是New共500m）里所有对象都搬到Old里，550兆的空间也足够了，所以只要满足上面的公式，就不会出现垃圾回收时的promotion failed。  
SoftRefLRUPolicyMSPerMB这个参数是softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap。

但是，这种设置方法因为没有用到Survivor，所以Old区容易满，CMS执行会比较频繁。建议还是用Survivor并把加大，这样也不会有promotion failed错误。配置上32位和64位不一样，64位系统只要配置MaxTenuringThreshold参数，CMS还是有暂停。为了解决暂停问题和promotion failed问题，最后我设置-XX:SurvivorRatio=1 ，并把MaxTenuringThreshold去掉，这样即没有暂停又不会有promotoin failed，而且更重要的是，Old区和PermGen上升非常慢（因为好多对象到不了年老代就被回收了），所以CMS执行频率非常低，好几个小时才执行一次，这样，服务器都不用重启了。下面是64位的配置，系统8G内存。

> \-Xmx4000M -Xms4000M -Xmn600M -XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log

【JVM启动参数介绍】

\-Xmn －Eden Generation的Heap大小，一般设置为Xmx的1/3或1/4

\-Xmx －设置JVM Heap大小最大值，这里的heap = New Generation + Old Generation，但不包括PermGen

\-Xms －设置JVM Heap大小初始值

\-XX:NewRatio －New/Old的大小比率

\-XX:NewSize －New Generation Heap的大小

\-XX:MaxNewSize －可以通过NewRatio和-Xmx计算得到

\-XX:SurvivorRatio －Eden/Survivor Space大小比率

\-XX:PermSize －PermGen的初始值

\-XX:MaxPermSize －PermGen最大值

\-Xss： －设置每个线程的Stack大小

\-XX:+UseParNewGC －表示多CPU下缩短Minor GC的时间

\-XX:+UseParallelGC －设置后可以使用并行清除收集器【多CPU】

\-XX:+ParallelGCThreads －可用来增加并行度【多CPU】

\-XX:+AggressiveOpts －是否激活最近的试验性性能调整

\-XX:\-Xnoclassgc －是否允许类垃圾收集，默认设置是允许类 GC

\-XX:+UseLargePages －是否支持大页面堆

\-XX:+UseFastAccessorMethods －在指定了这个参数后，JDK会将所有的get/set方法都转为本地代码

\-XX:+UseConcMarkSweepGC －缩短major收集的时间，此选项在Heap比较大而且Full GC时间较长的情况下使用更合适

另外，JVM的一些参数可以输出有效的日志文件：

\-verbose:gc －输出一些gc信息

\-XX:+PrintGCDetails －输出gc详细信息

\-XX:+PrintGCTimeStamps －包含时间戳信息

\-XX:+PrintHeapAtGC －包括gc前后Heap状况

\-XX:+PrintTenuringDistribution －输出对象存活时间和Tenured Generation的其他信息

\-XX:+PrintHeapUsageOverTime －以时间戳输出heap利用率和容量信息

\-Xloggc:filename －输出gc信息到日志文件  
例如：

> set JAVA\_OPTS=%JAVA\_OPTS% -verbose:gc -Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC

如果输出的日志文件非常大，可以后续采用其它工具分析；或者干脆使用Jstat或Jconsole这些成熟的工具直接监控JVM的GC问题。当然，前边图示的VisualVM更是一款漂亮的、即时监控JVM GC的工具。

下面的命令把整个堆设置成128m，New/Old比率设置成3，即New与Old比例为1：3，New Space为Heap的1/4即32M, 缺省值为NewSize=2m MaxNewSize=32m SurvivorRatio=2

> java –Xms128m –Xmx128m –XX:NewRatio=3

但是，如果JVM的堆Heap大小大于1GB，则应该使用值：-XX:newSize=640m -XX:MaxNewSize=640m -XX:SurvivorRatio=16，或者将堆的总大小的50%到60%分配给新生成的池。

【JVM性能瓶颈】

在JAVA应用程序中，虽然不太容易出现内存泄漏的问题，因为JVM会不定期的进行垃圾回收。但是因为程序的不合理写法，也会导致一些数据不能被收集。典型的状况是在HashMap中放置大量不用的数据，而没有及时的清理。在web应用中，很多人喜欢在Session放放置状态数据，而没有清理，也是内存泄漏的一个原因。在Session中存放数据还好，因为Session终究会有过期时间，但是如果在Class的Static变量中放置数据，那就怎么样也没办法了。诊断应用中是否存在内存泄漏也有一些方法，通过分析JVM GC Log就是一个直观的方式。通过分析GC After Heap的变化趋势，如果GC After Heap稳步上升，立刻进行Full GC后，仍然不能降下来，通常就意味着存在内存泄漏了。当然也有情况是，的确有一些数据是应用程序的需求，我们要确认除了这些数据，是否还存在一些异常数据一直占据内存。可以通过JProbe的Memory Views来观察Class的对象数，在一段请求过后，如果还存在一些Class的Instance数目相当多，就可以判断这个Class可能会是问题的根源。

[128d719ff9cg215.jpg]: /images/20210726/cde3f11c7a064f1e908faa3f30b38eb0.png
[128d719ff9cg215.jpg 1]: http://pp.sohu.com/photoview-319443767-25087292.html