JVM的垃圾回收机制详解和调优
gc即垃圾收集机制是指jvm用于释放那些不再使用的对象所占用的内存。java语言并不要求jvm有gc，也没有规定gc如何工作。不过常用的jvm都有gc，而且大多数gc都使用类似的算法管理内存和执行收集操作。
1.JVM的gc概述
gc即垃圾收集机制是指jvm用于释放那些不再使用的对象所占用的内存。java语言并不要求jvm有gc，也没有规定gc如何工作。不过常用的jvm都有gc，而且大多数gc都使用类似的算法管理内存和执行收集操作。
在充分理解了垃圾收集算法和执行过程后，才能有效的优化它的性能。有些垃圾收集专用于特殊的应用程序。比如，实时应用程序主要是为了避免垃圾收集中断，而大多数OLTP应用程序则注重整体效率。理解了应用程序的工作负荷和jvm支持的垃圾收集算法，便可以进行优化配置垃圾收集器。
垃圾收集的目的在于清除不再使用的对象。gc通过确定对象是否被活动对象引用来确定是否收集该对象。gc首先要判断该对象是否是时候可以收集。两种常用的方法是引用计数和对象引用遍历。
1.1.引用计数
引用计数存储对特定对象的所有引用数，也就是说，当应用程序创建引用以及引用超出范围时，jvm必须适当增减引用数。当某对象的引用数为0时，便可以进行垃圾收集。
1.2.对象引用遍历
早期的jvm使用引用计数，现在大多数jvm采用对象引用遍历。对象引用遍历从一组对象开始，沿着整个对象图上的每条链接，递归确定可到达（reachable）的对象。如果某对象不能从这些根对象的一个（至少一个）到达，则将它作为垃圾收集。在对象遍历阶段，gc必须记住哪些对象可以到达，以便删除不可到达的对象，这称为标记（marking）对象。
下一步，gc要删除不可到达的对象。删除时，有些gc只是简单的扫描堆栈，删除未标记的未标记的对象，并释放它们的内存以生成新的对象，这叫做清除（sweeping）。这种方法的问题在于内存会分成好多小段，而它们不足以用于新的对象，但是组合起来却很大。因此，许多gc可以重新组织内存中的对象，并进行压缩（compact），形成可利用的空间。
为此，gc需要停止其他的活动活动。这种方法意味着所有与应用程序相关的工作停止，只有gc运行。结果，在响应期间增减了许多混杂请求。另外，更复杂的gc不断增加或同时运行以减少或者清除应用程序的中断。有的gc使用单线程完成这项工作，有的则采用多线程以增加效率。
2.几种垃圾回收机制
2.1.标记－清除收集器
这种收集器首先遍历对象图并标记可到达的对象，然后扫描堆栈以寻找未标记对象并释放它们的内存。这种收集器一般使用单线程工作并停止其他操作。
2.2.标记－压缩收集器
有时也叫标记－清除－压缩收集器，与标记－清除收集器有相同的标记阶段。在第二阶段，则把标记对象复制到堆栈的新域中以便压缩堆栈。这种收集器也停止其他操作。
2.3.复制收集器
这种收集器将堆栈分为两个域，常称为半空间。每次仅使用一半的空间，jvm生成的新对象则放在另一半空间中。gc运行时，它把可到达对象复制到另一半空间，从而压缩了堆栈。这种方法适用于短生存期的对象，持续复制长生存期的对象则导致效率降低。
2.4.增量收集器
增量收集器把堆栈分为多个域，每次仅从一个域收集垃圾。这会造成较小的应用程序中断。
2.5.分代收集器
这种收集器把堆栈分为两个或多个域，用以存放不同寿命的对象。jvm生成的新对象一般放在其中的某个域中。过一段时间，继续存在的对象将获得使用期并转入更长寿命的域中。分代收集器对不同的域使用不同的算法以优化性能。
2.6.并发收集器
并发收集器与应用程序同时运行。这些收集器在某点上（比如压缩时）一般都不得不停止其他操作以完成特定的任务，但是因为其他应用程序可进行其他的后台操作，所以中断其他处理的实际时间大大降低。
2.7.并行收集器
并行收集器使用某种传统的算法并使用多线程并行的执行它们的工作。在多cpu机器上使用多线程技术可以显著的提高java应用程序的可扩展性。
3.Sun HotSpot 1.4.1 JVM堆大小的调整
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
如前所述，默认状态下HotSpot对新域使用复制收集器，对旧域使用标记－清除－压缩收集器。在新域中使用复制收集器有很多意义，因为应用程序生成的大部分对象是短寿命的。理想状态下，所有过渡对象在移出Eden空间时将被收集。如果能够这样的话，并且移出Eden空间的对象是长寿命的，那么理论上可以立即把它们移进旧域，避免在救助空间反复复制。但是，应用程序不能适合这种理想状态，因为它们有一小部分中长寿命的对象。最好是保持这些中长寿命的对象并放在新域中，因为复制小部分的对象总比压缩旧域廉价。为控制新域中对象的复制，可用-XX：TargetSurvivorRatio控制救助空间的比例（该值是设置救助空间的使用比例。如救助空间位1M，该值50表示可用500K）。该值是一个百分比，默认值是50.当较大的堆栈使用较低的sruvivorratio时，应增加该值到80至90，以更好利用救助空间。用-XX：maxtenuring threshold可控制上限。
为放置所有的复制全部发生以及希望对象从eden扩展到旧域，可以把MaxTenuring Threshold设置成0.设置完成后，实际上就不再使用救助空间了，因此应把SurvivorRatio设成最大值以最大化Eden空间，设置如下：
java & -XX：MaxTenuringThreshold=0 &XX：SurvivorRatio＝50000 &
4.BEA JRockit JVM的使用
Bea WebLogic 8.1使用的新的JVM用于Intel平台。在Bea安装完毕的目录下可以看到有一个类似于jrockit81sp1_141_03的文件夹。这就是Bea新JVM所在目录。不同于HotSpot把Java字节码编译成本地码，它预先编译成类。JRockit还提供了更细致的功能用以观察JVM的运行状态，主要是独立的GUI控制台（只能适用于使用Jrockit才能使用jrockit81sp1_141_03自带的console监控一些cpu及memory参数）或者WebLogic Server控制台。
Bea JRockit JVM支持4种垃圾收集器：
4.1.1.分代复制收集器
它与默认的分代收集器工作策略类似。对象在新域中分配，即JRockit文档中的nursery.这种收集器最适合单cpu机上小型堆操作。
4.1.2.单空间并发收集器
该收集器使用完整堆，并与背景线程共同工作。尽管这种收集器可以消除中断，但是收集器需花费较长的时间寻找死对象，而且处理应用程序时收集器经常运行。如果处理器不能应付应用程序产生的垃圾，它会中断应用程序并关闭收集。
分代并发收集器 这种收集器在护理域使用排它复制收集器，在旧域中则使用并发收集器。由于它比单空间共同发生收集器中断频繁，因此它需要较少的内存，应用程序的运行效率也较高，注意，过小的护理域可以导致大量的临时对象被扩展到旧域中。这会造成收集器超负荷运作，甚至采用排它性工作方式完成收集。
4.1.3.并行收集器
该收集器也停止其他进程的工作，但使用多线程以加速收集进程。尽管它比其他的收集器易于引起长时间的中断，但一般能更好的利用内存，程序效率也较高。
默认状态下，JRockit使用分代并发收集器。要改变收集器，可使用-Xgc：&gc_name&，对应四个收集器分别为gencopy，singlecon，gencon以及parallel.可使用-Xms和-Xmx设置堆的初始大小和最大值。要设置护理域，则使用-Xns：java &jrockit &Xms512m &Xmx512m &Xgc：gencon &Xns128m&尽管JRockit支持-verbose：gc开关，但它输出的信息会因收集器的不同而异。JRockit还支持memory、load和codegen的输出。
注意 ：如果 使用JRockit JVM的话还可以使用WLS自带的console（C：\bea\jrockit81sp1_141_03\bin下）来监控一些数据，如cpu，memery等。要想能构监控必须在启动服务时startWeblogic.cmd中加入－Xmanagement参数。
5.如何从JVM中获取信息来进行调整
-verbose.gc开关可显示gc的操作内容。打开它，可以显示最忙和最空闲收集行为发生的时间、收集前后的内存大小、收集需要的时间等。打开-xx：+ printgcdetails开关，可以详细了解gc中的变化。打开-XX： + PrintGCTimeStamps开关，可以了解这些垃圾收集发生的时间，自jvm启动以后以秒计量。最后，通过-xx： + PrintHeapAtGC开关了解堆的更详细的信息。为了了解新域的情况，可以通过-XX：=PrintTenuringDistribution开关了解获得使用期的对象权。
6.Pdm系统JVM调整
6.1.服务器：前提内存1G 单CPU
可通过如下参数进行调整：－server 启用服务器模式（如果CPU多，服务器机建议使用此项）
－Xms，－Xmx一般设为同样大小。 800m
－Xmn 是将NewSize与MaxNewSize设为一致。320m
－XX：PerSize 64m
－XX：NewSize 320m 此值设大可调大新对象区，减少Full GC次数
－XX：MaxNewSize 320m
－XX：NewRato NewSize设了可不设。4
－XX： SurvivorRatio 4
－XX：userParNewGC 可用来设置并行收集
－XX：ParallelGCThreads 可用来增加并行度 4
－XXUseParallelGC 设置后可以使用并行清除收集器
－XX：UseAdaptiveSizePolicy 与上面一个联合使用效果更好，利用它可以自动优化新域大小以及救助空间比值
6.2.客户机：通过在JNLP文件中设置参数来调整客户端JVM
JNLP中参数：initial-heap-size和max-heap-size
这可以在framework的RequestManager中生成JNLP文件时加入上述参数，但是这些值是要求根据客户机的硬件状态变化的（如客户机的内存大小等）。建议这两个参数值设为客户机可用内存的60％（有待测试）。为了在动态生成JNLP时以上两个参数值能够随客户机不同而不同，可靠虑获得客户机系统信息并将这些嵌到首页index.jsp中作为连接请求的参数。
在设置了上述参数后可以通过Visualgc 来观察垃圾回收的一些参数状态，再做相应的调整来改善性能。一般的标准是减少fullgc的次数，最好硬件支持使用并行垃圾回收（要求多CPU）。
阅读(...) 评论()5090人阅读
Weblogic/Websphere（14）
WebSphere优化的关键点&&因不同JDK而异。本文将描述IBM JDK下常用参数的设置。
-Xms：最小堆大小
-Xmx：最大堆大小
-Xminf and -Xmaxf：GC（垃圾回收）之后可用空间的最小值最大值
-Xmine and -Xmaxe：堆增长的最小最大值
-Xmint and -Xmaxt：垃圾回收占时间整个运行时间的比例，默认是5%。如果回收时间小于5%，那么它就缩减堆，反之增大。
一般来说只要对Xms和Xmx设置合理，后面的三对不用特别设置。可以看看上heap expasion和heap shrinkage两章的说明，除非有下文的情况：
如果使用大小可变的堆（比如，-Xms 和 -Xmx 不同），应用程序可能遇到这样的情况，不断出现分配失败而堆没有扩展。这就是堆失效，是由于堆的大小刚刚能够避免扩展但又不足以解决以后的分配失败而造成的。通常，垃圾收集周期释放的空间不仅可以满足当前的分配失败，而且还有很多可供以后的分配请求使用的空间。但是，如果堆处于失效状态，那么每个垃圾收集周期释放的空间刚刚能够满足当前的分配失败。结果，下一次分配请求时，又会进入垃圾收集周期，依此类推。大量生存时间很短的对象也可能造成这种现象。避免这种循环的一种办法是增加 -Xminf 和 -Xmaxf 的值。比方说，如果使用 -Xminf.5，堆将增长到至少有 50% 的自由空间。同样，增加 -Xmaxf 也是很合理。如果 -Xminf等于0.5，-Xmaxf 为默认值 0.6，因为 JVM 要把自由空间比例保持在 50% 和 60% 之间，所以就会出现太多的扩展和收缩。两者相差 0.3 是一个不错的选择，这样 -Xmaxf.8 可以很好地匹配 -Xminf.5。如果记录表明，需要多次扩展才能达到稳定的堆大小，但可以更改 -Xmine，根据应用程序的行为来设置扩展大小的最小值。目标是获得足够的可用空间，不仅能满足当前的请求，而且能满足以后的很多请求，从而避免过多的垃圾收集周期。-Xmine、-Xmaxf 和 -Xminf 为控制应用程序的内存使用特性提供了很大的灵活性。
摘自Java性能优化的策略和常见方法
所以在应用正式上线的头一段时间，最好把GC日志打开，观察一下堆（heap）的增长（expasion）和收缩（shrinkage）。最佳的情况就是，每次回收后可用的堆大小占整个堆的50%左右。如果回收后才腾出30%不到的可用空间，那就该再调整一下上述的参数了。下图看起来直观一点，使用-verbose:size参数可以查看当前的默认值。
那为何不把Xms和Xmx设置成一样大，就像SUN的JDK所推荐的那样？
Using the same values is not usually a good idea, because it delays the start of garbage collection until the heap is full. The first time that the Garbage Collector runs, therefore, becomes a very expensive operation. Also, the heap is more likely to be fragmented and require a heap compaction. Again this is a very expensive operation.&&
If the Garbage Collector cannot find enough garbage, it runs compaction. If the Garbage Collector finds enough garbage, or any of the other conditions for heap expansion are met , the Garbage Collector expands the heap.
因为IBM JDK采用的是标记（mark）-扫描（sweep）-标记-&&-扫描-紧凑排列（compact），如果还不能提供足够的空间，扩展堆（expasion）。依次循环，直到达到最大堆大小。每次扩展前，那些长存的对象就被调整到堆的底部，每次扩展后需要再动的量就很少。所以如果把Xms设置成和Xmx一样，那么扫描和紧凑排列这么一个充满内存碎片的大堆的开销将大大高于从小扩展堆的开销。
The overheads of expanding the heap are almost trivial compared to the cost of collecting and compacting a very large fragmented heap.
这是由于IBM的GC特点造成的，而SUN的JDK采用的是分代回收的策略，所以就没有这种情况，反而会受益于堆大小一致。不过这么说起来，用了-Xgcpolicy:gencon，就应该把最小堆最大堆设置成一样咯。
在Gencon回收策略下，可以通过-Xmn来设置婴儿区域（Nursery或者叫young）的大小，通过-Xmo来设置长存区（tenured或者old）的大小。注意-Xmn不能和-Xmns/-Xmnx参数一起使用，-Xmo不能和-Xmos/-Xmox一起使用，否则会报错。前者就是把年轻代和长存代的大小固定了，而后两者就是设定两个部分最大最小的范围，默认情况下：
-Xmns是-Xms的25%或者64M（在JDK 5.0中默认是25%）
-Xmnx是-Xmx的25%或者64M（同上）
-Xmos是-Xmx减去-Xmns的大小
-Xmox是和-Xmx一样大
可见默认的年轻代太小了，生产环境中有必要改大一点。因为年轻代使用的是复制策略，所以回收速度相当快（minor gc），而长存代使用的是和optavgpause 策略相似的方式进行并发标志、扫描策略，回收速度比较慢（major gc）。理想情况是minor gc和major gc的比值在1：1010：1左右。（可以通过GC日志查看回收的区域）
gencon中年老期限（Tenure age）和倾斜比率（Tilt ratio）这两个参数是JVM自己动态调整的。
针对固定对象问题（Pinned Objects），使用-Xk -Xp参数设定kCluster和pCluster， 或者我这篇。
一些不常用的参数：
-Xloainitial&percentage& -Xloamaximum&percentage& ：调整大对象区域（Large Object Area）的大小。分配总是先在SOA（Small Object Area）中分配，如果没有空间并且需要分配的大小大于64K，那么分配到LOA。默认情况下为-Xloainitial0.05 (5%)，-Xloamaximum0.5 (50%)，如果你的程序确实需要分配许多大对象的话（大于64K），那么可以调整LOA的初始百分比。
以上两点可以参考我这篇，获得更详细的解释。
总结一下来说，对于optthruput和optavgpause，设置恰当的最大堆和最小堆，设置-Xk和-Xp避免碎片问题，如果程序需要分配大对象较多，那么调整一下LOA的大小；对于gencon，可以调大最小堆和最大堆接近，调整young区域的大小，LOA也可以视情况调整。subpool一般用不到，就不去研究了。
一些另外的信息
Default settings for the JVM
JVM environment settings
默认的Heapdumps是关闭的，调试的时候记得打开；默认的Javadumps on out of memory和Heapdumps on out of memory都是开启的，但是默认的dump位置是profile的所在目录，最好在管理控制台java进程中把IBM_HEAPDUMPDIR和IBM_JAVACOREDIR设置到别的目录，防止dump内容把WAS的文件系统撑爆，影响正常业务使用。
在Windows机器上，如果内存大于4G，记得开启/3GB参数，这样可以使JVM Heap可以设置的更大一些，接近2G-1，（其它的三部分可以扩展到另外的1G上去），但一般最大不超过1.7G。
更详细内容，可见
或者下载dig60 查看JVM这一块
Sun的JDK配置，可以参考
本文转载自：
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：2732158次
积分：22310
积分：22310
排名：第328名
原创：131篇
转载：316篇
评论：835条
(1)(1)(2)(2)(1)(1)(2)(3)(6)(1)(1)(1)(2)(3)(6)(7)(2)(4)(3)(10)(6)(2)(1)(8)(4)(2)(4)(8)(2)(2)(7)(5)(8)(5)(4)(12)(20)(7)(5)(4)(3)(1)(6)(3)(8)(7)(2)(8)(1)(1)(20)(7)(6)(7)(10)(12)(8)(5)(3)(6)(2)(6)(2)(6)(6)(5)(6)(5)(5)(3)(3)(3)(6)(11)(4)(7)(5)(2)(8)(3)(2)(5)(4)(2)(15)(13)(10)
(window.slotbydup = window.slotbydup || []).push({
id: '4740881',
container: s,
size: '200,200',
display: 'inlay-fix'IBM Knowledge Center博客访问： 609550
博文数量： 254
博客积分： 10
博客等级： 民兵
技术积分： 3608
注册时间：
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： LINUX
以下摘自IBM信息中心：
每个 JVM 供应商都提供了有关其 JVM 性能和调整的详细信息。请将本主题中提供的信息与系统上运行的 JVM 附带提供的信息结合使用。
Java SE 运行时环境提供用于运行企业应用程序和应用程序服务器的环境。因此，Java 配置在确定应用程序服务器及其运行的应用程序的性能和系统资源使用方式方面扮演着重要的角色。
IBM Java 虚拟机 V6.0 包括 Java Platform Enterprise Edition (Java EE) 规范的最新内容，并且性能和稳定性都有所提高（与 Java 的先前版本相比）。
尽管 JVM 调整依赖于您所使用的 JVM 提供程序，但存在一些适用于所有 JVM 的一般调整概念。这些一般的概念包括：
编译器调整。在服务器运行时期间，所有 JVM 都使用即时 (JIT) 编译器来将 Java 字节码编译为本机指令。
Java 内存或堆调整。调整 JVM 内存管理功能（即垃圾回收）是提高 JVM 性能的良好开端。
类装入调整。
启动性能优化与运行时性能优化
以下步骤提供了有关如何对每个 JVM 执行下列类型的调整的特定指示信息。您不必按任何具体的顺序来执行这些步骤。
优化启动和运行时性能。
在某些环境（例如，开发环境）中，提高应用程序服务器的启动性能比提高运行时性能更重要。在另一些环境中，优化运行时性能更为重要。缺省情况下，IBM Java 虚拟机针对运行时性能进行优化，而基于 HotSpot 的 JVM 针对启动性能进行优化。
Java 即时 (JIT) 编译器会影响是否优化启动性能或运行时性能。编译器使用的初始优化级别影响编译类方法所需的时间以及启动服务器所需的时间。为了提高启动速度，请降低编译器所使用的初始优化级别。但是，如果降低初始优化级别，由于现在使用较低的优化级别来编译类方法，所以应用程序的运行时性能可能会下降。
-Xquickstart
此设置影响 IBM Java 虚拟机使用较低优化级别来编译类方法的方式。较低的优化级别将提高服务器启动速度，但会使运行时性能下降。如果未指定此参数，那么 IBM Java 虚拟机缺省使用高初始优化级别开始执行编译，这将提高运行时性能，但会减慢服务器启动速度。
可在 Java 虚拟机面板上使用管理控制台设置此属性。有关详细信息，请阅读有关 Java 虚拟机设置的信息。
高初始编译器优化级别
高初始编译器优化级别
指定&-Xquickstart&可缩短服务器启动时间。
配置堆大小。
Java 堆参数会影响垃圾回收行为。增加堆大小会支持更多对象创建。由于大的堆要用较长时间进行填充，所以在垃圾回收发生前应用程序会运行较长时间。但是，较大的堆也会用较长时间进行压缩，导致垃圾回收的时间也较长。
JVM 使用定义的阈值来管理分配给它的存储器。当达到阈值时，将会调用垃圾回收器以释放未使用的存储器。因此，垃圾回收会导致 Java 性能显著下降。在更改初始堆大小和最大堆大小之前，应考虑下列信息：
在大多数情况下，您应将最大 JVM 堆大小设置为比初始 JVM 堆大小更大的值。此设置允许 JVM 在正常的稳定状态期间能够在初始堆大小范围内高效地运行。此设置还允许 JVM 在事务高峰期也能够高效地运行，因为 JVM 可以将堆大小最多扩大至最大 JVM 堆大小指定的值。在某些需要绝佳性能的罕见情况下，您可能要对初始堆大小和最大堆大小指定相同的值。此设置消除了某些当 JVM 扩大或减小 JVM 堆大小时出现的开销。在更改任何 JVM 堆大小之前，请验证 JVM 存储器分配足够大，可以容纳新的堆大小。
不要使初始堆的大小太大，使得初次通过延迟垃圾回收来提高性能时，在垃圾回收进行期间，回收进程影响响应时间，因为该进程必须运行更长的时间。
要使用管理控制台来配置堆大小：
在管理控制台中，请单击服务器 & 服务器类型 & WebSphere 应用程序服务器 &&server_name。
在“服务器基础结构”部分中，单击Java 和进程管理 & 进程定义 & Java 虚拟机。
在初始堆大小或最大堆大小字段中指定新值。
如果需要同时调整这两项设置，也可以对这两个字段都指定值。
为进行性能分析，初始堆大小和最大堆大小应该相等。
“初始堆大小”设置指定 JVM 启动时分配给 JVM 堆的存储量（以兆字节为单位）。“最大堆大小”设置指定 JVM 启动时可分配给 JVM 堆的最大存储量（以兆字节为单位）。两种设置都对性能产生重大影响。
如果要调整某个生产系统但不知道在该系统上运行的企业应用程序工作集大小，那么初始堆大小的适宜启动值是最大堆大小的 25%。然后，JVM 尝试使堆大小适应应用程序的工作集大小。
以下插图表示三个 CPU 概要文件，每个概要文件都以不同 Java 堆设置运行固定工作负载。在中间的概要文件中，初始堆大小和最大堆大小都设置为 128 MB。发生四次垃圾回收。垃圾回收的总时间大约是运行总时间的 15%。当堆参数加倍为 256 MB 时（如在顶部的概要文件中所示），在两次垃圾回收之间的工作时间长度会增加。仅发生三次垃圾回收，但每次垃圾回收的工作时间长度也会增加。在第三个概要文件中，堆大小减少为 64 MB 而且会显示出相反的效果。使用较小的堆大小，两次垃圾回收之间的时间和每次垃圾回收的时间也会较短。 对于所有三种配置，垃圾回收的总时间大约是 15%。此示例说明有关 Java 堆及其与对象利用率的关系的重要概念。运行企业应用程序时，垃圾回收的开销始终存在。
运行一系列使用不同 Java 堆设置的测试。例如，运行使用 128 MB、192 MB、256 MB 和 320 MB 的试验。在每次实验期间，监视全部内存使用情况。如果您对堆扩展太多，那么可能发生页面调度。
使用&vmstat&命令或 Windows 性能监视器检查页面调度。如果发生页面调度，那么减少堆大小或将更多的内存添加到系统。
当所有运行都完成时，比较以下各统计信息：
垃圾回收调用次数
一次垃圾回收调用的平均持续时间
一次垃圾回收调用的工作时间长度和两次垃圾回收调用之间的平均时间之间的比率
如果应用程序不是过度使用的对象而且没有内存泄漏，那么达到了稳定内存利用率的状态。垃圾回收也不会频繁发生，而且持续时间短。
如果堆可用空间稳定在 85% 或更多，那么考虑降低堆大小的最大值，这是因为应用程序服务器和应用程序未充分利用为堆分配的内存。
单击应用。
单击保存以保存您对主配置所作的更改。
停止然后重新启动应用程序服务器。
还可使用下列命令行参数来调整这些设置。这些参数适用于所有受支持的 JVM，用于调整每个应用程序服务器或应用程序服务器实例的最小堆大小和最大堆大小。
此参数控制 Java 堆的初始大小。调整此参数有助于降低垃圾回收开销，从而缩短服务器响应时间并提高吞吐量。对于某些应用程序，此选项的缺省设置可能会太低，这将导致发生大量小型垃圾回收。
随工作负载的不同而有所变化，但高于缺省值。
指定&-Xms256m&会将初始堆大小设置为 256 MB。
此参数控制 Java 堆的最大大小。增大此参数将增加可供应用程序服务器使用的内存量，并且将降低垃圾回收频率。增大此设置可以缩短服务器响应时间并提高吞吐量。但是，增大此设置也将延长所执行的垃圾回收的持续时间。此设置不应大于可供应用程序服务器实例使用的系统内存量。如果将此设置增大到超出可用系统内存量，将导致发生系统页面调度，从而导致性能显著下降。
缺省情况下，JVM 会根据系统中的可用内存动态计算 Java 堆大小。
随工作负载的不同而有所变化，但高于缺省值，并取决于可用物理内存量。
指定&-Xmx512m&会将最大堆大小设置为 512 MB。
&避免故障：&对&-Xmx&参数指定值以减少可能的内存不足问题。
将此参数与 IBM Java 虚拟机配合使用以在使用大页（例如，16 MB 页）时分配该堆。在指定此参数之前，请验证操作系统是否配置为支持大页。使用大页可以降低 CPU 跟踪堆内存时的开销，并且还允许创建较大的堆。
64 KB，如果您在使用 Java 6 SR 7 或更高版本
4 KB，如果您在使用 Java 6 SR 6 或更低版本
可使用此参数来使用中等大小页（例如，64 KB）分配堆。由于硬件效率与页大小相关，因此，对应用程序所需的内存使用此虚拟内存页大小可以提高该应用程序的性能和吞吐量。
&i5/OS? 和 AIX? 提供了对 64 KB 页的强大支持，因为 64 KB 页旨在成为通用页。64 KB 页易于启用，并且应用程序在使用 64 KB 页时的性能也会有所提高。从 Java 6 SR 7 开始，缺省情况下 Java 堆是以 64K 页为单位分配的。对于 Java 6 SR 6 或之前版本，缺省设置为 4K 页。可更改此设置而不更改操作系统配置。但是，如果您使用 64KB 页，那么建议您在另一存储池中运行应用程序服务器。
&如果正在使用 Java 6 SR 6 或之前版本，要支持 64 KB 页大小，请在管理控制台中，单击服务器 & 应用程序服务器 &server_name&& 进程定义 & 环境条目 & 新建，然后在名称字段中指定&LDR_CNTRL，在值字段中指定DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K。
请尽可能地使用 64 KB 页。
&POWER5+ 系统和具有 5300-04 建议维护包的 AIX 5L? V5.3 在运行 64 位内核时支持 64 KB 页大小。
可通过此参数来使用 4 KB 页分配堆。对应用程序所需的内存使用此虚拟内存页大小（而不是 64 KB）可能会降低性能应用程序的性能和吞吐量，因为页大小较小会导致硬件的低效率。
&从 Java 6 SR 7 开始，缺省情况下 Java 堆是以 64K 页为单位分配的。对于 Java 6 SR 6 或之前版本，缺省设置为 4K 页。可更改此设置而不更改操作系统配置。但是，如果您使用 64KB 页，那么建议您在另一存储池中运行应用程序服务器。
&如果正在使用 Java 6 SR 7 或更高版本，要支持 4 KB 页大小，请在管理控制台中，单击服务器 & 应用程序服务器 &server_name&& 进程定义 & 环境条目 & 新建，然后在名称字段中指定&LDR_CNTRL，在值字段中指定DATAPSIZE=4K@TEXTPSIZE=4K@STACKPSIZE=4K。
请尽可能地使用 -Xlp64k 而不是 -Xlp4k。
调整 Java 内存。
用 Java 语言编写的企业应用程序涉及复杂对象关系，并使用大量对象。虽然 Java 语言会自动管理与对象生命周期关联的内存，但是了解对象的应用程序使用模式仍然重要。特别要验证以下条件是否存在：
应用程序不是过度使用的对象
应用程序不是泄漏对象
已正确设置 Java 堆参数以处理给定的对象使用模式
检查是否过度使用对象。
可以查看包括在 Tivoli? Performance Viewer 报告中的 JVM 运行时的计数器，以确定应用程序是否越载使用对象。必须指定&-XrunpmiJvmtiProfiler&命令行选项和 JVM 模块最大级别才能启用 Java 虚拟机概要分析程序接口 JVMTI 计数器。
垃圾回收之间的最佳平均时间至少是单次垃圾回收的平均持续时间的 5 到 6 倍。如果没有达到此数字，那么应用程序将多用 15% 的时间用于垃圾回收。
如果信息表明产生了垃圾回收瓶颈，那么有两种方法清除瓶颈。最划算的方法是优化应用程序以实现对象高速缓存和池。使用 Java 概要分析程序确定目标对象。如果您无法优化应用程序，请尝试添加内存、处理器和克隆。添加的内存允许每个克隆保持合理的堆大小。添加的处理器允许克隆并行运行。
测试内存泄漏。
在 Java 语言中，内存泄漏是造成垃圾回收瓶颈的一个危险因素。内存泄漏比内存过度使用更有破坏性，因为内存泄漏最终会导致系统不稳定。随着时间的过去，垃圾回收会发生得更加频繁，直到堆用尽，而且 Java 代码会失败并返回致命的“内存不足”异常。当未使用的对象具有不会被释放的引用时，会发生内存泄漏。内存泄漏通常发生在集合类（如 Hashtable）中，这是因为该表总是具有对对象的引用（甚至在删除实际的引用后）。
高工作负载总会引起应用程序在部署到生产环境后立即崩溃。如果应用程序有内存泄漏，那么高工作负载会加速放大此泄漏并导致发生内存分配故障。
进行内存泄漏测试的目标是扩大数字。根据无法进行垃圾回收的字节或千字节量评测内存泄漏。此精细任务将区别有用内存和不可用内存预期大小的量。如果扩大数字，使间隔更大、更易于标识不一致性，那么完成此任务会更简便。以下列表可让您了解如何解释内存泄漏测试结果：
长期运行测试
内存泄漏问题可能在一段时间后才会显现，因此，在长期运行测试期间易于找到内存泄漏。短时间运行的测试可能会提供内存泄漏位置的无效指示。有时很难知道 Java 语言中正在发生内存泄漏，尤其当在一段给定时间内，内存使用情况表面上突然地或单调地增加时。很难检测到内存泄漏的原因是由于这些种类的增加可能有效或可能是开发者的意图。您可以通过将应用程序运行一段较长的时间，来了解如何区分延迟使用的对象和完全未使用的对象。进行长期运行应用程序测试能帮助您更好地确定是否真的正在发生对象的延迟使用。
在很多情况下，内存泄漏问题通过同一测试用例的连续重复使用而发生。内存泄漏测试的目标是建立不能使用的内存和使用的内存（根据它们的相对大小）之间的大间隔。通过一次又一次地重复同一方案，渐进地增加间隔。如果由执行测试用例引起的泄漏数太小以至于很难在某次运行中明显地显示出来，那么进行此测试会有帮助。
您可以在系统级别或模块级别上使用重复测试。进行模块化测试的优点是较好控制。当模块设计为保持专用模块而不创建外部副作用（如内存使用情况）时，对内存泄漏进行测试较简便。首先，在运行模块前记录内存使用情况。然后，重复运行一组固定的测试用例。在测试运行结束时，为重大更改记录和检查当前内存使用情况。请记住，当通过将 System.gc() 插入到想要进行垃圾回收的模块中，或通过使用概要分析工具强迫事件发生来记录实际的内存使用情况时，必须建议使用垃圾回收。
并发性测试
某些内存泄漏问题可能只有当几个线程运行在应用程序中时才会发生。不幸地是，由于程序逻辑中添加了新出现的问题，导致同步点很容易受到内存泄漏的影响。编程粗心可能会导致保留或不释放引用。系统中增加的并发性通常会推动或促进内存泄漏事件。增加并发性最常见的方法就是增加测试驱动程序中的客户机数。
当选择用于进行内存泄漏测试的测试用例时，考虑以下各点：
好的测试用例会涉及创建对象的应用程序领域。大多数情况下，需要应用程序的知识。方案的描述可以建议创建数据空间，如添加新记录、创建 HTTP 会话、执行事务和搜索记录。
查看使用对象集合的区域。通常，内存泄漏由同一个类中的对象组成。同样，集合类（如 Vector 和 Hashtable）是通过调用相应的插入方法，隐式存储对对象的引用的通用位置。例如，Hashtable 对象的 get 方法不会移除其对已检索对象的引用。
可以使用 Tivoli Performance Viewer 来帮助查找内存泄漏。
为了取佳结果，请用递增的持续时间重复实验，如 1,000、2,000 和 4,000 页请求。已用内存的 Tivoli Performance Viewer 图应该具有锯齿形状。图上的每个下落对应于垃圾回收。如果图形中发生以下某种情况，那么存在内存泄漏：
每次垃圾回收后立即使用的内存量显著增加。当发生此情况时，锯齿模式更象楼梯。
锯齿模式具有不规则的形状。
已分配的对象数与已释放的对象数之间的豁口随着时间的推移而增大。
如果堆消耗在应用程序服务器的 CPU 利用率一直接近 100% 期间指示可能的内存泄漏，但是在工作负载较轻或接近空闲时消失，那么表示存在堆碎片。当 JVM 可以在垃圾回收循环期间释放足够的对象以满足内存分配请求时会产生堆碎片，但 JVM 没有时间将堆中小的空闲内存区域压缩到较大的邻近空间。
当释放小于 512 个字节的对象时，会产生另一种形式的堆碎片。会释放对象，但不会恢复存储器，导致产生内存碎片直到执行堆压缩为止。
通过强制执行压缩，可以减少堆碎片。但是，强制执行压缩会降低性能。使用 Java&-X&命令来查看内存选项列表。
调整垃圾回收
检查 Java 垃圾回收可了解应用程序将如何利用内存。垃圾回收是 Java 的特质。通过从应用程序写程序中移除内存管理负担，Java 应用程序比使用不提供垃圾回收的语言编写的应用程序更可靠。只要应用程序不滥用对象，就可以保持此可靠性。垃圾回收通常占用正常运行的应用程序总运行时间的 5% 到 20%。如果不进行管理，那么垃圾回收会是应用程序的一个最大的瓶颈。
如果在固定工作负载正在运行时监视垃圾回收，那么可让您了解应用程序是否越载使用对象。垃圾回收甚至可以检测到是否存在内存泄漏。
可以使用 JVM 设置来配置垃圾回收的类型和行为。当 JVM 由于连续空间不足而无法从当前堆中分配对象时，将调用垃圾回收器从不再使用的 Java 对象中回收内存。每个 JVM 供应商都提供了独特的垃圾回收器策略和调整参数。
可在管理控制台中使用冗余垃圾回收设置来启用垃圾回收监视。此设置的输出包括类垃圾回收统计信息。生成的报告的格式在不同的 JVM 之间或发行级别之间并无一定标准。
要调整 JVM 垃圾回收设置：
在管理控制台中，请单击服务器 & 服务器类型 & WebSphere 应用程序服务器 &&server_name。
在“服务器基础结构”部分中，单击Java 和进程管理 & 进程定义 & Java 虚拟机
在通用 JVM 参数字段中输入要更改的&–X&选项。
单击应用。
单击保存以保存您对主配置所作的更改。
停止然后重新启动应用程序服务器。
以下列表描述不同 JVM 垃圾回收器的&–X&选项。
用于 Java 垃圾回收程序的 IBM 虚拟机。
IBM Developer Kit and Runtime Environment, Java2 Technology Edition, Version 5.0 Diagnostics Guide&中提供了 Java 垃圾回收器的 IBM 实现的完整指南。此文档可以从 developerWorks? Web 站点获得。
使用 Java&-X&选项来查看内存选项列表。
-Xgcpolicy
IBM Java 虚拟机提供了四种垃圾回收策略。每种策略都有独特的优点。
注：&虽然每个策略都有独特优点，但对于 WebSphere Application Server V8.0 及更高版本，gencon 是缺省垃圾回收策略。应用程序服务器的先前版本指定 optthruput 作为缺省垃圾回收策略。
gencon 是缺省策略。此策略与分代垃圾回收器配合使用。分代模式尝试实现高吞吐量并同时缩短垃圾回收暂停时间。为了实现此目标，将堆分为新区域和旧区域。长生命周期对象将被提升到旧空间，而短生命周期对象将在新空间中被迅速地作为垃圾回收。gencon 策略能使许多应用程序受益匪浅。但是，它并不适合所有应用程序，并且通常难以调整。
optthruput 提供高吞吐量，但垃圾回收暂停时间较长。在垃圾回收期间，将停止所有应用程序线程，以便进行标记、清理并根据需要进行压缩。gencon 策略对于大部分应用程序而言已经够用了。
optavgpause 策略通过在应用程序运行期间执行垃圾回收的标记和清理阶段来缩短垃圾回收暂停时间。此策略会对整体吞吐量产生轻微的性能影响。
subpool 策略可以提高多处理器系统（通常使用 8 个以上处理器）的性能。此策略仅适用于 IBM System i? System p? 和 System z? 处理器。subpool 策略与 gencon 策略类似，只是它将堆划分为子池以提高对象分配可伸缩性。
指定&Xgcpolicy:gencon&会将垃圾回收策略设置为 gencon。
将&gcpolicy&设置为&gencon&会禁用并发标记。除非应用程序响应时间不规律（这表示可能存在暂停时间问题），否则，使用 gencon 策略应可获得最佳的吞吐量结果。
将&gcpolicy&设置为&optavgpause&会使用缺省值来启用并发标记。此设置将减少由正常垃圾回收所引起的应用程序响应时间不规律情况。但是，此选项可能会降低整体吞吐量。
-Xnoclassgc
缺省情况下，当一个类没有任何活动实例时，JVM 就会从内存中卸装该类。多次装入和卸装同一个类的开销会降低性能。
&避免故障：&可以使用&-Xnoclassgc&参数来禁用类垃圾回收。但是，类垃圾回收的性能影响通常很小，在基于 Java Platform, Enterprise Edition (Java EE) 的系统（该系统大量使用应用程序类装入器）中关闭类垃圾回收可能会在事实上造成类数据的内存泄漏并导致 JVM 抛出内存不足异常。
如果使用此选项，那么每当重新部署应用程序时，都必须重新启动应用程序服务器，以清除来自应用程序的先前版本的类和静态数据。
启用类垃圾回收。
不要禁用类垃圾回收。
指定&Xnoclassgc&以禁用类垃圾回收。
启用本地主机名称高速缓存
缺省情况下，在 IBM SDK for Java 中，静态方法 java/net/InetAddress.getLocalHost 不会高速缓存其结果。系统在整个 WebSphere Application Server 中使用此方法，但尤其会在 Deployment Manager 和 Node Agent 之类的管理代理程序中使用。如果进程的本地主机地址在进程运行期间不会更改，那么建议通过将 com.ibm.cacheLocalHost 系统属性的值设置为 true 以使用内置高速缓存查找本地主机。有关在各种类型的进程上设置 JVM 定制属性的指示信息，请参阅信息中心中的“Java 虚拟机定制属性”主题。
&避免故障：&使用 DHCP 配置的服务器地址随时间推移而更改。除非为服务器使用静态分配的 IP 地址，否则请勿设置此属性。
com.ibm.cacheLocalHost =&false
com.ibm.cacheLocalHost =&true（请参阅描述）
指定&-Dcom.ibm.cacheLocalHost=true&会启用 getLocalHost 高速缓存
在高速缓存中启用类共享。
Java 2 运行时环境 (J2RE) V1.5.0 的 IBM 实现的共享类选项允许在高速缓存中共享类。通过在高速缓存中共享类，可以缩短启动时间并减少内存使用量。进程（例如应用程序服务器、Node Agent 和 Deployment Manager）可以使用共享类选项。
&&避免故障：&在下列平台上，当前不支持 J2RE V1.5.0 的 IBM 实现：
如果使用此选项，那么应该在进程不在使用中时清除高速缓存。要清除高速缓存，请调用&app_server_root/bin/clearClassCache.bat/sh&实用程序，也可以先停止该进程，然后重新启动它。
如果需要对某个进程禁用共享类选项，请对该进程指定通用 JVM 参数 -Xshareclasses:none：
在管理控制台中，请单击服务器 & 服务器类型 & WebSphere 应用程序服务器 &&server_name。
在“服务器基础结构”部分中，单击Java 和进程管理 & 进程定义 & Java 虚拟机
在通用 JVM 参数字段中输入&-Xshareclasses:none。
单击确定。
单击保存以保存您对主配置所作的更改。
停止然后重新启动应用程序服务器。
启用“在高速缓存中共享类”选项。
保留“在高速缓存中共享类”选项处于启用状态。
指定&-Xshareclasses:none&会禁用“在高速缓存中共享类”选项。
在 64 位环境上启用压缩引用。
可在 64 位环境（例如，AIX 64、Linux PPC 64、zLinux 64、Microsoft Windows AMD64 和 Linux AMD64）上启用压缩引用。
64 位 Java SE 运行时环境 (JRE) V6.0 的 IBM 实现的压缩引用选项可让您将所有内存引用限制为 32 位大小。与 32 位 JVM 相比，64 位 JVM 通常使用更多堆空间，因为它们使用 64 位内存引用来对内存进行寻址。可通过 64 位引用寻址的堆比 32 位的堆大几个数量级，但在现实生活中，通常不需要使用必须所有 64 位来进行寻址的堆。压缩引用可减少地址的大小并提高堆的使用效率。压缩这些引用还可以提高处理器高速缓存和总线利用率，从而提高性能。
&避免故障：&
在以下 JVM 上不支持压缩引用功能：
HP-UX 64 位 JVM
iSeries? 传统 64 位 JVM
缺省情况下，如果堆大小（由 -Xmx 参数控制）设置为在特定堆大小之下（约为 25 GB，具体视平台而定），那么在受支持的平台上产品会自动启用指针压缩，否则会缺省为非压缩引用。用户可以使用下面的命令行选项来覆盖这些缺省值。
以下命令行选项控制压缩引用功能：
-Xcompressedrefs
此命令行选项启用压缩引用功能。使用此命令行选项启动 JVM 时，它将使用 32 位宽内存引用来对堆进行寻址。此功能最多可以使用特定堆大小（约 29GB，具体视平台而定），由 -Xmx 参数控制。
-Xnocompressedrefs
此命令行选项显式禁用压缩引用功能。使用此命令行选项启动 JVM 时，它将使用 64 位宽内存引用来对堆进行寻址。如果需要，用户可使用此选项来覆盖指针压缩的缺省启用。
调整大型单元配置的配置更新进程。
在大单元配置中，您可能必须确定是配置更新性能还是配置一致性检查更重要。Deployment Manager 为整个单元维护一个主配置存储库。缺省情况下，当该配置更改时，产品会将工作空间中的配置与主存储库进行比较以保持工作空间的一致性。然而，一致性验证过程会导致增加保存配置更改或部署大量应用程序所需的时间。以下因素影响所需的时间：
单元中定义的应用程序服务器或集群越多，保存配置更改所需的时间越长。
单元中部署的应用程序服务器越多，保存配置更改所需的时间越长。
如果您对更改配置所需的时间量不满意，那么可以将&config_consistency_check&定制属性添加到 JVM 设置中并将此属性的值设置为 false。
在管理控制台中，单击系统管理 & Deployment manager。
在“服务器基础结构”下，选择“Java 和进程管理”，然后单击进程定义。
在“其他属性”下，单击&Java 虚拟机 & 定制属性 & 新建。
在“名称”字段中输入&config_consistency_check，在“值”字段中输入&false。
单击确定，然后将这些更改保存到主配置。
重新启动服务器。
&支持的配置：&config_consistency_check&定制属性仅影响 Deployment Manager 进程。它不会影响其他进程，包括 Node Agent 进程和应用程序服务器进程。不会对这些进程执行一致性检查。然而，在这些进程的&SystemOut.log&文件中，您可能会看到一个表示禁用了一致性检查的注释。对于非 Deployment Manager 的进程，您可以忽略此消息。
如果要以本地方式使用 wsadmin 命令&wsadmin -conntype none，那么在发出此命令之前，必须将&config_consistency_check&属性设置为false。
阅读(3479) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。