JVM内存段分配,Java垃圾回收调优,Heap设定

1、3/26/2013第7页，共7页Page ,Total7JVM内存段分配，Java垃圾回收调优,Heap设定1.JVM内存段分配及启动参数：J2EE服务器的内存组成：?Java堆：我们的程序和对象都在这个堆进行管理?C堆：当引用到一些Native的对象，如网络访问、OCI方式的数据库连接等都在C堆里进行管理Java堆的描述：如下图?Young及Old区域用来存放由Java类而生成的内存对象；?Perm区域用来存放Java类及其他虚拟机自己的静态数据垃圾回收描述：垃圾回收分多级，0级为全部(Full)的垃圾回收，会回收OLD段中的垃圾；1级或以上为部分垃圾回收，只会回收Young中的垃圾，内存溢

2、出通常发生于OLD段或Perm段垃圾回收后，仍然无内存空间容纳新的Java对象的情况。当一个URL被访问时，内存申请过程如下：JVM会试图为相关Java对象在Eden中初始化一块内存区域当Eden空间足够时，内存申请结束。否则到下一步JVM试图释放在Eden中所有不活跃的对象(这属于1或更高级的垃圾回收)；释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区/OLD区Survivor区被用来作为Eden及OLD的中间交换区域，当OLD区空间足够时，Survivor区的对象会被移到Old区，否则会被保留在Survivor区当OLD区空间不够时，JVM会在

3、OLD区进行完全的垃圾收集(0级)完全垃圾收集后，若Survivor及OLD区仍然无法存放从Eden复制过来的部分对象，导致JVM无法在Eden区为新对象创建内存区域，则出现outofmemory错误”Java堆相关参数：ms/mx:定义YOUNG+OLD段的总尺寸，ms为JVM启动时YOUNG+OLD的内存大小；mx为最大可占用的YOUNG+OLD内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。NewSize/MaxNewSize：定义YOUNG段的尺寸，NewSize为JVM启动时YOUNG的内存大小；MaxNewSize为最大可占用的YOUNG

4、内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。PermSize/MaxPermSize:定义Perm段的尺寸，PermSize为JVM启动时Perm的内存大小；MaxPermSize为最大可占用的Perm内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。SurvivorRatio:设置Survivor空间和Eden空间的比例例：MEM_ARGS=-Xms512m-Xmx512m-XX:NewSize=256m-XX:MaxNewSize=256m-XX:PermSize=128m-XX:MaxPermSiz

5、e=128m-XX:SurvivorRatio=6在上面的例子中：YOUNG+OLD:512MYOUNG:256MPerm:128MEden:YOUNG*6/(6+1+1)=192MSurvivor:YOUNG/(6+1+1)=32MJava堆的总尺寸=YOUNG+OLD+Perm=640MJVM内存分析工具可以使用HPjmeter来进行分析，需要将JDK的GC日志打开(-verbose:gc),可定期用HPjmeter对GC日志进行分析，Demo工具可提供JavaHeap内存变化图，以及垃圾回收图，这样就很容易分析内存溢出时是哪个段产生问题内存溢出的可能性OLD段溢出这种内存溢出是最常见的情

6、况之一，产生的原因可能是：设置的内存参数过小(ms/mx,NewSize/MaxNewSize)程序问题?单个程序持续进行消耗内存的处理，如循环几千次的字符串处理，对字符串处理应建议使用StringBuffer。此时不会报内存溢出错，却会使系统持续垃圾收集，无法处理其它请求，相关问题程序可通过ThreadDump获取(见系统问题诊断一章)?单个程序所申请内存过大，有的程序会申请几十乃至几百兆内存，此时JVM也会因无法申请到资源而出现内存溢出，对此首先要找到相关功能，然后交予程序员修改，要找到相关程序，必须在Apache日志中寻找。?当Java对象使用完毕后，其所引用的对象却没有销毁，使得JVM

7、认为他还是活跃的对象而不进行回收，这样累计占用了大量内存而无法释放。由于目前市面上还没有对系统影响小的内存分析工具，故此时只能和程序员一起定位。Perm段溢出通常由于Perm段装载了大量的Servlet类而导致溢出，目前的解决办法：将PermSize扩大，一般256M能够满足要求若别无选择，贝I只能将servlet的路径加到CLASSPATH中，但一般不建议这么处理CHeap溢出系统对CHeap没有限制，故CHeap发生问题时，Java进程所占内存会持续增长，直到占用所有可用系统内存。1.1Java垃圾回收调优在Java中，通常通讯类型的服务器对GC(GarbageCollection)比较敏

8、感。通常通讯服务器每秒需要处理大量进出的数据包，需要解析，分解成不同的业务逻辑对象并做相关的业务处理，这样会导致大量的临时对象被创建和回收。同时服务器如果需要同时保存用户状态的话，又会产生很多永久的对象，比如用户session。业务越复杂的应用往往用户session包含的引用对象就越多。这样在极端情况下会发生两件事情，longgcpausetime或outofmemory。一，要解决longpausetime首先要了解JVM中heap的结构JProinToEETenured、/PermanentYoniifCieneratioiiSwvivwrRatioefau.ll；32twind:Newl

9、tatio2(1:2)climtvmN(L:servervmSumwirSpa;eOld(jEH&raEianjavagcheapJavaHeap为什么要分成几个不同的代(generation)?由于80%-98%的对象的生存周期很短，大部分新对象存放在younggeneration可以很高效的回收，避免遍历所有对象。young与old中内存分配的算法完全不同oyounggeneration中由于存活的很少，要mark,sweep然后再compact剩余的对象比较耗时，干脆把liveobjectcopy到另外一个空间更高效。oldgeneration完全相反，里面的liveobject变化较少

10、。因此采用mark-sweep-compact更合适。二，Java中四种垃圾回收算法Java中有四种不同的回收算法，对应的启动参数为-XX:+UseSerialGC-XX:+UseParallelGC-XX:+UseParallelOldGC-XX:+UseConcMarkSweepGCSerialCollector大部分平台或者强制java-client默认会使用这种。younggeneration算法=serialoldgeneration算法=serial(mark-sweep-compact)这种方法的缺点很明显，stop-the-world,速度慢。服务器应用不推荐使用。Parall

11、elCollector在linuxx64上默认是这种，其他平台要加java-server参数才会默认选用这种。young=parallel，多个thread同时copyold=mark-sweep-compact=1优点：新生代回收更快。因为系统大部分时间做的gc都是新生代的，这样提高了throughput(cpu用于非gc时间)缺点：当运行在8G/16Gserver上oldgenerationliveobject太多时候pausetime过长ParallelCompactCollector(ParallelOld)young=parallel=2old=parallel,分成多个独立的单元，

12、如果单元中liveobject少则回收，多则跳过优点：oldoldgeneration上性能较parallel方式有提高缺点：大部分server系统oldgeneration内存占用会达到60%-80%,没有那么多理想的单元liveobject很少方便迅速回收，同时compact方面开销比起parallel并没明显减少。ConcurentMark-Sweep(CMS)Collectoryounggeneration=parallelcollector=2old=cms同时不做compact操作。优点：pausetime会降低,pause敏感但CPU有空闲的场景需要建议使用策略4.缺点：cpu占

13、用过多，cpu密集型服务器不适合。另外碎片太多，每个object的存储都要通过链表连续跳n个地方，空间浪费问题也会增大。几条经验：java-server设置Xms=Xmx=3/4物理内存如果是CPU密集型服务器，使用-XX:+UseParallelOldGC,否则-XX:+UseConcMarkSweepGC新生代,Parallel/ParallelOld可设大于Xmxl/4,CMS可设小，小于Xmxl/4优化程序，特别是每个用户的session中的集合类等。我们的一个模块中session中曾经为每个用户使用了一个ConcurrentHashMap,里面通常只有几条记录，后来改成数组之后，每台

14、机大概节约了12G内存。不过总的说来，Java的GC算法感觉是业界最成熟的，目前很多其他语言或者框架也都支持GC了，但大多数都是只达到JavaSerialgc这种层面，甚至分generation都未考虑。JDK7里面针对CMS又进行了一种改进，会采用一种Gl(Garbage-FirstGarbageCollection)的算法。实际上Garbage-Firstpaper(PDF)2004年已经出来了，相信到JDK7已经可以用于严格生产环境，有时间也会进一步介绍一下G1。另夕卜在今年的SunTechDays上JoeyShen讲的ImprovingJavaPerformance(PDF)也是一个很

15、好的JavaGC调优的入门教程。Heap设定与垃圾回收JavaHeap分为3个区，Young,Old和Permanent。Young保存刚实例化的对象。当该区被填满时，GC会将对象移到Old区。Permanent区则负责保存反射对象，本文不讨论该区。JVM的Heap分配可以使用-X参数设定，-Xms初始Heap大小-Xmxjavaheap最大值-Xmnyounggeneration的heap大小JVM有2个GC线程。第一个线程负责回收Heap的Young区。第二个线程在Heap不足时，遍历Heap，将Young区升级为OIder区。Older区的大小等于-Xmx减去-Xmn，不能将-Xms的值

16、设的过大，因为第二个线程被迫运行会降低JVM的性能。为什么一些程序频繁发生GC?有如下原因：程序内调用了System.gc()或Runtime.gc()。一些中间件软件调用自己的GC方法，此时需要设置参数禁止这些GC。Java的Heap太小，一般默认的Heap值都很小。频繁实例化对象，Release对象。此时尽量保存并重用对象，例如使用StringBuffer()和String。如果你发现每次GC后，Heap的剩余空间会是总空间的50%，这表示你的Heap处于健康状态。许多Server端的Java程序每次GC后最好能有65%的剩余空间。经验之谈：Server端JVM最好将-Xms和-Xmx设为

17、相同值。为了优化GC,最好让-Xmn值约等于-Xmx的1/32。一个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溢漏。硬件环境硬件环境也影响GC的效率，例如机器的种类，内存，swap空间，和CPU的数量。如果你的程序需要频繁创建很多transient对象，会导致JVM频繁GC。这种情况你可以增加机器的内存，来减少Swap空间的使用。4种GC第一种为单线程GC,也是默认的GC。，该GC适用于单CPU机器。第二种为ThroughputGC，是多线程的GC，适用于多CPU，使用大量线程的程序。第二种GC与第一种GC相似，不同在于G