注：在下面做的介绍都是以Weblogic8.1为例的，其它版本的Weblogic可能会有些许不同。

       1) 设置JAVA参数；

       a) 编辑Weblogic Server启动脚本文件；

l         BEA_HOME\user_projects\domains\domain-name\startWebLogic.cmd(startWebLogic.sh on Unix)

l         BEA_HOME\user_projects\domains\domain-name\startManagedWebLogic.cmd(startManagedWebLogic.sh on Unix)

b) 编辑set JAVA_OPTIONS命令，如：set JAVA_OPTIONS=-Xms256m –Xmx256m；

c) 保存，重启即可。

注：在WebLogic中，为了获得更好的性能，BEA公司推荐最小Java堆等于最大Java堆。

2) 开发模式 vs. 产品模式；

开发模式和产品模式的一些参数的默认值不同，可能会对性能造成影响，下面是对性能有影响的参数列表：

       通过启动管理控制台，在域（如：mydomain）> 配置 > 常规选择产品模式。

3) 尽量开启本地I/O；

通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）> 配置 > 调整选择启用本地I/O。

注：此值也可通过手动的修改config.xml配置文件。

4) 调优执行队列线程；

a) 修改默认执行线程数

在这里，执行队列的线程数表示执行队列能够同时执行的操作的数量。但此值不是设的越大越好，应该恰到好处的去设置它，太小了，执行队列中将会积累很多待处理的任务，太大了，则会消耗大量的系统资源从而影响整体的性能。在产品模式下默认为25个执行线程。

为了设置理想的执行队列的线程数，我们可以启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）> 监视 > 性能中监控最大负载时执行队列的吞吐量和队列中的等待请求数，据此确定理想的数值。

       理想的默认执行线程数是由多方面的因素决定的，比如机器CPU性能、总体体系架构、I/O、操作系统的进程调度机制、JVM的线程调度机制。随着CPU个数的增加，WebLogic可以近乎线性地提高线程数。线程数越多，花费在线程切换的时间也就越多；线程数越小，CPU可能无法得到充分的利用。为获取一个理想的线程数，需要经过反复的测试。在测试中，可以以25*CPU个数为基准进行调整。当空闲线程较少，CPU利用率较低时，可以适当增加线程数的大小（每五个递增）。对于PC Server和Windows 2000，则最好每个CPU小于50个线程，以CPU利用率为90%左右为最佳。

       通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）> Execute Queue > weblogic.kernel.Defalt > 配置中修改线程计数。

       b) 设定执行队列的溢出条件；

       Weblogic Server提供给默认的执行队列或用户自定义的执行队列自定义溢出条件的功能，当满足此溢出条件时，服务器改变其状态为“警告”状态，并且额外的再分配一些线程去处理在队列中的请求，而达到降低队列长度的目的。

       通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）> Execute Queue > weblogic.kernel.Defalt > 配置下面几项：

l         队列长度：此值表示执行队列中可容纳的最大请求数，默认值是65536，最后不要手动改变此值。

l         队列长度阈值百分比：此值表示溢出条件，在此服务器指出队列溢出之前可以达到的队列长度大小的百分比。

l         线程数增加：当检测到溢出条件时，将增加到执行队列中的线程数量。如果CPU和内存不是足够的高，尽量不要改变默认值“0”。因为Weblogic一旦增加后不会自动缩减，虽然最终可能确实起到了降低请求的作用，但在将来的运行中将影响程序的性能。

l         最大线程数：为了防止创建过多的线程数量，可以通过设定最大的线程数进行控制。

在实际的应用场景中，应根据具体情况适当的调整以上参数。

c) 设定执行队列监测行为

Weblogic Server能够自动监测到当一个执行线程变为“阻塞”。变为“阻塞”状态的执行线程将无法完成当前的工作，也无法再执行新请求。如果执行队列中的所有执行线程都变为“阻塞”状态，Weblogic server可能改变状态为“警告”或“严重”状态。如果Weblogic server变为“严重”状态，可以通过Node Manager来自动关闭此服务器并重新启动它。具体请参考：Node Manager Capabilities文档。

通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）>配置 > 调整下可配置下面几项：

l         阻塞线程最长时间：在此服务器将线程诊断为阻塞线程之前，线程必须连续工作的时间长度(秒)。默认情况下，WebLogic Server 认为线程在连续工作 600 秒后成为阻塞线程。

l         阻塞线程计时器间隔：WebLogic Server 定期扫描线程以查看它们是否已经连续工作了 "阻塞线程最长时间" 字段中指定的时间长度的间隔时间(秒)。默认情况下，WebLogic Server 将此时间间隔设置为 600 秒。

5) 调优TCP连接缓存数；

WebLogic Server用Accept Backlog参数规定服务器向操作系统请求的队列大小，默认值为50。当系统重载负荷时,这个值可能过小,日志中报Connection Refused,导致有效连接请求遭到拒绝,此时可以提高Accept Backlog 25%直到连接拒绝错误消失。对于Portal类型的应用,默认值往往是不够的。Login Timeout和SSL Login Timeout参数表示普通连接和SSL连接的超时时间,如果客户连接被服务器中断或者SSL容量大,可以尝试增加该值。

通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）>配置 > 调整下可配置“接受预备连接”。

6) 改变Java编译器；

标准的Java编译器是javac，但编译JSP servlets速度太慢，为了提高编译速度，可以使用sj或jikes编译器取代javac编译器。下面说说更改Java编译器：

通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）>配置 > 常规下改变Java 编译器，默认为javac。输入完整路径，如：c:\visualcafe31\bin\sj.exe。然后打开高级选项，在预规划到类路径填写编译 Java 代码时为 Java 编译器类路径预规划的选项，如：BEA_HOME\jdk141_02\jre\lib\rt.jar。

7) 使用Webogic Server集群提高性能；

具体关于如何配置Weblogic集群，我就不细说了。详情可参考：Introduction to WebLogic Server Clustering。

8) Weblogic EJB调优

由于EJB2.0已经很少项目在用了，EJB3.0再成熟一点，我再补充这一部分吧！

9) JDBC应用调优

JDBC Connection Pool的调优受制于WebLogic Server线程数的设置和数据库进程数,游标的大小。通常我们在一个线程中使用一个连接,所以连接数并不是越多越好,为避免两边的资源消耗，建议设置连接池的最大值等于或者略小于线程数。同时为了减少新建连接的开销,将最小值和最大值设为一致。

增加Statement Cache Size对于大量使用PreparedStatement对象的应用程序很有帮助,WebLogic能够为每一个连接缓存这些对象,此值默认为10。在保证数据库游标大小足够的前提下,可以根据需要提高Statement Cache Size。比如当你设置连接数为25,Cache Size为10时,数据库可能需要打开25*10=250个游标。不幸的是,当遇到与PreparedStatement Cache有关的应用程序错误时,你需要将Cache Size设置为0。

尽管JDBC Connection Pool提供了很多高级参数,在开发模式下比较有用,但大部分在生产环境下不需调整。这里建议最好不要设置测试表, 同时Test Reserved Connections和Test Released Connections也无需勾上。 当然如果你的数据库不稳定,时断时续,你就可能需要上述的参数打开。

最后提一下驱动程序类型的选择,以Oracle为例,Oracle提供thin驱动和oci驱动,从性能上来讲,oci驱动强于thin驱动,特别是大数据量的操作。但在简单的数据库操作中,性能相差不大,随着thin驱动的不断改进,这一弱势将得到弥补。而thin驱动的移植性明显强于oci驱动。所以在通常情况下建议使用thin驱动。而最新驱动器由于WebLogic server/bin目录下的类包可能不是最新的,请以Oracle网站为准: http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/jdbc9201.html。

10) JSP调优

l         设置jsp-param pageCheckSeconds=-1；

l         设置serlet-reload-check=-1或ServletReloadCheckSecs=-1；

l         设置jsp-param precompile=true，关闭JSP预编译选项。

       下面列出一些常见的关于字符串优化的策略，简单的我就不多作解释了。

1) 使用规则表达式处理字符串匹配代替复杂的字符串查找和复制操作；

2) 使用不拷贝字符串中字符的高效方法，例如String.subString()方法；

3) 尽可能不要使用需要拷贝字符串中字符的低效方法，例如String.toUpperCase()和String.toLowercase()；

4) 在编译期使用String的“+”操作符来执行连接操作，在运行期使用StringBuffer执行连接操作；

这里特别强调一下，因为我已经在网上看到好多文章都推荐使用StringBuffer的append()方法来做字符串的连接操作。其实在JVM能够在编译期就能确定结果的情形，使用String的“+”操作符的性能要好很多。

3.3 异常，类型转换和变量

       1) 考虑在抛出异常的时候是否可以不即时生成堆栈信息而使用一个已有的异常实例；

       创建异常的开销很大。当创建一个异常时，需要收集一个栈跟踪（Stack Trace），这个栈跟踪用于描述异常是在何处创建的。构建这些栈跟踪时需要为运行时栈做一份快照，正是这一部分开销很大。运行时栈不是为有效的异常创建而设计的，而是设计用来让运行时尽可能快地运行。入栈，出栈，入栈，出栈。让这样的工作顺利完成，而没有任何不必要的延迟。但是，当需要创建一个Exception时，JVM不得不说：“先别动，我想就你现在的样子存一份快照，所以按时停止入栈和出栈操作，笑着等我拍完快照吧。”栈跟踪不只包含运行时栈中的一两个元素，而是包含这个栈中的每一个元素，从栈顶到栈底，还有行号和一切应有的东西。

       因此，创建异常这一部分开销很大。从技术上讲，栈跟踪快照是在本地方法Throwable.fillInStackTrace()中发生的，这个方法不是从Throwable contructor那里调用的。但是这并并没有什么影响——如果你创建了一个Exception，就得付出代价。好在捕获异常开销不大，因此可以用try-catch将核心内容包起来。你也可以在方法定义中定义throws子句，这样对性能不会造成什么损失。从技术上讲，你甚至可以随意地抛出异常，而不用花费很大的代价。招致性能损失的并不是throw操作——尽管在没有预先创建异常的情况下就抛出异常是有点不寻常。真正要花代价的是创建异常。

       幸运的是，好的编程习惯已教会我们，不应该不管三七二十一就抛出异常。异常是为异常的情况而设计的，使用时也应该牢记这一原则。但是，万一你不想遵从好的编程习惯，Java语言就会让你知道，那样就可以让你的程序运行的更快，从而鼓励你去那样做。

       2) 用instanceof替代在try-catch中做投机的强制类型转换方法；

       3) 尽可能少的使用强制类型转换方法，尤其是使用类型特定的集合类时；

       4) 使用int优先于其他所有的数据类型；

       5) 尽可能使用基本数据类型做临时变量；

       6) 考虑直接获取实例变量而不通过get，set方法获取（注意：这不符合面向对象的封装原则，不推荐使用）。

3.4 循环，选择和递归

       1) 在循环中消除不必要的代码，做尽可能少的事情；

       2) Switch语句中使用连续的case值；

       3) 确定是否真的需要用到递归，最好转为用循环来实现。

3.5 输入输出操作

       1) 在程序中尽量不要使用System.out这样的语句，而使用log4j这样的日志工具替换，以在程序正式上线的时候可以关闭所有不必要的日志操作提高性能；

       2) 当程序中有大量的I/O操作时，考虑将日志写入不同的文件做到并行化操作以提高性能，并可以用一个后台线程执行I/O操作而不打断正常程序的执行；

       3) 正确的使用序列化机制，没有必要序列化的成员变量需要标识为transient；

       4) 使用NIO技术。

3.6 JDBC

       1) 使用正确的JDBC驱动，尽可能地选择最新的JDBC驱动；

       最新的JDBC驱动不仅优化了性能，而且提供了更多的性能更好的接口供开发人员使用。

       2) 使用应用服务器自带的连接池，而不要使用自己的连接池或干脆不用连接池；

       3) 在使用完数据库资源后，需依次关闭ResultSet，Statement和Connection；

       4) 手动控制事务，使用connection.setAutoCommit(false)关闭自动提交，使用executeBatch()进行批量更新；

       5) 业务复杂或者大数据量操作时使用存储过程；

       6) ResultSet.next()极其消耗性能，建议使用RowSet替代ResultSet；

       7) 把所有的字符数据都保存为Unicode，Java以UniCode形式处理所有数据，数据库驱动程序不必再执行转换过程；

       8) 尽可能的优化SQL语句；

       9) 少用join，多用index；

       10) 使用EXPLAIN工具监控SQL语句的执行，以确定瓶颈所在；

11)   不要使用 SELECT * ..., 使用 SELECT Field1, Field1 ...；

12)   通过index获取字段，而不要使用名字去获取，例如resultSet.getString(1) 而不是 resultSet.getString("field1")；

13)   缓存数据，避免重复查询；

14)   考虑使用内存数据库；

15)   调整fetch size进行批量查询；

16)   尽可能的使Java数据类型和数据库类型相匹配，转换数据在匹配不好的数据类型间效率太差；

17)  避免使用低效的metadata调用，尤其是getBestRowIdentifier( ), getColumns( ), getCrossReference( ), getExportedKeys( ), getImportedKeys( ), getPrimaryKeys( ), getTables( ), and getVersionColumns( )；

18)   使用metadata查询减少数据库网络通信量；

19)   使用最低的事务隔离级别；

20)   使用乐观锁机制；

21)   把应用服务器和数据库分散在不同的机器中，性能可能会更好。

3.7 Servlet和JSP

       1) Session的使用；

       应用服务器保存很多会话时，容易造成内存不足，所以尽量减少Session的使用，放置到Session中的对象不应该是大对象，最好是简单的小对象，实现串行化接口。当会话不再需要时，应当及时调用invalidate()方法清除会话。而当某个变量不需要时，及时调用removeAttribute()方法清除变量。当session终止时需要清除不必要的资源，实现HttpSessionBindingListener接口的valueUnbound()方法。

       2) 使用include directive，而不使用include action；

       目前在JSP页面中引入外部资源的方法主要有两种：include directive和include action。Include directive：例如<%@ include file=”copyright.html” %>，该指令在编译时引入指定的资源。在编译之前，带有include指令的页面和指定的资源被合并成一个文件。被引用的资源在编译时就确定，比运行时才确定资源更高效。Include action：例如< jsp:include page=”copyright.jsp” />，该动作引入指定页面执行后生成的结果。由于它在运行时完成，因此对输出结果的控制更加灵活。但是，只有当引用的内容被频繁改变时，或者在对主页面的请求没有出现之前，被引用的页面无法确定时，使用include action才合算。

       3) 对于那些无需跟踪会话状态的jsp，关闭自动创建的会话可以节省一些资源。使用如下page指令： < %@ page session=”false” %>；

       4) 尽量不要把jsp页面定义为单线程，应设置为< %@page isThreadSafe=”true” %>；

       5) 在jsp页面最好使用输出缓存功能，如：< %@page buffer=”32kb” %>；

       6) 在servlet之间跳转时，forward比sendRedirect更有效；

       7) 设置HttpServletResponse缓冲区，如：response.setBufferSize(20000)；

       8) 建议在servlet里使用ServletOutputStream输出图片等对象；

9) 不要使用SingleThreadModel，使Servlet是线程安全的，但是尽可能的减少消耗在同步代码上的时间，使用足够多的servlet去响应用户的请求；

10) 尽可能的使useBean的范围在page范围内；

11)   Servlet的inti()和destroy()或jspInit()和jspDestroy()方法用于创建和删除昂贵的资源，例如缓存对象和数据库连接；

12)   避免使用反向DNS查找；

13)   预编译JSP页面；

14)   尽可能的在客户段校验数据；

15)   禁止自动装载特色防止周期性的装载servlet和jsp。

3.8 EJB

       由于EJB2.0已经很少项目在用了，EJB3.0再成熟一点，我再补充这一部分吧！

对象的创建是一个非常昂贵的工作，而由于对象的创建而导致经常性的垃圾收集则是一个更加消耗时间和CPU的操作。我们在编码时，应当尽量的减少对象的创建。不要在经常被执行的代码中创建对象；使用集合对象时最好预先分配其大小；当一个class的多个实例都需要获取某个对象时，最好能标记那个对象static；当不需要stack trace时尽可能的重用异常实例等等都能很有效的避免对象创建而导致的额外的开销。下面是一些常用的有效的策略：

1)      对象池技术

在Java中开发一个普遍性的对象池架构可以更好地利用资源，并可以使对象创建的成本降到最小。大多数人对直接或间接运用对象池来连接一个数据库都很熟悉。但通常你也可以将对象放入对象池中从而节省重要的资源、提高程序的效率并控制对不充足资源的访问。出于对设计、成本或性能的考虑，放入对象池中的对象通常是有限的。它们或者是初始化成本很高的对象，或者是很少用的对象。运用对象池我们可以管理竞争性客户端对有限的对象集的访问。

对象池主要是可以更好地运用你的资源。例如，设想有相当多的客户要有效运用很少的数据库连接或网络连接。通过限制对对象的访问（只在客户端需要的时候才能访问对象），你就可以释放资源，让其它客户端使用。通过对象池提高对象的利用率通常可以提高系统的性能。

你可以使用对象池使初始化的成本达到最小。典型的例子包括数据库、网络连接和线程。这样的连接通常需要很多时间来初始化。一旦创建了这些连接，你就可以重用它们，从而极大地节省了成本。因此，你可以将初始化成本很高（从时间、内存或其它资源方面考虑）的对象放入对象池中。例如，大多数容器都将EJB放入对象池中，从而避免重复的资源分配和状态初始化。

一个设计良好的对象池架构具有普遍性，它适合不同应用程序的需要。可以让你控制对象池的容量、对象填充策略和对象状态。它可以极大地提高你的应用程序的效率，不管从速度方面考虑，还是从资源利用率方面考虑，该架构都可以提供这样的好处。

在这里，给大家推荐一个开源的项目Commons-Pool（http://jakarta.apache.org/commons/pool/），我还没来得及研究，谁用过了，感觉好的，麻烦告诉我一下，谢谢！

2)      ThreadLocal技术

使用此技术获取线程绑定的带状态的单例对象。

3)      单例模式

通过单例模式或使定义对象static来使得对象的实例只能有一个并被其他对象所共享。

4)      枚举常量

使用整数取代字符串作为枚举常量，比如FEMALE和MALE我们可以用整数1和2来替代。这样将带来速度上和内存上的优势。

5)      使用SoftReference，WeakReference和PhantomReference引用类

引用类的主要功能就是能够引用仍可以被垃圾收集器回收的对象。在引入引用类之前，我们只能使用强引用（Strong Reference）。例如obj这个引用将引用堆中存储的一个对象，只要obj引用还存在，垃圾收集器就永远不会释放用来容纳该对象的存储空间。当obj超出范围或被显式指定为null时，垃圾收集器就认为没有对这个对象的其他引用，也就可以收集它了。然而还需要注意一个重要的细节：仅凭对象可以被收集并不意味着垃圾收集器的一次指定运行就能够回收它。由于各种垃圾收集算法不同，某些算法会更频繁地分析生存期较短的对象，而不是较老、生存期较长的对象。因此，一个可供收集的对象可能永远也不会被回收。如果程序在垃圾收集器释放对象之前结束，这种情况就可能会出现。因此，概括地说，你永远无法保证可供收集的对象总是会被垃圾收集器收集。

让我们来看看一些术语和定义：

强可及对象（Strongly Reachable）：可以通过强引用访问的对象。

软可及对象（Softly Reachable）：不是强可及对象，并且能够通过软引用访问的对象。

弱可及对象（Weakly Reachable）：不是强可及对象也不是软可及对象，并且能够通过弱引用访问的对象。

虚可及对象（Phantomly Reachable）：不是强可及对象、软可及对象，也不是弱可及对象，已经结束的，可以通过虚引用访问的对象。

清除：将引用对象的refernce域设置为null，并将引用类在堆中引用的对象声明为可结束的。

SoftReference类：SoftReference类的一个典型用途就是用于内存敏感的高速缓存。SoftReference的原理是：在保持对对象的引用时保证在JVM报告内存不足情况之前清楚所有的软引用。关键之处在于，垃圾收集器在运行时可能会（也可能不会）释放软可及对象。对象是否被是否取决于垃圾收集器的算法以及垃圾收集器运行时可用的内存数量。

WeakReference类：WeakReference类的一个典型用途就是规范化映射（Canonicalized Mapping）。另外，对于那些生存期相对较长而且重新创建的开销也不高的对象来说，弱引用也比较有用。关键之处在于，垃圾收集器运行时如果碰到了弱可及对象，将释放 WeakReference 引用的对象。然而，请注意，垃圾收集器可能要运行多次才能找到并释放弱可及对象。

PhantomReference类：PhantomReference 类只能用于跟踪对被引用对象即将进行的收集。同样，它还能用于执行 pre-mortem 清除操作。 PhantomReference 必须与 ReferenceQueue 类一起使用。需要 ReferenceQueue 是因为它能够充当通知机制。当垃圾收集器确定了某个对象是虚可及对象时， PhantomReference 对象就被放在它的 ReferenceQueue 上。将 PhantomReference 对象放在 ReferenceQueue 上也就是一个通知，表明 PhantomReference 对象引用的对象已经结束，可供收集了。这使您能够刚好在对象占用的内存被回收之前采取行动。

在某些场合引用类还是很有用的，具体可以参考文章Java2引用类使用指南（http://www-128.ibm.com/developerworks/cn/java/j-refs/index.html）。

6)      尽可能少的减少不必要对象的生成

尽可能减少在循环中创建对象，使用StringBuffer而不要使用String来做连接操作等等。

7)      改变对象的创建时机

通过提前创建对象或延迟到使用时再创建对象，来做到性能优化和避免创建过多的对象。

一 基本知识

1.1 性能是什么

在性能调优之前，我们首先来了解一下性能是什么？关于性能，我想每个学习过Java的人都能列出几点，甚至可以夸夸其谈。在《Java TM Platform Performance》（注：我有此书的电子版，有需要者可以和我联系）一书中，定义了如下五个方面来作为评判性能的标准：

1)      运算的性能——哪一个算法的执行性能最好？

2)      内存的分配——程序运行时需要耗费多少内存？

3)      启动的时间——程序启动需要多长时间？这在Web项目中的影响不大，但要注意部分程序需要部署或运行在客户端时的情形（比如applet程序）。

4)      程序的可伸缩性——在压力负载的情况下，程序的性能如何？

5)      性能的感知——用户在什么情况下会觉得程序的性能不好？

以上五个方面，在具体的使用场景可以有选择的去评判。至于这五方面的性能调优，在后续的章节中将会陆续的给以相应的性能调优策略。

1.2 调优的规则

我们只需要关心对我们程序有影响，可以察觉到的性能问题，而不是每一个类中的每一个方法我们都需要想方设法的提高性能。如果程序的性能没有达到我们所期望的要求，我们才需要考虑如何优化性能。同样的，晦涩的代码虽然提高了程序的性能，但同时可能带给我们的是维护的噩梦。我们需要折中的考虑以上两种情况，使得程序的代码是优美的，并且运行的足够快，达到客户所期望的性能要求。

优化代码甚至会导致不良的结果，Donald Knuth（一位比较牛比较有影响的人物，具体是谁，我也忘了，谁知道，可以告诉我一下，谢谢！）曾说过，“Premature optimization is the root of all evil”。在开始性能调优前，需要先指出不优化代码的一些理由。

1)      如果优化的代码已经正常工作，优化后可能会引入新的bug；

2)      优化代码趋向于使代码更难理解和维护；

3)      在一个平台上优化的代码，在另一个平台上可能更糟；

4)      花费很多时间在代码的优化上，提高了很少的性能，却导致了晦涩的代码。

确实，在优化前，我们必须认真的考虑是否值得去优化。

1.3 调优的步骤

一般我们提高应用程序的性能划分为以下几个步骤：

1)      明确应用程序的性能指标，怎样才符合期望的性能需求；

2)      在目标平台进行测试；

3)      如果性能已经达到性能指标，Stop；

4)      查找性能瓶颈；

5)      修改性能瓶颈；

6)      返回到第2步。

二 JDK调优

2.1 选择合适的JDK版本

不同版本的JDK，甚至不同厂家的JDK可能都存在着很大的差异，对于性能优化的程度不同。一般来说，尽可能选择最新发布的稳定的JDK版本。最新的稳定的JDK版本相对以前的JDK版本都会做一些bug的修改和性能的优化工作。

2.2 垃圾收集Java堆的优化

垃圾收集就是自动释放不再被程序所使用的对象的过程。当一个对象不再被程序所引用时，它所引用的堆空间可以被回收，以便被后续的新对象所使用。垃圾收集器必须能够断定哪些对象是不再被引用的，并且能够把它们所占据的堆空间释放出来。如果对象不再被使用，但还有被程序所引用，这时是不能被垃圾收集器所回收的，此时就是所谓的“内存泄漏”。监控应用程序是否发生了内存泄漏，有一个非常优秀的监控工具推荐给大家——Quest公司的JProbe工具，使用它来观察程序运行期的内存变化，并可产生内存快照，从而分析并定位内存泄漏的确切位置，可以精确定位到源码内。这个工具的使用我在后续的章节中还会做具体介绍。

Java堆是指在程序运行时分配给对象生存的空间。通过-mx/-Xmx和-ms/-Xms来设置起始堆的大小和最大堆的大小。根据自己JDK的版本和厂家决定使用-mx和-ms或-Xmx和-Xms。Java堆大小决定了垃圾回收的频度和速度，Java堆越大，垃圾回收的频度越低，速度越慢。同理，Java堆越小，垃圾回收的频度越高，速度越快。要想设置比较理想的参数，还是需要了解一些基础知识的。

Java堆的最大值不能太大，这样会造成系统内存被频繁的交换和分页。所以最大内存必须低于物理内存减去其他应用程序和进程需要的内存。而且堆设置的太大，造成垃圾回收的时间过长，这样将得不偿失，极大的影响程序的性能。以下是一些经常使用的参数设置：

1)      设置-Xms等于-XmX的值；

2)      估计内存中存活对象所占的空间的大小，设置-Xms等于此值，-Xmx四倍于此值；

3)      设置-Xms等于-Xmx的1/2大小；

4)      设置-Xms介于-Xmx的1/10到1/4之间；

5)      使用默认的设置。

大家需要根据自己的运行程序的具体使用场景，来确定最适合自己的参数设置。

除了-Xms和-Xmx两个最重要的参数外，还有很多可能会用到的参数，这些参数通常强烈的依赖于垃圾收集的算法，所以可能因为JDK的版本和厂家而有所不同。但这些参数一般在Web开发中用的比较少，我就不做详细介绍了。在实际的应用中注意设置-Xms和-Xmx使其尽可能的优化应用程序就行了。对于性能要求很高的程序，就需要自己再多研究研究Java虚拟机和垃圾收集算法的机制了。可以看看曹晓钢翻译的《深入Java虚拟机》一书。