jvm垃圾回收调整

[b]JVM的垃圾回收机制详解和调优
Sun HotSpot 1.4.1 JVM堆大小的调整[/b]

　 　Sun HotSpot 1.4.1使用分代收集器，它把堆分为三个主要的域：新域、旧域以及永久域。Jvm生成的所有新对象放在新域中。一旦对象经历了一定数量的垃圾收集循环 后，便获得使用期并进入旧域。在永久域中jvm则存储class和method对象。就配置而言，永久域是一个独立域并且不认为是堆的一部分。

　　下面介绍如何控制这些域的大小。可使用-Xms和-Xmx 控制整个堆的原始大小或最大值。
　　下面的命令是把初始大小设置为128M：
　　java –Xms128m
　　–Xmx256m为控制新域的大小，可使用-XX:NewRatio设置新域在堆中所占的比例。

　　下面的命令把整个堆设置成128m，新域比率设置成3，即新域与旧域比例为1：3，新域为堆的1/4或32M：
　　java –Xms128m –Xmx128m
　　–XX:NewRatio =3可使用-XX:NewSize和-XX:MaxNewsize设置新域的初始值和最大值。

　　下面的命令把新域的初始值和最大值设置成64m:
　　java –Xms256m –Xmx256m –Xmn64m
　　永久域默认大小为4m。运行程序时，jvm会调整永久域的大小以满足需要。每次调整时，jvm会对堆进行一次完全的垃圾收集。

　 　使用-XX:MaxPerSize标志来增加永久域搭大小。在WebLogic Server应用程序加载较多类时，经常需要增加永久域的最大值。当jvm加载类时，永久域中的对象急剧增加，从而使jvm不断调整永久域大小。为了避免 调整，可使用-XX:PerSize标志设置初始值。
　　下面把永久域初始值设置成32m，最大值设置成64m。
　　java -Xms512m -Xmx512m -Xmn128m -XX:PermSize=32m -XX:MaxPermSize=64m

　 　默认状态下，HotSpot在新域中使用复制收集器。该域一般分为三个部分。第一部分为Eden，用于生成新的对象。另两部分称为救助空间，当Eden 充满时，收集器停止应用程序，把所有可到达对象复制到当前的from救助空间，一旦当前的from救助空间充满，收集器则把可到达对象复制到当前的to救 助空间。From和to救助空间互换角色。维持活动的对象将在救助空间不断复制，直到它们获得使用期并转入旧域。使用-XX:SurvivorRatio 可控制新域子空间的大小。

　　同NewRation一样，SurvivorRation规定某救助域与Eden空间的比值。比如，以下命令把新域设置成64m，Eden占32m，每个救助域各占16m：
　　java -Xms256m -Xmx256m -Xmn64m -XX:SurvivorRation =2
运行程序时，JVM会调整永久域的大小以满足需要。每次调整时，JVM会对堆进行一次完全的垃圾收 集。使用-XX:MaxPerSize标志来增加永久域搭大小。在WebLogic Server应用程序加载较多类时，经常需要增加永久域的最大值。当JVM加载类时，永久域中的对象急剧增加，从而使JVM不断调整永久域大小。为了避免 调整，可使用-XX:PerSize标志设置初始值。比如，下面把永久域初始值设置成32m，最大值设置成64m。 java –Xms512m –Xmx512m –Xmn128m –XX:PermSize=32m –XX:MaxPermSize=64m 默认状态下，HotSpot在新域中使用复制收集器。该域一般分为三个部分。第一部分为Eden，用于生成新的对象。另两部分称为救助空间，当Eden充满 时，收集器停止应用程序，把所有可到达对象复制到当前的from救助空间，一旦当前的from救助空间充满，收集器则把可到达对象复制到当前的to救助空 间。From和to救助空间互换角色。维持活动的对象将在救助空间不断复制，直到它们获得使用期并转入旧域。使用-XX:SurvivorRatio可控制新域子空间的大小。同NewRation一样，SurvivorRation规定某救助域与Eden空间的比值。比如，以下命令把新域设置成64m，Eden占32m，每个救助域各占16m： java –Xms256m –Xmx256m –Xmn64m –XX:SurvivorRation=2 如前所述，默认状态下HotSpot对新域使用复制收集器，对旧域使用标记－清除－压缩收集器。在新域中使用复制收集器有很多意义，因为应用程序生成的大 部分对象是短寿命的。理想状态下，所有过渡对象在移出Eden空间时将被收集。如果能够这样的话，并且移出Eden空间的对象是长寿命的，那么理论上可以 立即把它们移进旧域，避免在救助空间反复复制。但是，应用程序不能适合这种理想状态，因为它们有一小部分中长寿命的对象。最好是保持这些中长寿命的对象并放在新域中，因为复制小部分的对象总比压缩旧域廉价。为控制新域中对象的复制，可用-XX:TargetSurvivorRatio控制救助空间的比例。该值是一个百分比，默认值是50。当较大的堆栈使用较低的sruvivorratio时，应增加该值到80至90，以更好利用救助空间。用-XX:maxtenuring threshold可控制上限。为放置所有的复制全部发生以及希望对象从eden扩展到旧域，可以把MaxTenuring Threshold设置成0。设置完成后，实际上就不再使用救助空间了，因此应把SurvivorRatio设成最大值以最大化Eden空间，设置如下： java … -XX:MaxTenuringThreshold=0 –XX:SurvivorRatio＝5000 3.1.4 从JVM中获取信息以助于调整方案 -verbose.gc开关可显示GC的操作内容。打开它，可以显示最忙和最空闲收集行为发生的时间、收集前后的内存大小、收集需要的时间等。打开-xx:+ printgcdetails开关，可以详细了解GC中的变化。打开-XX: + PrintGCTimeStamps开关，可以了解这些垃圾收集发生的时间，自JVM启动以后以秒计量。最后，通过-xx: + PrintHeapAtGC开关了解堆的更详细的信息。为了了解新域的情况，可以通过-XX:=PrintTenuringDistribution开关了解获得使用期的对象权。 3.1.5 BEA JRockit JVM的使用 Bea WebLogic 8.1使用的新的JVM用于Intel平台。在Bea安装完毕的目录下可以看到有一个类似于jrockit81sp1_141_03的文件夹。这就是Bea新JVM所在目录。不同于HotSpot把Java字节码编译成本地码，它预先编译成类。JRockit还提供了更细致的功能用以观察JVM的运行状态，主要是独立的GUI控制台或者WebLogic Server控制台。Bea JRockit JVM支持4种垃圾收集器：分代复制收集器：它与默认的分代收集器工作策略类似。对象在新域中分配，即JRockit文档中的nursery。这种收集器最适合单CPU机上小型堆操作。单空间并发收集器：该收集器使用完整堆，并与背景线程共同工作。尽管这种收集器可以消除中断，但是收集器需花费较长的时间寻找死对象，而且处理应用程序时收集器经常运行。如果处理器不能应付应用程序产生的垃圾，它会中断应用程序并关闭收集。分代并发收集器：这种收集器在护理域使用排它复制收集器，在旧域中则使用并发收集器。由于它比单空间共同发生收集器中断频繁，因此它需要较少的内存，应用程序的运行效率也 较高，注意，过小的护理域可以导致大量的临时对象被扩展到旧域中。这会造成收集器超负荷运作，甚至采用排它性工作方式完成收集。并行收集器：该收集器也停止其他进程的工作，但使用多线程以加速收集进程。尽管它比其他的收集器易于引起长时间的中断，但一般能更好的利用内存，程序效率也较高。 默 认状态下，JRockit使用分代并发收集器。要改变收集器，可使用-Xgc:，对应四个收集器分别为gencopy， singlecon，gencon以及parallel。可使用-Xms和-Xmx设置堆的初始大小和最大值。要设置护理域，则使用-Xns: java –jrockit –Xms512m –Xmx512m –Xgc:gencon –Xns128m… 尽管JRockit支持-verbose:gc开关，但它输出的信息会因收集器的不同而异。JRockit还支持memory、load和codegen的输出。原文地址： http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=124&threadID=19031&tstart=0 3.2 WebLogic Server Hang产生的一般原因 3.2.1 系统内存不足 系统CPU忙，系统文件描述符数目不足，线程死锁，JVM有GC方面的bug，对于一些特定的情况可以使用truss命令跟踪系统调用来进行分析。可以打开JVM的gc log,在java命令行上加上-verbose:gc,GC的log输出在java进程的标准输出里,在hp的JVM上，可以通过在java命令行上加-Xverbosegc:file=gcfilename来将gc log写到指定的文件其输出类似：[GC 15639K->13700K(65280K), 0.0068439 secs]。解决办法是调整JVM的内存设置和gc算法,升级jvm或是os patch。 出现OutOfMemoryError或是观察到内存吃紧，操作系统本身的剩余内存，通过top或是vmstat观察，操作系统的swap区，Swap区太小可能导致编译jsp时报“Not enough space”的错，操作系统kernel参数中maxsize的大小，如果观测到数据库连接池里的连接泄漏，极可能是内存泄漏的先兆 JVM的heap区大小，通过java命令行中的-Xms,-Xmx指定，建议最小值和最大值设成一样，可以通过WebLogic console上server/monitor/performance来观察其使用情况，建议生产系统最256M，一般情况下可以设置为系统剩余物理内存的80％，Heap size太大在一些JVM上会有问题，对于sun和hp的JVM，permanent size太小也会出OutOfMemoryError，在java命令行上加-XX:MaxPermSize=128m 尽量减少内存消耗，Session中不要放大的数据，并尽量在不再需要的时候remove掉，如果可以调整session timeout到较小的值，避免在J2EE 内存泄漏，可以通过WebLogicserver端应用里边调用AWT/swing作图，调整ejb的cache/pool设置 console来观察JVM的heap memory使用情况来获知是否有内存泄漏情况，采用第三方辅助工具来获取更详细信息，如Jprobe/OptimizeIt；有可能是weblogic的bug，但绝大部分情况是由用户的应用引起的，最常见的代码问题是数据库连接没正常关闭。  如果是kernel态很多，需要OS厂商调整操作系统 如果用户访问量很大，CPU占用很高（user态）并不是异常3.2.2 系统CPU忙 采用top找到占用CPU很多的进程，如果是非weblogic进程，应该考虑将其移到另外的server上运行，如果是运行weblogic的java进程，通过做thread dump（详细信息后边会介绍到）来确认是那段代码导致了这么高的CPU使用（也有可能是os/jvm本身不正常） 3.2.3 系统文件描述符数目不足  ulimit –a –H 可以查看当前限制Log中有“too many open files”的错误，表示达到了系统对一个进程能同时打开的文件数的限制： Solaris上可以通过/usr/proc/bin/pfilesulimit –n number可以来更改当前环境的设置，建议至少设到4096 Solaris上root用户可以通过/usr/proc/bin/plimit -npid来查看指定进程的限制和当前使用的file descriptor数目 soft,hard pid 来动态更改进程的文件描述符的限制 3.2.4 线程死锁对于原因不明的hang或是响应慢，最根本的方法就是获取thread dump信息，对于windows系统，在运行java的窗口按Ctrl＋Break，对于UNIX系统，首先用ps找到运行weblogic的java进程的pid，然后执行kill –3 pid，JVM将负责将所有java进程的状态、执行堆栈dump到其标准输出，为了方便获取thread dump信息，在weblogic启动的时候，最好将其标准输出重定向到一个文件，为了反映线程状态的动态变化，需要接连多次做thread dump，每次间隔10-20s。 对于thread dump信息，主要关注的是线程的状态和其执行堆栈，线程的状态一般为三类 Waiting for monitor Waiting on monitor（CW）：线程主动wait Runnable（R）：当前可以运行的线程 entry（MW）：线程等锁一般关注的都是第一和第三种状态的线程 CPU很忙则关注runnable的线程 CPU闲则关注waiting for monitor entry的线程一种典型的死锁是由于在server端应用（比如servlet）中请求由同一weblogic实例serve的资源，解决办法就是将该servlet放到另外的执行队列里去执行。原文地址： http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=4525&tstart=0&quint=true 3.3 "指定的网络名不再可用"错误 wl6.1和wl7.0部署应用后都在后台抛出“java.net.SocketException: ReadFile failed: 指定的网络名不再可用”,这不是一个致命的错误，只会在中文Window上。如Hilaser和linstone提出了办法： 用wls6.1 sp4，到如下位置下载如果你是自己随便玩玩，将你的JDK升级到jdk1.3.1_06 http://commerce.bea.com/SoftwareProductDetailWLS?SWName=WebLogic+Server+Evaluation+Software&SWVersion=Version+6.1+SP4&SWPlatform=Microsoft+Windows+NT%2F2000 运行cmd，打开窗口菜单（点击左上角窗口图标），选择 默认值，将默认代码页改为437。原文地址： http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=81&threadID=9393&tstart=0 4 集群配置 4.1 集群简明配置过程在wls7中，集群的受管服务器无需使用相同的端口，这使在一个主机上实现集群成为可能。下面的例子是在一个主机（172.30.94.60）上的 wls7里创建一个集群（mycluster）DEMO，包括管理服务器（myserver:7001）、集群（两个受管服务器serverA: 8001、serverB:8003）、代理服务器（ProxyServer:80）。应用WebApp是部署在集群上的web应用，而 DefaultWebApp是部署在代理服务器上用来代理集群应用WebApp的。具体步骤如下： 1．创建集群域clusterdomainnew，管理服务器myserver（7001:7003）； 2．创建Machine：admin（myserver,ProxyServer），cluster(serverA,serverB)； 3．创建受管服务器serverA(8001)，serverB(8003)； 4．创建集群mycluster； Choose Servers for this Cluster: serverA，serverB config.xml: 5．部署WebApp应用，targets mucluster； 6．创建代理服务器ProxyServer（80），将DefaultWebApp targets ProxyServer； 7．编辑DefaultWebApp应用，注册HttpClusterServlet： HttpClusterServlet weblogic.servlet.proxy.HttpClusterServlet WebLogicCluster 172.30.94.60:8001:8002|172.30.94.60:8003:8004 DebugConfigInfo ON HttpClusterServlet / HttpClusterServlet *.jsp HttpClusterServlet *.htm HttpClusterServlet *. Linux联盟收集整理 ,转贴请标明原始链接,如有任何疑问欢迎来本站Linux论坛讨论


[b]VM （Hotpot VM）gc机制分析[/b]
JVM 中一个重大的性能问题是gc与应用程序线程的互斥性。垃圾收集器要完成垃圾收集，需要在一段时间内防止所有线程访问它正在处理的堆空间。这期间称为“stop-the-world”。因此gc 的频率和执行速度堆应用程序有着巨大的影响。
1. Hotpot JVM 类型
JDK Hotpot VM包含Client和Server两种类型。Client版本一般用于对启动速度和响应速度有要求的GUI程序，Server版本一般用于长时间运行的Server端程序。
JDK 能够根据运行环境自动检测JVM。 选择的基本条件是：运行环境至少有2个CPU，2G的物理内存。手动选择只需要设置JAVA启动参数 –server 或者 –client。
2. Hotpot JVM 内存结构
JVM 内存结构按代分为“年轻（Young）”、“年老（Old）”、“永久(Permanent)”3个区域:
[img]http://dl.iteye.com/upload/attachment/454260/dc26dbd5-1488-3f0d-8f06-69b5421abe8f.bmp[/img]

其中Yong 和 Old是属于Heap 区域，只要用来保存创建的对象，而Permanet则属于Non-heap区域，只要用来保存Class数据以及JVM内部使用。
–Xms, –Xmx 分别可以设置JVM Heap域的最小和最大值。
-XX:PerSize , -XX:MaxPerSize 分别可以设置Permanent 域的初始和最大值。
3. Hotpot JVM 内存回收机制和参数分析
JDK5.0开始，可以通过在启动参数中设置期望的性能目标，然后由Hotpot VM自动对垃圾回收参数进行设置，以满足我们设置的性能目标。
例如：
可以使用-XX:MaxGCPauseMillis=nnn来设置最大的垃圾回收停顿时间，多用于GUI程序，提高程序响应速度。
可以使用-XX:GCTimeRatio=nnn来设置垃圾回收占用时间的最大比例，多用于Server端程序，提高程序的吞吐量。
虽然JDK5.0提供了参数的自动设置功能，带来了很多方便，但不一定满足每个应用的需要，所以，如果有必要，通常还需要利用一些工具来辅助进行Hotpot VM参数的设置.
3.1 Permanent 域:
永久域默认大小为4m。运行程序时，jvm会调整永久域的大小以满足需要。每次调整时，jvm会对Permanent域进行一次完全的垃圾收集。
3.2 Young域:
Young域默认使用Copying Collector。一般分为如下3个部分

[img]http://dl.iteye.com/upload/attachment/454266/f28a74ac-1581-3dbb-bd5f-d198927b361f.bmp[/img]

第一部分为Eden，用于生成新的对象。另两部分称为Survivor Spaces。当Eden充满时，收集器停止应用程序，把所有可到达对象复制到当前的from救助空间，一旦当前的from救助空间充满，收集器则把可到达对象复制到当前的to救助空间。From和to救助空间互换角色。维持活动的对象将在救助空间不断复制，直到它们获得使用期并转入旧域。

[img]http://dl.iteye.com/upload/attachment/454264/26fc961e-e073-3c0d-98e2-abb013a80333.bmp[/img]

-XX:NewRatio 可以设置Young 和 Old 域的比例。
-XX:SurvivorRatio 可以设置Survivor 和 Eden space 的比例。
3.3 Old 域
Old域使用Mark-Compact Collector 来实现垃圾收集。也就是使用标记－清除－压缩的算法。
Old 域垃圾收集也叫Full GC往往需要较长的时间，为提高性能，要尽量极少Full GC的次数。
4. 测试GC
要正确设置合适的GC参数, 必须严格测试gc的信息.
-verbose:gc -Xloggc:filename 可以汇总gc信息输出到log文件里面
其他一些工具例如jvmstat 可以查看垃圾回收过程，内存变化情况等.
Hotpot VM有很多参数，详细参数列表请参看:
http://java.sun.com/docs/hotspot/VMOptions.html
5. 其他
5.1 其他一些参数:
-XX:+UseParallelGC: 缺省情况下，JVM内部的垃圾回收是有一个线程来完成的。如果有多个CPU，建议增加这个参数，通过多线程来提高垃圾回收的效率。
-XX:+AggressiveHeap: JVM会充分利用运行环境的中的物理内存。如果同一台机器中还存在其他应用，该参数应谨慎使用
5.2 关于垃圾回收，程序需要注意的几个方面：
不要调用System.gc()
不要重写Object.finalize()
尽早释放对象引用
6. 结束语
对gc的配置没有万灵丹,必须对不同的应用进行测试来寻求最优方案, 如果配置不当,反而带来性能的下降。