聚沙成塔-小哈的记事薄

在JAVA性能优化—IBM JDK JVM参数设置和JAVA性能优化—Sun’s Hostspot JVM参数设置两篇文章中我介绍了针对JDK进行优化的方法，这些参数上的改变也许会带来50%甚至100%的性能提升，但是如果从程序入手，可能提升的空间是一个数量级的，而且往往很多时候性能问题光靠调整参数无法解决。接下来分享两篇文档，指点你写出更符合JVM GC“胃口”的代码。

javaProgrammingPerformanceTips

1. Primitive and Objects
2. Abuse of the String class
3. Creating intermediate objects
4. Mutable return types
5. Using the wrong collections
6. Array copy

         GCFriendlyProgramming

1. Garbage Collection
2. Programming Tips
3. Problems With Finalization
4. Using Reference Objects
5. Conclusions

          详细内容各位自己看吧，对于编程我也是门外汉。

本文主要根据这篇PDF（GCTuningGuidelines）写成。

首先是JDK1.5引入的新功能 Ergonomic Settings（自动优化的参数）

对于有2块CPU和2GB内存及更佳配置的服务器，Sun的hotspot jdk默认设置了如下参数：

• -server ：服务器模式编译
• -XX:+UseParallelGC 并行收集
• -Xms设置为服务器物理内存的1/64
• -Xmx设置为服务器物理内存的1/4（最大为1G）

我在网上发现了这篇文章，也是根据那篇PDF写的，基本都翻译过来了，那我就不再做造轮子的过程了。有些自己的想法会用红色标出。

摘自         http://unixboy.javaeye.com/

原文链接 JVM调优总结 -Xms -Xmx -Xmn -Xss

1. 堆大小设置 JVM 中最大堆大小有三方面限制：相关操作系统的数据模型（32-bt还是64-bit）限制；系统的可用虚拟内存限制；系统的可用物理内存限制。32位系统 下，一般限制在1.5G~2G；64为操作系统对内存无限制。我在Windows Server 2003 系统，3.5G物理内存，JDK5.0下测试，最大可设置为1478m。

   典型设置（例子中的堆分配的都比较大，注意自己平台的限制，下文同）：

   • java -Xmx3550m -Xms3550m -Xmn2g -Xss128k-Xmx3550m：设置JVM最大可用内存为3550M。

     -Xms3550m：设置JVM促使内存为3550m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存（就是收缩和扩张，分代回收加上Sun内存分配的算法，避免了IBM JDK最小堆和最大堆一样上的缺陷，但是这对-Xms和-Xmx的设置有了更高的要求，应该是多次试验确定一个合适的大小）。

     -Xmn2g：设置年轻代大小为2G。整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。从下图，应该可以看到整个堆大小=年轻代大小 + 年老代大小，Xms和Xmx不包括Perm Size。

   阅读全文…

前一篇JVM的恩恩怨怨中，说了对WebSphere优化的关键点——因不同JDK而异。本文将描述IBM JDK下常用参数的设置。

-Xms：最小堆大小

-Xmx：最大堆大小

-Xminf and -Xmaxf：GC（垃圾回收）之后可用空间的最小值最大值

-Xmine and -Xmaxe：堆增长的最小最大值

-Xmint and -Xmaxt：垃圾回收占时间整个运行时间的比例，默认是5%。如果回收时间小于5%，那么它就缩减堆，反之增大。

一般来说只要对Xms和Xmx设置合理，后面的三对不用特别设置。可以看看http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp上heap expasion和heap shrinkage两章的说明，除非有下文的情况：

摘自Java性能优化的策略和常见方法

所以在应用正式上线的头一段时间，最好把GC日志打开，观察一下堆（heap）的增长（expasion）和收缩（shrinkage）。最佳的情况就是，每次回收后可用的堆大小占整个堆的50%左右。如果回收后才腾出30%不到的可用空间，那就该再调整一下上述的参数了。下图看起来直观一点，使用-verbose:size参数可以查看当前的默认值。

那为何不把Xms和Xmx设置成一样大，就像SUN的JDK所推荐的那样？

因为IBM JDK采用的是标记（mark）-扫描（sweep）-标记-……-扫描-紧凑排列（compact），如果还不能提供足够的空间，扩展堆（expasion）。依次循环，直到达到最大堆大小。每次扩展前，那些长存的对象就被调整到堆的底部，每次扩展后需要再动的量就很少。所以如果把Xms设置成和Xmx一样，那么扫描和紧凑排列这么一个充满内存碎片的大堆的开销将大大高于从小扩展堆的开销。

这是由于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

http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp?topic=/com.ibm.java.doc.diagnostics.50/diag/appendixes/defaults.html

JVM environment settings

http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp?topic=/com.ibm.java.doc.diagnostics.50/diag/appendixes/env_var/env_jvm.html

默认的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。

更详细内容，可见http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/index.jsp

或者下载dig60 http://www.ibm.com/developerworks/java/jdk/diagnosis/查看JVM这一块

Sun的JDK配置，可以参考JAVA性能优化—Sun Hotspot JDK JVM参数设置

WebSphere优化中不得不提的是对JVM的优化，OutOfMemory、GC时间太长太频繁、内存碎片、大对象问题……虽说JVM运行效率如何很大程度是和代码有关，但是恰当的参数设置还是可以避免很多问题。因为在JAVA程序中，垃圾回收（Garbage Collection——GC）是内存发生瓶颈的主要因素（在程序没有问题的情况下）。

但是JVM的优化（也就是优化GC）是一个很令人头疼的活。调整JVM需要根据不同的平台分别对待，如果不了解直接Google一个参数加上无法生效事小，适得其反就不好了。在 Sun ™Solaris™ 和 HP-UX 平台上，WebSphere使用的是Sun和HP提供的JDK，而所有其他平台，WebSphere提供的是IBM JDK。所以优化参数主要区别在IBM JDK和非IBM JDK上，Sun和Hp环境下的优化方案基本能共享。

通用配置

          GC优化的关键是降低频率（frequency）和减少持续时间（duration）。但是两者此消彼长，所以平衡一个恰当的值十分关键。频率和堆的大小和分配增长速度有关，而持续时间则和堆大小和堆中对象的多少有关。由此可以看出最先要考虑的就是堆的大小。

          最大堆、最小堆设置：现在32位的堆，一般设置为256～512M或者512～1024M，但是

       对于不同的应用程序，最优化堆大小的设置都有可能不同。如果堆设置较大，可能导致 GC 的次数变少，但每次 GC 所花的时间很长，从而导致系统的处理能力抖动很大。此外如果堆设置过大，会占用过多的内存，使内存资源耗尽，从而会频繁的进行 IO 操作来使用虚拟内存。 如果堆设置较小，可能导致 GC 变的频繁，但每次 GC 所花的时间不会太长，每次 GC 对系统的性能影响相对也会小些。但是如果堆设置过小， 会使得对象可分配空间变小，从而会频繁的 GC 来释放内存空间，而每次 GC，都会耗用一定的系统资源。因此，要通过试验和监控数据，设法使的我们所设置的堆大小能够使得系统运行最优化。

          具体合适的值，可以启用-verbose:gc来观察。一般良好的堆大小，要让回收频率保持在10秒左右，而一次的full gc回收时间在1到2秒之内（一般的回收时间更短才好）。要注意的是，对于32位的JDK，在Windows环境下单个堆不要超过1.7G，AIX平台不要超过3.2G。下面摘自 出色的“清洁工具” ― 理解 IBM Java 垃圾收集器，第一部分：: 对象分配

确定了堆大小，接下来要考虑的是

GC的策略

IBM JDK（1.5）下WebSphere首先要了解的是4个Policy：

IBM SDK 5.0 中的 GC 策略

针对吞吐量进行优化
-Xgcpolicy:optthruput（可选）
默认策略。对于吞吐量比短暂的 GC 停顿更重要的应用程序，通常使用这种策略。每当进行垃圾收集时，应用程序都会停顿。

针对停顿时间进行优化
-Xgcpolicy:optavgpause
通过并发地执行一部分垃圾收集，在高吞吐量和短 GC 停顿之间进行折中。应用程序停顿的时间更短。

分代并发
-Xgcpolicy:gencon
以不同方式处理短期存活的对象和长期存活的对象。采用这种策略时，具有许多短期存活对象的应用程序会表现出更短的停顿时间，同时仍然产生很好的吞吐量。

子池 （一般平台用不到）
-Xgcpolicy:subpool
采用与默认策略相似的算法，但是采用一种比较适合多处理器计算机的分配策略。建议对于有 16 个或更多处理器的 SMP 计算机使用这种策略。这种策略只能在 IBM pSeries® 和 zSeries® 平台上使用。需要扩展到大型计算机上的应用程序可以从这种策略中受益。

其中optthruput是默认的IBM JDK GC策略，我觉得不是很适合一般电子商务的情况。因为它的GC停顿时间是三种策略里最长的，而且对于频繁分配短生命周期、小对象的应用来说，很容易就产生了内存碎片，虽然标志-扫描-紧凑排列（mark-sweep-compact）的第三个阶段“紧凑排列”可以消除碎片，但是这种动作开销很大。一般需要设置P cluster、K cluster参数来减少碎片Avoiding Java heap fragmentation with Java SDK V1.4.2. （这个参数在1.5中也适用）

optavgpause是以一点吞吐量的牺牲（官方说是5%）换来响应时间的提高，用并发标记（JDK1.4）外加并发扫描（JDK1.5引入）的方式来减少GC “Stop the world”的时间。

但一般而言，我都是设置成-Xgcpolicy:gencon ，gencon就是我们常说的“分代回收”策略，在HP和SUN的JDK实现中是默认的回收策略。这篇文章Java 理论与实践: JVM 1.4.1 中的垃圾收集，介绍的就是分代回收策略，而且肯定是针对SUN的JDK，当然HP的也适用。可以关注下面这张图：

形象直观，文章里的文字总忘掉七零八落，但那些原理可以日后巩固，这幅图保存好了设置参数就没啥大问题。

注意下图显示的IBM JDK的分代回收参数设置和SUN/HP的不同

IBM没有设置MaxPermSize的地方，这点要注意了。

HP和SUN的JDK也有两种主要的回收策略，分别是对应高吞吐率的-XX:+UseParallelGC和快速响应时间的-XX:+UseConcMarkSweepGC。

本文主要是描述GC优化的纲领，指出不同的JDK优化对策的不同。详细的参数测试有待以后慢慢写。

相关阅读：

Java 技术，IBM 风格: IBM Developer Kit 简介

Java 理论与实践: 垃圾收集简史  可以了解为什么不同的回收策略，表现出的gc时间会如此迥异。虽然Java 技术，IBM 风格: 垃圾收集策略，第 1 部分一文也叙述的很详细，但是个人觉得《垃圾回收简史》一文写的更明了，毕竟这是最原始的设计，省略了实现过程中添加的许多特性。

前言

What is the Cause of the Performance Problem? 或者是How to Improve the Performance?

这是我们在系统开发、部署过程中都会面对的问题，但是却很难回答。从下面的这幅图就可以看到，一个系统的性能瓶颈（bottleneck)，可能在网络、防火墙，也能在Http Server，Application Server，或者是数据库；系统中一个或者多个“短板”的存在，就能让系统无法达到设计时的目标，无法满足已经签在合同里的SLA……

虽然性能问题牵涉到方方面面，但是本系列关注点在于中间件这一层。希望能用合理的配置避免诸如OutOfMemory（某些情况下）、数据库连接不够的发生，同时能应用一些参数使系统在不优化代码的情况下有5%到100%的提升。

言归正传

池（Pool）是WebSphere中最常涉及的概念之一。从网络、Web 服务器、Web 容器、EJB 容器，一直到数据源，每一个环节都线程池、连接池的影子。要想恰当配置这些池的大小，首先要了解漏斗模型。

通常，WebSphere应用中的一个请求到达服务器，到真正开始处理，要经过一系列的连接池。广域网上可能有大量的并发用户同时访问Web服务器，Web服务器上同时活动（Active）的连接可能高达10000个。但Web服务器到应用服务器（Web容器）的连接池大小可能只有200。Web容器到EJB容器的连接池更小，可能是80。然后，经过数据源（Data source）到数据库的连接最大可能只有25个。从Web服务器的连接池到数据库的连接池尺寸逐渐变小，像一个漏斗（funnel），所以称为漏斗模型。

摘自《构建高性能WebSphere企业级应用》第二章

IBM 000-253中有这么一道题：

According to the Upstream Queuing model for performance tuning, what reflets the correct application of recommended settings for maximum concurrent clients?

A Web Server=75, Web container=75, Datasource =25

B Web Server=75, Web container=50, Datasource =25

C Web Server=50, Web container=50, Datasource =50

D Web Server=25, Web container=50, Datasource =75

根据漏斗模型，那么很显然应该选B。

那么实际生产环境中就如此依样画葫芦就可以了么？后面的池一定比前面的小么？如果当前性能不行，增大池的大小就能提高么？

绝没有那么简单。后面的池小于前者，比如数据库连接池小于web线程池，默认的假定是：并非每个JSP和Servlet都需要访问数据库。如果你的应用是数据库密集型的应用，基本上每个JSP和Servlet都需要访问一次或多次数据库，而且系统中还有一些不经过jsp或Servlet的后台进程。那么数据源的连接池就必须大于web容器线程池，否则会报无法得到连接的错。

下面按照我的经验讲述一下每层池大小设置值

对于Web服务器

IBM HTTP Server的优化就是对Apache的优化。一般需要调整httpd.conf中如下参数：

MaxClients：用来定义Web服务器可以同时支持的最大并发连接数或并发用户数，默认值是600。这个值需要根据你所希望的同时支持的并发用户数来设置，一般是峰值的120%。当然这个值不能设的太大，毕竟Apache吃内存也是很厉害。我遇到的项目一般是不用调整的，大家可以根据实际负载动态的调整MaxClients。

将 IBM HTTP Server 配置为显示状态页面：

• 编辑 IBM HTTP Server 的 httpd.conf 文件，从此文件的下列各行中注释注释字符（#）：

  #LoadModule status_module, modules/ApacheModuleStatus.dll,
  #<Location/server-status>
  #SetHandler server-status
  #</Location>

• 保存更改，然后重新启动 IBM HTTP Server。
• 在 Web 浏览器中，转至 http://yourhost/server-status。并且，单击重新装入以更新状态。
• （可选）如果浏览器支持刷新，那么转至 http://your_host/server-status?refresh=5 以便每 5 秒钟刷新一次。

上图给出了一些其它参数的推荐值。注意Windows平台和其它平台的不同（ThreadsPerChild相当于Maxclients）。关于MinSpareServers, MaxSpareServers, 和StartServers 等的设置，以及MPM使用prefork或worker模块时的不同，可以阅读Apache Performance Tuning。

如果你的应用访问量很大，那么也许你需要优化一下操作系统的tcp/ip相关参数。 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tuneopsys.html

并修改“负载均衡”选项和“重试时间间隔”Web 服务器插件属性设置以提高性能http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tprf_tunewebserv.html

Web容器线程池

要点就是：“通常，对于每个服务器 CPU，5 至 10 个线程将会提供最佳吞吐量”（现在的一个cpu可以用核来代替）。比如你的Pc Server有2块CPU，每块CPU都是4核，那么你一个Application Server可以设置的最小值和最大值可以分别为40、80。但是一般考虑到能充分利用CPU和Memory，或者为不同的应用启用不同的application server，一台Pc Server上并不仅有这么一个appserver，而且还有别的进程在占用着CPU，所以默认的10到50（Linux 系统上 25 个）是一个比较合适的值，当然更准确的值需要通过性能测试来确定。

在进行性能测试的时候，如果吞吐率不是很满意，或者在TPV中看到线程池占用一直是最大值，不要立刻就调大线程池的设置——往往吞吐率会更一步下降。这时候要注意CPU占用率的情况、vmstat的r列值，特别是System状态占用率的情况，如果接近10%，甚至超过10%，那么可以肯定系统在进程切换上面消耗的资源太多了。下调线程池的大小反而会提升吞吐率，而且会由于吞吐率的提升降低页面平均响应时间。

这篇文章也许会使你对线程池大小对性能的影响有个感性的认识。

设置的地方大家应该都晓得，单击服务器 > 应用程序服务器 > server_name > 线程池。

数据库连接池

连接池的最小值，应该和性能测试时TPV观察到的jdbc平均大小一样，最大值根据实际需要设置，每次增长可以设置成大于1，增长一次到位。总之尽量避免连接池频繁的增长和收缩，减少wait的情况发生。

可以使用 Tivoli Performance Viewer 查找池中最优连接数。如果并发等待者的数目大于 0，但是 CPU 负载未接近 100%，那么考虑增加连接池大小。如果使用百分比值一直低于正常工作负载，那么考虑减少池中的连接数。

Application Server 将在使用该数据源的每个应用程序服务器中创建连接池的单独实例。例如：

• 如果运行包含三个服务器的集群，这三个服务器都使用 myDataSource，并且 myDataSource 的“最大连接数”设置为 10，那么可生成多达 30 个连接（3 个服务器乘以 10 个连接）

这是需要考虑的，别数据库端的连接大小不够了。此外，inactive timeout和timeout的时间应该大于收集时间。

总结

这篇文章参考了IBM的inforcenter和developworks，给出了优化WebSphere池大小的一些经验值，但是真正合适的大小还要参考实际的情况，总之调优是个循序渐进的过程。

继续逛逛

调整完了各种池的大小，接下来你需要对内存参数做些优化，这篇是纲领性的。

JVM的恩恩怨怨-WebSphere性能优化（二）

针对不同的JDK，你可以参考：

JAVA性能优化—Sun Hotspot JDK JVM参数设置

JAVA性能优化—IBM JDK JVM参数设置