JVM内存的调优

一.JVM内存的设置的原理

默认的java虚拟机的大小比较小，在对大数据进行处理时java就会报错：java.lang.OutOfMemoryError。设置jvm内存的方法，对于单独的.class，能够用下面的方法对Test运行时的jvm内存进行设置。
java -Xms64m -Xmx256m Test
-Xms是设置内存初始化的大小
-Xmx是设置最大可以使用内存的大小（最好不要超过物理内存大小）
在weblogic中，能够在startweblogic.cmd中对每一个domain虚拟内存的大小进行设置，默认的设置是在commEnv.cmd里面。

-vmargs
-Xms128M
-Xmx512M
-XX:PermSize=64M
-XX:MaxPermSize=128M

下面是这几个设置的一些背景知识：

• 堆(Heap)和非堆(Non-heap)内存
  按照官 方的说法：“Java 虚拟机具备一个堆，堆是运行时数据区域，全部类实例和数组的内存均今后处分配。堆是在 Java 虚拟机启动时建立的。”“在JVM中堆以外的内存称为非堆内存(Non-heap memory)”。能够看出JVM主要管理两种类型的内存：堆和非堆。简单来讲堆就是Java代码可及的内存，是留给开发人员使用的；非堆就是JVM留给 本身用的，因此方法区、JVM内部处理或优化所需的内存(如JIT编译后的代码缓存)、每一个类结构(如运行时常数池、字段和方法数据)以及方法和构造方法 的代码都在非堆内存中。
• 堆内存分配
  JVM初始分配的内存由-Xms 指定，默认是物理内存的1/64；JVM最 大分配的内存由-Xmx指定，默认是物理内存的1/4。默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时， JVM会减小堆直到-Xms的最小限制。所以服务器通常设置-Xms、-Xmx相等以免在每次GC 后调整堆的大小。
• 非堆内存分配
  JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；由XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。
• JVM内存限制(最大值)
  首先JVM内存首 先受限于实际的最大物理内存，假设物理内存无限 大的话，JVM内存的最大值跟操做系统有很大的关系。简单的说就32位处理器虽然可控内存空间有4GB,可是具体的操做系统会给一个限制，这个限制通常是 2GB-3GB（通常来讲Windows系统下为1.5G-2G，Linux系统下为2G-3G），而64bit以上的处理器就不会有限制了

JVM内存的调优

1. Heap设定与垃圾回收Java Heap分为3个区，Young，Old和Permanent。Young保存刚实例化的对象。当该区被填满时，GC会将对象移到Old区。Permanent区则负责保存反射对象，本文不讨论该区。JVM的Heap分配可使用-X参数设定，

-Xms	初始Heap大小
-Xmx	java heap最大值
-Xmn	young generation的heap大小

JVM有2个GC线程。第一个线程负责回收Heap的Young区。第二个线程在Heap不足时，遍历Heap，将Young 区升级为Older区。Older区的大小等于-Xmx减去-Xmn，不能将-Xms的值设的过大，由于第二个线程被迫运行会下降JVM的性能。

为何一些程序频繁发生GC？有以下缘由：

l         程序内调用了System.gc()或Runtime.gc()。

l         一些中间件软件调用本身的GC方法，此时须要设置参数禁止这些GC。

l         Java的Heap过小，通常默认的Heap值都很小。

l         频繁实例化对象，Release对象。此时尽可能保存并重用对象，例如使用StringBuffer()和String()。

         若是你发现每次GC后，Heap的剩余空间会是总空间的50%，这表示你的Heap处于健康状态。许多Server端的Java程序每次GC后最好能有65%的剩余空间。经验之谈：

1．Server端JVM最好将-Xms和-Xmx设为相同值。为了优化GC，最好让-Xmn值约等于-Xmx的1/3[2]。

2．一个GUI程序最好是每10到20秒间运行一次GC，每次在半秒以内完成[2]。

注意：

1．增长Heap的大小虽然会下降GC的频率，但也增长了每次GC的时间。而且GC运行时，全部的用户线程将暂停，也就是GC期间，Java应用程序不作任何工做。

2．Heap大小并不决定进程的内存使用量。进程的内存使用量要大于-Xmx定义的值，由于Java为其余任务分配内存，例如每一个线程的Stack等。

2．Stack的设定

每一个线程都有他本身的Stack。

-Xss	每一个线程的Stack大小

Stack的大小限制着线程的数量。若是Stack过大就好致使内存溢漏。-Xss参数决定Stack大小，例如-Xss1024K。若是Stack过小，也会致使Stack溢漏。

3．硬件环境

硬件环境也影响GC的效率，例如机器的种类，内存，swap空间，和CPU的数量。

若是你的程序须要频繁建立不少transient对象，会致使JVM频繁GC。这种状况你能够增长机器的内存，来减小Swap空间的使用[2]。

4．4种GC

第一种为单线程GC，也是默认的GC。，该GC适用于单CPU机器。

第二种为Throughput GC，是多线程的GC，适用于多CPU，使用大量线程的程序。第二种GC与第一种GC类似，不一样在于GC在收集Young区是多线程的，但在Old区和第一种同样，仍然采用单线程。-XX:+UseParallelGC参数启动该GC。

第三种为Concurrent Low Pause GC，相似于第一种，适用于多CPU，并要求缩短因GC形成程序停滞的时间。这种GC能够在Old区的回收同时，运行应用程序。-XX:+UseConcMarkSweepGC参数启动该GC。

第四种为Incremental Low Pause GC，适用于要求缩短因GC形成程序停滞的时间。这种GC能够在Young区回收的同时，回收一部分Old区对象。-Xincgc参数启动该GC。

4种GC的具体描述参见[3]。

 

参考文章：

1. JVM Tuning. http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp#garbage-collection

2. Performance tuning Java: Tuning steps

http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,1604,00.html

3. Tuning Garbage Collection with the 1.4.2 JavaTM Virtual Machine .

http://java.sun.com/docs/hotspot/gc1.4.2/

 

二．Tomcat配置

问题分析：

　　　因为TOMCAT内存溢出而引起的问题，主要缘由是JVM的虚拟内存默认为128M，当超过这个值时就把先前占用的内存释放，而致使好象TCP/IP丢包的假象，出现HTTP500的错误。解决方法主要是加大TOMCAT可利用内存，并在程序当中加大内存使用。

 

解决方法：

方法：加大TOMCAT可利用内存：

　　在TOMCAT的目录下，也就是在TOMCAT41/bin/catalina.bat文件最前面加入

　　set JAVA_OPTS=-Xms800m -Xmx800m

　　表现效果是当你启动TOMCAT时，系统内存会增长近800M使用

操做方法：

　　1）、先关掉WINDOWS服务当中的TOMCAT4服务。

　　2）、再找到TOMCAT/BIN目录下startup.bat，双击打开它，你会发现现WINDOWS内存占用会增长近800M。

　　3）、执行程序，由于是TOMCAT从新编译程序，因此第一次会比较慢。

结论：

通过测试，咱们得出以下数据：

当系统传输约2000条数据时，大约近12M的净数据（不压缩时），系统辅助运行的内存大约占用150M左右的空间，也就是近200M的内存占用，而咱们扩大了近800M的JAVA内存使用，这对于业务自己来讲是足够了。因此大家不用担忧大数据量的传递问题。

基于JAVA虚拟机的原理，JAVA自动有垃圾回收机制，也就是在你对一些内存长时间不使用时（近2分钟，取决于使用频度和优先级等），就会自动垃圾回收，从而释放不用的内存占用。

 

三.WebLogic配置：

 因为WebLogic的配置问题，咱们的测试出现了失败状况。缘由是为WebLogic分配的内存太少了。经过修改commom/bin/commEnv.cmd文件来增长内存分配。

 修改的部分以下：

:bea

if "%PRODUCTION_MODE%" == "true" goto bea_prod_mode

set JAVA_VM=-jrockit

set MEM_ARGS=-Xms768m -Xmx1024m

set JAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:none

goto continue

:bea_prod_mode

set JAVA_VM=-jrockit

set MEM_ARGS=-Xms768m -Xmx1024m//原来是128M~256M，过小了，数据太大

goto continue

 结果修改后，没有效果。仍是有失败的状况。

 发现，原来，在：bea下面还有一段配置信息以下：

:sun

if "%PRODUCTION_MODE%" == "true" goto sun_prod_mode

set JAVA_VM=-client

set MEM_ARGS=-Xms768m -Xmx1024m -XX:MaxPermSize=256m

set JAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:none

goto continue

:sun_prod_mode

set JAVA_VM=-server

set MEM_ARGS=-Xms768m -Xmx1024m -XX:MaxPermSize=256m

goto continue

 将这里的内存分配修改后见效。

 缘由是，上面对第一段代码是为bea本身的JVM设置的，下面的是为Sun的设置的。而WebLogic默认的是Sun的，因此出了毛病。在JDK的选择上，weblogic有两种JDK供选择，一种是Sun的JDK，另一种是Bea的jrockit。按照bea的网站的说明，sun jdk提供更好的兼容性，而使用jrockit能够提供更好的性能。做为weblogic集群我所有采用jrockit做为JDK环境，以达到更高的性能。

 

在默认启动状况下，jrockit启动时为其窗口配置的内存大小比较小。注意weblogic的启动内存配置-Xms32m -Xmx256m，经过修改commEnv.sh能够修改这个参数，Xms表示启动开始分配的内存，Xmx表示最大能分配的内存，这里咱们根据应用状况调整为-Xms1536m -Xmx1536m，这点须要根据自身测试状况和系统配置进行调整，通过周一晚的调试，咱们目前应用比较合理的窗口内存大小为1536M（2G× 75％），经过top能够观察到测试中的内存反应，最合理的应该是刚好把物理内存用完。