《jvm垃圾回收调整》由会员分享，可在线阅读，更多相关《jvm垃圾回收调整（6页珍藏版）》请在金锄头文库上搜索。
1、1JVM的垃圾回收机制详解和调优3.SunHotSpot堆大小的调整堆大小的调整使用分代收集器，它把堆分为三个主要的域：新域、旧域以及永久域。Jvm生成的所有新对象放在新域中。一旦对象经历了一定数量的垃圾收集循环后，便获得使用期并进入旧域。在永久域中jvm则存储class和method对象。就配置而言，永久域是一个独立域并且不认为是堆的一部分。下面介绍如何控制这些域的大小。可使用-Xms和-Xmx控制整个堆的原始大小或最大值。下面的命令是把初始大小设置为128Mjava-Xms128m-Xmx256啲控制新域的大小，可使用-XX:NewRatio设置新域在堆中所占的比例。下面的命令把整个堆设置
2、成128m新域比率设置成3,即新域与旧域比例为1:3,新域为堆的1/4或32Mjava-Xms128m-Xmx128m-XX:NewRatio=3可使用-XX:NewSize和-XX:MaxNewsize设置新域的初始值和最大值。下面的命令把新域的初始值和最大值设置成64m:java-Xms256m-Xmx256m-Xmn64m永久域默认大小为4m运行程序时，jvm会调整永久域的大小以满足需要。每次调整时，jvm会对堆进行一次完全的垃圾收集。使用-XX:MaxPerSize标志来增加永久域搭大小。在WebLogicServer应用程序加载较多类时，经常需要增加永久域的最大值。当jvm加载类时，
3、永久域中的对象急剧增加，从而使jvm不断调整永久域大小。为了避免调整，可使用-XX:PerSize标志设置初始值。下面把永久域初始值设置成32m最大值设置成64mjava-Xms512m-Xmx512m-Xmn128m-XX:PermSize=32m-XX:MaxPermSize=64m默认状态下，HotSpot在新域中使用复制收集器。该域一般分为三个部分。第一部分为Eden,用于生成新的对象。另两部分称为救助空间，当Eden充满时，收集器停止应用程序，把所有可到达对象复制到当前的from救助空间，一旦当前的from救助空间充满，收集器则把可到达对象复制到当前的to救助空间。From和to救助
4、空间互换角色。维持活动的对象将在救助空间不断复制，直到它们获得使用期并转入旧域。使用-XX:SurvivorRatio可控制新域子空间的大小同NewRation样，SurvivorRation规定某救助域与Eden空间的比值。比如，以下命令把新域设置成64mEden占32m,每个救助域各占16mjava-Xms256m-Xmx256m-Xmn64m-XX:SurvivorRation=2运行程序时，JVM会调整永久域的大小以满足需要。每次调整时，JVM会对堆进行一次完全的垃圾收集。使用-XX:MaxPerSize标志来增加永久域搭大小。在WebLogicServer应用程序加载较多类时，经常需
5、要增加永久域的最大值。当JVM加载类时，永久域中的对象急剧增加，从而使JVM不断调整永久域大小。为了避免调整，可使用-XX:PerSize标志设置初始值。比如，下面把永久域初始值设置成32m，最大值设置成64m。java-ms512m-Cmx512m-mn128m-X:PermSize=32m-CX:MaxPermSize=64m默认状态下，HotSpot在新域中使用复制收集器。该域一般分为三个部分。第一部分为Eden，用于生成新的对象。另两部分称为救助空间，当Eden充满时，收集器停止应用程序，把所有可到达对象复制到当前的from救助空间，一旦当前的from救助空间充满，收集器则把可到达对象
6、复制到当前的to救助空间。From和to救助空间互换角色。维持活动的对象将在救助空间不断复制，直到它们获得使用期并转入旧域。使用-XX:SurvivorRatio可控制新域子空间的大小。同NewRation一样，SurvivorRation规定某救助域与Eden空间的比值。比如，以下命令把新域设置成64m，Eden占32m，每个救助域各占16m:java-ms256m-Cmx256m-mn64m-CX:SurvivorRation=2如前所述，默认状态下HotSpot对新域使用复制收集器，对旧域使用标记清除压缩收集器。在新域中使用复制收集器有很多意义，因为应用程序生成的大部分对象是短寿命的。理
7、想状态下，所有过渡对象在移出Eden空间时将被收集。如果能够这样的话，并且移出Eden空间的对象是长寿命的，那么理论上可以立即把它们移进旧域，避免在救助空间反复复制。但是，应用程序不能适合这种理想状态，因为它们有一小部分中长寿命的对象。最好是保持这些中长寿命的对象并放在新域中，因为复制小部分的对象总比压缩旧域廉价。为控制新域中对象的复制，可用-XX:TargetSurvivorRatio控制救助空间的比例。该值是一个百分比，默认值是50。当较大的堆栈使用较低的sruvivorratio时，应增加该值到80至90，以更好利用救助空间。用-XX:maxtenuringthreshold可控制上限。
8、为放置所有的复制全部发生以及希望对象从eden扩展到旧域，可以把MaxTenuringThreshold设置成0。设置完成后，实际上就不再使用救助空间了，因此应把SurvivorRatio设成最大值以最大化Eden空间，设置如下：java-XX:MaxTenuringThreshold=0-X:SurvivorRatio=5000从JVM中获取信息以助于调整方案-verbose.gc开关可显示GC的操作内容。打开它，可以显示最忙和最空闲收集行为发生的时间、收集前后的内存大小、收集需要的时间等。打开-xx:+printgcdetails开关，可以详细了解GC中的变化。打开-XX:+PrintGC
9、TimeStamps开关，可以了解这些垃圾收集发生的时间，自JVM启动以后以秒计量。最后，通过-xx:+PrintHeapAtGC开关了解堆的更详细的信息。为了了解新域的情况，可以通过-XX:=PrintTenuringDistribution开关了解获得使用期的对象权。的使用BeaWebLogic8.1使用的新的JVM用于Intel平台。在Bea安装完毕的目录下可以看到有一个类似于jrockit81sp1_141_03的文件夹。这就是Bea新JVM所在目录。不同于HotSpot把Java字节码编译成本地码，它预先编译成类。JRockit还提供了更细致的功能用以观察JVM的运行状态，主要是独立
10、的GUI控制台或者WebLogicServer控制台。BeaJRockitJVM支持4种垃圾收集器：分代复制收集器：它与默认的分代收集器工作策略类似。对象在新域中分配，即JRockit文档中的nursery。这种收集器最适合单CPU机上小型堆操作。单空间并发收集器：该收集器使用完整堆，并与背景线程共同工作。尽管这种收集器可以消除中断，但是收集器需花费较长的时间寻找死对象，而且处理应用程序时收集器经常运行。如果处理器不能应付应用程序产生的垃圾，它会中断应用程序并关闭收集。分代并发收集器：这种收集器在护理域使用排它复制收集器，在旧域中则使用并发收集器。由于它比单空间共同发生收集器中断频繁，因此它需
11、要较少的内存，应用程序的运行效率也较高，注意，过小的护理域可以导致大量的临时对象被扩展到旧域中。这会造成收集器超负荷运作，甚至采用排它性工作方式完成收集。并行收集器：该收集器也停止其他进程的工作，但使用多线程以加速收集进程。尽管它比其他的收集器易于引起长时间的中断，但一般能更好的利用内存，程序效率也较高。默认状态下，JRockit使用分代并发收集器。要改变收集器，可使用-Xgc:，对应四个收集器分别为gencopy，singlecon，gencon以及parallel。可使用-Xms和-Xmx设置堆的初始大小和最大值。要设置护理域，则使用-Xns:java-rockit-ms512m-mx51
12、2m-13700K(65280K),0.0068439secs。解决办法是调整JVM的内存设置和gc算法，升级jvm或是ospatch。出现OutOfMemoryError或是观察到内存吃紧，操作系统本身的剩余内存，通过top或是vmstat观察，操作系统的swap区，Swap区太小可能导致编译jsp时报“NotEnoughspace的错，操作系统kernel参数中maxsize的大小，如果观测到数据库连接池里的连接泄漏，极可能是内存泄漏的先兆JVM的heap区大小，通过java命令行中的-Xms,-Xmx指定，建议最小值和最大值设成一样，可以通过WebLogicconsole上server/
13、monitor/performance来观察其使用情况，建议生产系统最256M，一般情况下可以设置为系统剩余物理内存的80%，Heapsize太大在一些JVM上会有问题，对于sun和hp的JVM，permanent.size太小也会出OutOfMemoryError，在java命令行上加-XX:MaxPermSize=128m尽量减少内存消耗，Session中不要放大的数据，并尽量在不再需要的时候remove掉，如果可以调整sessiontimeout到较小的值，避免在J2EE内存泄漏，可以通过WebLogic-server端应用里边调用AWT/swing作图，调整ejb的cache/pool
14、设置console来观察JVM的heapmemory使用情况来获知是否有内存泄漏情况，采用第三方辅助工具来获取更详细信息，如Jprobe/Optimizelt;有可能是weblogic的bug，但绝大部分情况是由用户的应用引起的，最常见的代码问题是数据库连接没正常关闭。如果是kernel态很多，需要OS厂商调整操作系统如果用户访问量很大，CPU占用很高(user态)并不是异常系统CPU忙采用top找到占用CPU很多的进程，如果是非weblogic进程，应该考虑将其移到另外的server上运行，如果是运行weblogic的java进程，通过做threaddump(详细信息后边会介绍到)来确认是那
15、段代码导致了这么高的CPU使用(也有可能是os/jvm本身不正常)系统文件描述符数目不足ulimit-a-H可以查看当前限制/Log中有“toomanyopenfiles的错误，表示达到了系统对一个进程能同时打开的文件数的限制：Solaris上可以通过/usr/proc/bin/pfiles-ulimitnumber可以来更改当前环境的设置，建议至少设到4096Solaris上root用户可以通过/usr/proc/bin/plimit-npid来查看指定进程的限制和当前使用的filedescriptor数目soft,hardpid来动态更改进程的文件描述符的限制线程死锁对于原因不明的hang或是响应慢，最根本的方法就是获取threaddump信息，对于windows系统，在运行java的窗口按Ctrl+Break，对于UNIX系统，首先用ps找到运行weblogic的ja
