您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
基于JVM的异常诊断和性能调优.docx19页
本文档一共被下载：
次 ,您可免费全文在线阅读后下载本文档
文档加载中...广告还剩秒
需要金币：100 &&
你可能关注的文档：
··········
··········
基于JVM的异常诊断和性能调优一、JVM GC 原理介绍:
以前我作为java 开发人员，用的都是sun 的JVM （这也是当今最好用的虚拟机），由于垃圾收集的工作都是交给JVM 做，只要编码的时候注意不要在静态的集合对象中只添加对象，而不删除对象的情况发生，就可以避免内存泄漏，所以自己从没有认真考虑过要将GC 好好学习一下；然而实际的工作表明，不深入的学习GC 的原理，很难解决生产中的问题。
学习开始从理解JVM 的GC 工作原理入手。垃圾收集的过程主要分三个步骤：标记（mark ），清除（sweep ），整理（compact ）。标记过程就是看看在JVM 堆中有哪些对象还有用，哪些对象不用了，有用的对象就作个标记，不用的对象就不作标记；对未作标记的对象（即不用的对象）就作第二步清除；当清除完以后，由于有用的对象此时是分散的分布在JVM 堆中，JVM 堆就会有许多堆碎片，因而需要做第三步整理；整理（也有人翻译成“压缩”，实际上最准确的翻译是“使紧凑”）就是将散放在JVM 堆中的有用对象移动到堆底部，削除堆碎片。 然而，原理虽然简单，可各个厂商在对GC 的具体实现上却有区别，从而导致相同的应用，在不同的JVM 上会出现不同问题。现在我们主要看看IBM JVM GC 和SUN JVM GC 的实现方式和行为。 java 与C/C++ 在内存泄露上定义不同，java 上内存泄露是说持有了不该再持有的对象 一）．SUN 的JVM 介绍 SUN 的JVM 采用分代垃圾收集 （generational garbage collection ）的方式，从JDK1.4.1 开始，它将JVM 堆栈分成三个部分：年轻代（young generation ）、年老代（old/tenured generation ）和持久代（permanent generation ）。关于分代垃圾收集的详细介绍请查阅参考文献（ [25] 、[26]）。 持久代用于存储装载的类、方法对象（C
正在加载中，请稍后...Linux平台的JVM性能评测 - Linux - Tech - ITeye论坛
Linux平台的JVM性能评测
锁定老帖子
该帖已经被评为精华帖
等级: 资深会员
文章: 6209
积分: 3125
来自: 上海
发表时间：&&
相关知识库：
最近准备用jroller来架设网站的Blog系统，因此我这几天研究了一下三个最主流的JVM，分别是Sun的Hotspot JVM，IBM的JVM和BEA的JRockit，并且做了一些性能方面的测试，所以向大家介绍一下。
在Linux平台上，Sun的Hotspot性能很一般，不如同样环境下Windows下的Hotspot表现好；
IBM的JVM无论在Linux还是Windows平台性能很卓越，不过IBM主要还是把精力放在Linux/Unix平台上，它的Windows平台的JVM到1.3.1性能口碑很好，但是以后就没有再单独发布新版本，因此从IBM网站也只能下载到Windows下1.3.1版本JVM，至于Linux平台下的1.4.1版本的JVM性能表现尚待检验；
而BEA的JRockit针对Intel 的CPU进行了指令优化，作为服务器的JVM来说在业界似乎一向评价颇好，但是我还不清楚JRockit在Linux上表现如何。这次我是要在SuSE Linux上跑jroller，因此主要关注3个JVM在我的SuSE 9上面的性能表现。
因为要作为网站服务器来使用，因此我还比较关注JRockit和IBM JVM的License问题，分别查了一下BEA和IBM的协议，看到这两个JVM都是可以免费使用，不管是开发目的，还是产品目的，如果是购买了其公司其他产品，那么可以得到免费的JVM方面的support，如果只是从网站下载使用其JVM，那么就没有免费的support，但是有商业付费的support。
在TSS上面有一个关于JRockit的Thread：
/news/thread.tss?thread_id=22895
Cameron Purdy对于3个JVM的评价如下：
引用Every application is different, so there is no single "best JVM." These JVMs only compete on the x86 platform anyway, and they perform differently on Windows and Linux. The IBM JVM has been much faster at math (all number processing it seems) compared to the Sun JVM. The jRockit JVM has been much better at handling large numbers of threads and sockets. The Sun JVM has been the fastest at general business logic running in server mode, but there used to be stability issues with the hotspot server mode that prevented its use for many server applications.
To be honest, with the above exception noted, we've seen the most stability and least weird behavior with the Sun JVMs. I haven't had a chance to look at the latest BEA release, though, and it's probably the one that's been improving the fastest.
他认为：
IBM JVM处理数学运算速度最快，BEA JVM处理大量线程和网络socket性能最好，而Sun JVM处理通常的商业逻辑性能最好。不过Hotspot的Server mode被报告有稳定性的问题。而他尚未有机会尝试一下最新的JRockit。
架设Blog系统我最关心的其实还是JVM的多线程处理能力和网络socket处理能力，因此使用著名的VolanoMark Benchmark进行了这方面的测试
VolanoMark Benchmark是一个JVM性能测试程序，任何人都可以自己下载来测试：
/benchmarks.html
这是2003年5月的测试报告
我下载了VolanoMark Benchmark，在Server上面分别安装了Linux版本的JRockit1.4.2，Sun JDK1.4.2，和IBM JDK1.4.1。修改了一下VolanoMark的测试脚本(有些小问题)。VolanoMark测试主要是运行Volano自己开发的一个chat的web application，然后从客户端进行压力测试，统计web application单位时间内处理并发请求的能力。测试主要有两项：
1、Loopback测试
不进行网络传输测试，因此可以测试出来JVM的performance
2、 Network测试
通过网络进行测试，模拟真实环境的JVM处理能力。
服务器软硬件环境：
服务器CPU：超线程1.8Gz Xeon CPU × 2
操作系统：SuSE Linux9.0 Professional
Linux Kernel版本：2.4.21-202-smp4G
Glibc版本：glibc-2.3.2-88
Volano使用的是Tomcat4.0.3来做App Server。这也符合我的选择，我正准备使用Tomcat来做App Server。每个测试分别执行三次，测试结果如下：
1、性能测试（Loopback）
Performance
VolanoMark version = 2.5.0.9
Messages sent&&&&& = 20000
Messages received& = 380000
Total messages&&&& = 400000
Sun JDK1.4.2
Average throughput = 8848 messages per second
Average throughput = 8060 messages per second
Average throughput = 8046 messages per second
IBM JDK1.4.1
Average throughput = 15620 messages per second
Average throughput = 17665 messages per second
Average throughput = 15666 messages per second
BEA JRockit1.4.2
Average throughput = 16549 messages per second
Average throughput = 15564 messages per second
Average throughput = 15736 messages per second
2、网络服务处理能力测试
VolanoMark version = 2.5.0.9
Messages sent&&&&& = 10000
Messages received& = 190000
Total messages&&&& = 200000
BEA JRockit1.4.2
Average throughput = 3938 messages per second
Average throughput = 3290 messages per second
Average throughput = 3648 messages per second
Average throughput = 3328 messages per second
Sun JDK1.4.2
Average throughput = 2225 messages per second
Average throughput = 2163 messages per second
Average throughput = 2080 messages per second
IBM JDK无法执行测试
测试总结：
在第一项性能测试中，3个JVM都完成测试，但是正如上面Purdy提到的一样，Sun的Hotspot JVM在server mode情况下会出错，必须使用cliet mode。在性能测试结果来看，IBM的JVM和BEA的JVM旗鼓相当，分值都相当高，而Sun的JVM性能差了几乎一倍。
在第二项网络服务测试中，IBM的JVM无法完成测试，会出现段地址错误，JDK版本和glibc版本不兼容造成的。Sun的JVM也需要修改一下JVM参数才可以顺利执行，从测试结果来看，BEA的JRockit仍然遥遥领先于Sun的Hotspot。
经过本次测试，已经决出了优胜者，就是BEA的JRockit1.4.2。当然JRockit也有一些不足，例如在内存消耗和CPU负载方面要明显高于另外两个JVM。
JRockit除了性能上的优势，也有着丰富的性能调整选项和一个图形监控工具，和一个性能报告分析工具，这对于JVM的调优有着非常大的帮助，鉴于性能方面的优势，以及可管理性方面的丰富功能，我决定选择JRockit作为Tomcat的JVM来使用。
BEA网站也有丰富的JRockit方面的资料查阅：
/wljrockit/docs142/index.html
下面是JRockit的management Console，可以远程链接到服务器的JVM上进行性能监控。
来自: 广州
发表时间：&&
我们也做过类似的测试，Weblogic Server 8.1 cluster on RedHat Linux，用真实的业务系统进行压力测试，BEA JRockit 比 Sun Hotspot的处理能力要高出一倍以上（不到两倍）。
说起来在一年多前刚刚知道blog的时候，因为对java的偏爱遍寻基于java的blog系统，结果找到了roller。为了解决它的中文问题逼着学习了Structs和Velocity，最后还是要自己写一个servlet filter来解决中文输入问题，我还到他的网站上去抱怨了。虽然拖了将近一年才真正开始自己的blog，不过对roller的学习还是让我受益不浅，可惜的是那时没有去关心它的O/R Mapping这一部分。
请登录后投票
文章: 1729
积分: 9849
来自: 上海
发表时间：&&
出于性能上的考虑，我们一直用的是 IBM 的 JVM。Web Container 我们使用 Jetty 4.2.x，JRockit 启动 Jetty 的速度比 IBM JVM 慢多了。而且 JRockit 好象专门为很少的几种 Linux 版本作过优化（RHAD2.1、RHEL3?、SuSe???），在其它版本上跑不知道能否达到最佳的性能。
这几个 JVM（JRE/JDK）的 License 我以前都看过，好象是除了 Sun 的 JRE（非 JDK）可以和自己的产品打包销售外其余的所有的 JRE/JDK 用于商业用途全部是要收费的（当然可以让用户自己下载安装以绕过这个限制，但是只要是由开发商提供就是要收费的），回头再看看。
请登录后投票
等级: 资深会员
文章: 6209
积分: 3125
来自: 上海
发表时间：&&
既然是做网络服务，那么启动速度快几秒和慢几秒有什么关系呢？WebLogic的启动速度比Jetty慢多了，但是不能因此认为WebLogic不如Jetty。
IBM的JDK我很早以前从IBM网站下载了JDK1.4.1版本，都快过去1年多了，IBM网站还是1.4.1版本，不过已经发布到1.4.1SR2，但是我现在下载不下来，不知道为什么。而我现在手里的1.4.1显然和SuSE 9的Glibc不兼容，不知道SR2有没有修改过来。
总体评价下来，我感觉IBM现在在JVM上投入热情不高，JDK1.4.1都发布了一年多了，还不升级到1.4.2。而Windows下的JDK干脆就是1.3.1，就不升级了。相比BEA的JRockit活跃的升级和开发，我已经完全倒向了JRockit了。
JRockit是针对Intel CPU进行了指令优化，因此JRockit只能用在Intel CPU上，可以跑在Windows和Linux上面，而其他软硬件平台就不支持了。在JRockit的兼容性列表中并没有SuSE9，只有SLSE8，不过我现在跑下来，感觉很好用，没有发现任何兼容性问题。其实只要JDK版本发布的比你的Linux的Glibc版本新，一般就不会出现任何问题。例如IBMJDK1.4.1和JRockit1.4.1发布都比SuSE9老，我分别发现了一些小毛病，JRockit1.4.1的Console在Linux上启动有问题，但是JRockit1.4.2就完全正常了。
我这次测试IBM JDK由于glibc的兼容性问题无法把测试跑完令我觉得很遗憾，没有比较出来IBM和BEA的JVM性能高下。但是从开发的活跃程度和丰富的管理功能来看，BEA全面胜出。
请登录后投票
等级: 资深会员
文章: 6209
积分: 3125
来自: 上海
发表时间：&&
引用JRockit is free to anyone deploying any Java code, whether that's WebLogic Server or not. Technical support is free to WebLogic Server users and can be purchased by anyone deploying anything else on it.
BEA Systems
上面明确的说出来，对于任何部署Java的人来说，JRockit都是免费的。
请登录后投票
等级: 资深会员
文章: 6209
积分: 3125
来自: 上海
发表时间：&&
另外听BEA的人说，JRockit在Thread方面进行了特别的优化，在SMP上面性能尤其的好。现在的Server是两颗超线程Xeon，模拟出来4颗CPU，JRockit能够表现这么好，可能也和这台Server是SMP有关系。这也反过来可以引出来一个测试，在单CPU上，JRockit的性能可以胜出Hotspot多少，而SMP可以胜出来多少，如果SMP上，JRockit更有优势的话，那么说明在SMP的Server条件下，我们更有理由采用JRockit。
请登录后投票
文章: 1729
积分: 9849
来自: 上海
发表时间：&&
引用JRockit is free to anyone deploying any Java code, whether that's WebLogic Server or not. Technical support is free to WebLogic Server users and can be purchased by anyone deploying anything else on it.
Eric
BEA Systems
这个 deploy 和我说的 distribute 不是一回事。如果开发商把 JRockit 提供给客户就构成了 distribute，这两个概念是不同的。客户自己下载用来 deploy Java 程序是没有问题的。
不过在国内基本上没有人考虑过这个问题。这样做其实已经比 Quake Wang 以前说的那些把开源软件改头换面自称具有自主知识产权的鸟公司强的多了。
请登录后投票
发表时间：&&
感谢 robbin 分享测试结果。
不知道有谁测过 jetty-4.2.20, jakarta-tomcat-4.1.30, Tomcat 5.0.25,& resin 3.08 的jsp性能?
请登录后投票
等级: 资深会员
文章: 6209
积分: 3125
来自: 上海
发表时间：&&
Jetty和Tomcat用的都是Jasper，性能应该差不了太多，但是Jetty比较轻巧，应该速度快一些。Resin号称最快的Java App Server，应该比Jetty，Tomcat都要快。
请登录后投票
等级: 资深会员
文章: 6209
积分: 3125
来自: 上海
发表时间：&&
时隔快半年了，服务器还是这台，但是Linux Kernel已经从2.4升级到2.6。因此我又重新测试和比较了一下BEA JRockit1.4.2和Sun Hostspot1.4.2在Kernel2.6下的表现如何。听闻Kernel2.6使用了NPTL，对于多线程Java应用性能有巨大的提高，是否如此呢？我们来看看测试结果：
1、性能测试（Loopback）
Performance
VolanoMark version = 2.5.0.9
Messages sent = 20000
Messages received = 380000
Total messages = 400000
Sun Hospot 1.4.2
Average throughput = 13701 messages per second
Average throughput = 14430 messages per second
Average throughput = 14466 messages per second
BEA JRocket 1.4.2
Average throughput = 19775 messages per second
Average throughput = 19310 messages per second
Average throughput = 18212 messages per second
和上文在Kernel2.4下面的测试成绩相比，性能的提高是惊人的，Sun Hotspot性能提高将近一倍！BEA JRocket性能提高也相当可观。
2、网络服务处理能力测试
VolanoMark version = 2.5.0.9
Messages sent = 10000
Messages received = 190000
Total messages = 200000
Sun Hospot 1.4.2
Average throughput = 9784 messages per second
Average throughput = 9972 messages per second
Average throughput = 10886 messages per second
此项测试中，BEA JRockit与Kernel2.6有些不兼容，导致测试无法正常完成。
从Sun Hotspot的网络服务测试比较可以看出，在Kernel2.6下面，Sun Hotspot的网络性能提高竟然有5倍之多，非常惊人！
Kernel2.6确实名不虚传，无论在性能测试，还是网络服务测试中，Sun Hotspot的性能提高都是非常惊人的！BEA JRockit提高也很显著。
请登录后投票
跳转论坛:移动开发技术
Web前端技术
Java企业应用
编程语言技术Java version = 1.6.0, Java Compiler = j9jit24, Java VM name = IBM J9 VM
native_stderr.log
&cycle-start id=&1743& type=&scavenge& contextid=&0& timestamp=&T18:58:48.315& intervalms=&& /&
&gc-start id=&1744& type=&scavenge& contextid=&1743& timestamp=&T18:58:48.315&&
&mem-info id=&1745& free=&& total=&& percent=&7&&
&mem type=&nursery& free=&& total=&& percent=&3& /&
&mem type=&tenure& free=&& total=&& percent=&10&&
&mem type=&soa& free=&& total=&& percent=&10& /&
&mem type=&loa& free=&0& total=&0& percent=&0& /&
&remembered-set count=&33378& /&
&/mem-info&
&/gc-start&
&allocation-stats totalBytes=&& &
&allocated-bytes non-tlh=&4935632& tlh=&& /&
&largest-consumer threadName=&WorkManager.HeartBeat_Ref : 2& threadId=&7B00& bytes=&8321520& /&
&/allocation-stats&
&gc-op id=&1746& type=&scavenge& timems=&& contextid=&1743& timestamp=&T18:58:55.864&&
&scavenger-info tenureage=&2& tiltratio=&76& /&
&memory-copied type=&nursery& objects=&& bytes=&& bytesdiscarded=&89488& /&
&memory-copied type=&tenure& objects=&5672186& bytes=&& bytesdiscarded=&46024& /&
&copy-failed type=&nursery& objects=&443560& bytes=&& /&
&copy-failed type=&tenure& objects=&2948224& bytes=&& /&
&warning details=&aborted collection due to insufficient free space& /&
&gc-end id=&1747& type=&scavenge& contextid=&1743& durationms=&& timestamp=&T18:58:55.864&&
&mem-info id=&1748& free=&& total=&& percent=&1&&
&mem type=&nursery& free=&& total=&& percent=&3& /&
&mem type=&tenure& free=&0& total=&& percent=&0&&
&mem type=&soa& free=&0& total=&& percent=&0& /&
&mem type=&loa& free=&0& total=&0& percent=&0& /&
&remembered-set count=&33378& /&
&/mem-info&
&cycle-end id=&1749& type=&scavenge& contextid=&1743& timestamp=&T18:58:55.864& /&
本文将描述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，Avoiding Java heap fragmentation with Java SDK V1.4.2. 或者我这篇IBM JDK的Java堆空间的碎片问题。
一些不常用的参数：
　　-Xloainitial&percentage& -Xloamaximum&percentage& ：调整大对象区域（Large Object Area）的大小。分配总是先在SOA（Small Object Area）中分配，如果没有空间并且需要分配的大小大于64K，那么分配到LOA。默认情况下为-Xloainitial0.05 (5%)，-Xloamaximum0.5 (50%)，如果你的程序确实需要分配许多大对象的话（大于64K），那么可以调整LOA的初始百分比。
　　以上两点可以参考我这篇IBM JDK的Java堆空间的碎片问题，获得更详细的解释。
　　总结一下来说，对于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。
相关 [java 性能 优化] 推荐：
- Java - 编程语言 - ITeye博客
转自：/blog/2199633. jvm
垃圾回收 . JVM是JAVA世界的核心，了解它有助于我们更好调试，调优和开发程序，最近散仙在看JAVA特种兵一书，看完觉得，作者写的内容还是挺不错，大家感兴趣的，也可以购买本温故而知新下.
- 博客 - 伯乐在线
IBM developerworks. 简介： 本文介绍如何提升 Java Web 服务性能，主要介绍了三种方法：一是采用 Web 服务的异步调用，二是引入 Web 服务批处理模式，三是压缩 SOAP 消息. 重点介绍在编程过程中如何使用异步 Web 服务以及异步调用和同步调用的差异点. 本文还示范了如何在项目中使用以上三种方法，以及各种方法所适合的应用场景.
- 编程语言 - ITeye博客
本文将描述IBM JDK下常用参数的设置. 　　-Xms：最小堆大小. 　　-Xmx：最大堆大小. 　　-Xminf and -Xmaxf：GC（垃圾回收）之后可用空间的最小值最大值. 　　-Xmine and -Xmaxe：堆增长的最小最大值. 　　-Xmint and -Xmaxt：垃圾回收占时间整个运行时间的比例，默认是5%.
- ImportNew
你是否正打算优化hashCode()方法. Lukas Eder介绍了很多简单方便的性能优化小贴士以及扩展程序性能的技巧. 最近“全网域（
Web Scale）”一词被炒得火热，人们也正在通过扩展他们的应用程序架构来使他们的系统变得更加“全网域”. 全网域被炒作的最多的是扩展负载（Scaling load），比如支持单个用户访问的系统也可以支持10 个、100个、甚至100万个用户访问.
- CSDN博客推荐文章
如果循环次数很多，循环体内代码处理不好问题就会被放大. for(int i=0;i&list.size();i++){}优化为
int size=list.size();
for(int i=0;i&i++){}
for(int i=0;i&100000;i++){. //每循环10次执行一次
for(int i=0;j=10;i&100000;i++;j--){.
- ImportNew
要对你的 java 代码进行优化，需要理解 java 不同要素之间的相互作用，以及它是如何与其运行时的操作系统进行交互的. 使用下面这五个技巧和资源，开始学习如何分析和优化你的代码吧. 在我们开始之前, 你也许会担心许可的问题. Java 为 Oracle 公司所有，遵循 Oracle 的 BCL 许可，该许可证不是一个免费/开源许可证.
- ITeye博客
读了 IBM Developer Works上的一篇. Java 性能优化之 String 篇
感觉写得比较实用，但也有一些问题值得斟酌：. 1）关于内存空间的使用大小，虽然Java的基本类型的大小是固定的，不因运行环境而变化，但是Object overhead，以及Reference的大小是与平台相关的，比如在64bit的机器上Object overhead 应该是16 bytes，Reference是8bytes，这点应该说清楚.
- CSDN博客推荐文章
Btrace是一个实时监控工具，可以无需修改应用代码（事实上它修改了字节码），来达到不可告人的秘密. 它可以获取应用程序代码的执行时间，他可以让你无需修改代码，帮你做时间的打点. 但是，你需要编写btrace脚本，它是一个java文件. 在Eclipse中编写java类很简单，在linux上，vm不熟悉的可能就会比较痛苦了，并且脚本可复制性很强.
- 并发编程网 -
JVM性能优化系列文章由Eva Andearsson在javaworld上发表共计5篇文章，
ImportNew上有前4篇译文. 本文(第5篇)由
吴杰翻译自：
javaworld . 很多程序员在解决JVM性能问题的时候，花开了很多时间去调优应用程序级别的性能瓶颈，当你读完这本系列文章之后你会发现我可能更加系统地看待这类的问题.
- ImportNew
Java性能优化工具可以帮助你改进你的Java代码. 之前我写过一篇关于
5个工具帮助写出更好的Java代码的文章. 合适的工具可以改进我们的代码，并且提高开发效率. 在
IDR解决方案中，我们一直在找一些方法来改进我们的代码. 但最近，我们在考虑改进
PDF HTML5转换器和
Java PDF类库代码时，发现最近我们的关注点已经开始转换到如何提升Java性能.
坚持分享优质有趣的原创文章，并保留作者信息和版权声明，任何问题请联系：@。