一、通用篇
“通用篇”讨论的问题适合于大多数Java应用。
1.1 不用new关键词创建类的实例
用new关键词创建类的实例时，构造函数链中的全部构造函数都会被自己主动调用。但假设一个对象实现了Cloneable接口。我们能够调用它的clone()方法。
clone()方法不会调用不论什么类构造函数。
在使用设计模式（Design Pattern）的场合，假设用Factory模式创建对象，则改用clone()方法创建新的对象实例非常easy。
比如。以下是Factory模式的一个典型实现：
| public static Credit getNewCredit() {return new Credit();} |
改进后的代码使用clone()方法。例如以下所看到的：
| private static Credit BaseCredit = new Credit(); public static Credit getNewCredit() { return (Credit) BaseCredit.clone(); } |
上面的思路对于数组处理相同非常实用。
1.2 使用非堵塞I/O
版本号较低的JDK不支持非堵塞I/O API。为避免I/O堵塞，一些应用採用了创建大量线程的办法（在较好的情况下，会使用一个缓冲池）。
这样的技术能够在很多必须支持并发I/O流的应用中见到，如Webserver、报价和拍卖应用等。然而，创建Java线程须要相当可观的开销。
JDK 1.4引入了非堵塞的I/O库（java.nio）。
假设应用要求使用版本号较早的JDK。在这里有一个支持非堵塞I/O的软件包。
请參见Sun中国站点的《调整Java的I/O性能》。
1.3 慎用异常
异常对性能不利。抛出异常首先要创建一个新的对象。
Throwable接口的构造函数调用名为fillInStackTrace()的本地（Native）方法，fillInStackTrace()方法检查堆栈，收集调用跟踪信息。仅仅要有异常被抛出，VM就必须调整调用堆栈，由于在处理过程中创建了一个新的对象。
异常仅仅能用于错误处理，不应该用来控制程序流程。
1.4 不要反复初始化变量
默认情况下，调用类的构造函数时， Java会把变量初始化成确定的值：全部的对象被设置成null。整数变量（byte、short、int、long）设置成0，float和double变量设置成0.0。逻辑值设置成false。
当一个类从还有一个类派生时。这一点尤其应该注意，由于用new关键词创建一个对象时，构造函数链中的全部构造函数都会被自己主动调用。
1.5 尽量指定类的final修饰符
带有final修饰符的类是不可派生的。在Java核心API中。有很多应用final的样例，比如java.lang.String。为String类指定final防止了人们覆盖length()方法。
另外，假设指定一个类为final。则该类全部的方法都是final。Java编译器会寻找机会内联（inline）全部的final方法（这和详细的编译器实现有关）。此举能够使性能平均提高50%。
1.6 尽量使用局部变量
调用方法时传递的參数以及在调用中创建的暂时变量都保存在栈（Stack）中，速度较快。
其它变量，如静态变量、实例变量等。都在堆（Heap）中创建。速度较慢。
另外。依赖于详细的编译器/JVM，局部变量还可能得到进一步优化。请參见《尽可能使用堆栈变量》。
1.7 乘法和除法
考虑以下的代码：
| for (val = 0; val < 100000; val +=5) { alterX = val * 8; myResult = val * 2; } |
用移位操作替代乘法操作能够极大地提高性能。以下是改动后的代码：
| for (val = 0; val < 100000; val += 5) { alterX = val << 3; myResult = val << 1; } |
改动后的代码不再做乘以8的操作，而是改用等价的左移3位操作，每左移1位相当于乘以2。
对应地。右移1位操作相当于除以2。值得一提的是，尽管移位操作速度快，但可能使代码比較难于理解，所以最好加上一些凝视。
前面介绍的改善性能技巧适合于大多数Java应用，接下来要讨论的问题适合于使用JSP、EJB或JDBC的应用。
二、J2EE篇
2.1 使用缓冲标记
一些应用server增加了面向JSP的缓冲标记功能。比如，BEA的WebLogic Server从6.0版本号開始支持这个功能，Open Symphonyproject也相同支持这个功能。
JSP缓冲标记既能够缓冲页面片断，也能够缓冲整个页面。
当JSP页面运行时，假设目标片断已经在缓冲之中，则生成该片断的代码就不用再运行。页面级缓冲捕获对指定URL的请求，并缓冲整个结果页面。对于购物篮、文件夹以及门户站点的主页来说，这个功能极事实上用。对于这类应用，页面级缓冲能够保存页面运行的结果，供后继请求使用。
对于代码逻辑复杂的页面，利用缓冲标记提高性能的效果比較明显；反之，效果可能略逊一筹。
请參见《用缓冲技术提高JSP应用的性能和稳定性》。
2.2 始终通过会话Bean訪问实体Bean
直接訪问实体Bean不利于性能。当客户程序远程訪问实体Bean时。每个get方法都是一个远程调用。訪问实体Bean的会话Bean是本地的，能够把全部数据组织成一个结构，然后返回它的值。
用会话Bean封装对实体Bean的訪问能够改进事务管理。由于会话Bean仅仅有在到达事务边界时才会提交。每个对get方法的直接调用产生一个事务。容器将在每个实体Bean的事务之后运行一个“装入-读取”操作。
一些时候。使用实体Bean会导致程序性能不佳。假设实体Bean的唯一用途就是提取和更新数据，改成在会话Bean之内利用JDBC訪问数据库能够得到更好的性能。
2.3 选择合适的引用机制
在典型的JSP应用系统中，页头、页脚部分往往被抽取出来，然后依据须要引入页头、页脚。
当前。在JSP页面中引入外部资源的方法主要有两种：include指令，以及include动作。
- include指令：比如<%@ include file="copyright.html" %>。
该指令在编译时引入指定的资源。
在编译之前，带有include指令的页面和指定的资源被合并成一个文件。被引用的外部资源在编译时就确定，比运行时才确定资源更高效。
- include动作：比如<jsp:include page="copyright.jsp" />。该动作引入指定页面运行后生成的结果。由于它在运行时完毕。因此对输出结果的控制更加灵活。
但时，仅仅有当被引用的内容频繁地改变时。或者在对主页面的请求没有出现之前，被引用的页面无法确定时，使用include动作才合算。
2.4 在部署描写叙述器中设置仅仅读属性
实体Bean的部署描写叙述器同意把全部get方法设置成“仅仅读”。当某个事务单元的工作仅仅包括运行读取操作的方法时。设置仅仅读属性有利于提高性能。由于容器不必再运行存储操作。
2.5 缓冲对EJB Home的訪问
EJB Home接口通过JNDI名称查找获得。
这个操作须要相当可观的开销。
JNDI查找最好放入Servlet的init()方法里面。
假设应用中多处频繁地出现EJB訪问，最好创建一个EJBHomeCache类。
EJBHomeCache类一般应该作为singleton实现。
2.6 为EJB实现本地接口
本地接口是EJB 2.0规范新增的内容，它使得Bean能够避免远程调用的开销。请考虑以下的代码。
| PayBeanHome home = (PayBeanHome) javax.rmi.PortableRemoteObject.narrow (ctx.lookup ("PayBeanHome"), PayBeanHome.class); PayBean bean = (PayBean) javax.rmi.PortableRemoteObject.narrow (home.create(), PayBean.class); |
第一个语句表示我们要寻找Bean的Home接口。这个查找通过JNDI进行，它是一个RMI调用。然后，我们定位远程对象，返回代理引用，这也是一个RMI调用。第二个语句示范了怎样创建一个实例。涉及了创建IIOP请求并在网络上传输请求的stub程序，它也是一个RMI调用。
要实现本地接口，我们必须作例如以下改动：
- 方法不能再抛出java.rmi.RemoteException异常。包括从RemoteException派生的异常，比方TransactionRequiredException、TransactionRolledBackException和NoSuchObjectException。
EJB提供了等价的本地异常，如TransactionRequiredLocalException、TransactionRolledBackLocalException和NoSuchObjectLocalException。
- 全部数据和返回值都通过引用的方式传递，而不是传递值。
- 本地接口必须在EJB部署的机器上使用。
简而言之，客户程序和提供服务的组件必须在同一个JVM上运行。
- 假设Bean实现了本地接口。则其引用不可串行化。
请參见《用本地引用提高EJB訪问效率》。
2.7 生成主键
在EJB之内生成主键有很多途径，以下分析了几种常见的办法以及它们的特点。
利用数据库内建的标识机制（SQL Server的IDENTITY或Oracle的SEQUENCE）。这样的方法的缺点是EJB可移植性差。
由实体Bean自己计算主键值（比方做增量操作）。
它的缺点是要求事务可串行化，并且速度也较慢。
利用NTP之类的时钟服务。
这要求有面向特定平台的本地代码，从而把Bean固定到了特定的OS之上。另外。它还导致了这样一种可能，即在多CPU的server上，同一个毫秒之内生成了两个主键。
借鉴Microsoft的思路，在Bean中创建一个GUID。然而，假设不求助于JNI，Java不能确定网卡的MAC地址；假设使用JNI。则程序就要依赖于特定的OS。
还有其它几种办法。但这些办法相同都有各自的局限。
似乎仅仅有一个答案比較理想：结合运用RMI和JNDI。先通过RMI注冊把RMI远程对象绑定到JNDI树。
客户程序通过JNDI进行查找。以下是一个样例：
| public class keyGenerator extends UnicastRemoteObject implements Remote { private static long KeyValue = System.currentTimeMillis(); public static synchronized long getKey() throws RemoteException { return KeyValue++; } |
2.8 及时清除不再须要的会话
为了清除不再活动的会话，很多应用server都有默认的会话超时时间，一般为30分钟。当应用server须要保存很多其它会话时，假设内存容量不足，操作系统会把部分内存数据转移到磁盘，应用server也可能依据“近期最频繁使用”（Most Recently Used）算法把部分不活跃的会话转储到磁盘，甚至可能抛出“内存不足”异常。在大规模系统中，串行化会话的代价是非常昂贵的。
当会话不再须要时。应当及时调用HttpSession.invalidate()方法清除会话。
HttpSession.invalidate()方法通常能够在应用的退出页面调用。
2.9 在JSP页面中关闭没用的会话
对于那些无需跟踪会话状态的页面，关闭自己主动创建的会话能够节省一些资源。使用例如以下page指令：
| <%@ page session="false"%> |
2.10 Servlet与内存使用
很多开发人员任意地把大量信息保存到用户会话之中。
一些时候，保存在会话中的对象没有及时地被垃圾回收机制回收。从性能上看，典型的症状是用户感到系统周期性地变慢。却又不能把原因归于不论什么一个详细的组件。假设监视JVM的堆空间，它的表现是内存占用不正常地大起大落。
解决这类内存问题主要有二种办法。第一种办法是。在全部作用范围为会话的Bean中实现HttpSessionBindingListener接口。这样，仅仅要实现valueUnbound()方法，就能够显式地释放Bean使用的资源。
第二种办法就是尽快地把会话作废。大多数应用server都有设置会话作废间隔时间的选项。另外，也能够用编程的方式调用会话的setMaxInactiveInterval()方法。该方法用来设定在作废会话之前。Servlet容器同意的客户请求的最大间隔时间。以秒计。
2.11 HTTP Keep-Alive
Keep-Alive功能使client到server端的连接持续有效，当出现对server的后继请求时，Keep-Alive功能避免了建立或者又一次建立连接。市场上的大部分Webserver，包括iPlanet、IIS和Apache，都支持HTTP Keep-Alive。
对于提供静态内容的站点来说。这个功能通常非常实用。
可是，对于负担较重的站点来说，这里存在另外一个问题：尽管为客户保留打开的连接有一定的优点，但它相同影响了性能。由于在处理暂停期间，本来能够释放的资源仍旧被占用。当Webserver和应用server在同一台机器上运行时，Keep-Alive功能对资源利用的影响尤其突出。
2.12 JDBC与Unicode
想必你已经了解一些使用JDBC时提高性能的措施，比方利用连接池、正确地选择存储过程和直接运行的SQL、从结果集删除多余的列、预先编译SQL语句，等等。
除了这些显而易见的选择之外，还有一个提高性能的好选择可能就是把全部的字符数据都保存为Unicode（代码页13488）。Java以Unicode形式处理全部数据。因此，数据库驱动程序不必再运行转换过程。但应该记住：假设採用这样的方式。数据库会变得更大，由于每个Unicode字符须要2个字节存储空间。另外。假设有其它非Unicode的程序訪问数据库。性能问题仍旧会出现。由于这时数据库驱动程序仍旧必须运行转换过程。
2.13 JDBC与I/O
假设应用程序须要訪问一个规模非常大的数据集，则应当考虑使用块提取方式。
默认情况下。JDBC每次提取32行数据。举例来说。假设我们要遍历一个5000行的记录集，JDBC必须调用数据库157次才干提取到全部数据。假设把块大小改成512，则调用数据库的次数将降低到10次。
在一些情形下这样的技术无效。
比如。假设使用可滚动的记录集，或者在查询中指定了FOR UPDATE，则块操作方式不再有效。
1.14 内存数据库
很多应用须要以用户为单位在会话对象中保存相当数量的数据。典型的应用如购物篮和文件夹等。由于这类数据能够依照行/列的形式组织，因此，很多应用创建了庞大的Vector或HashMap。
在会话中保存这类数据极大地限制了应用的可伸缩性，由于server拥有的内存至少必须达到每个会话占用的内存数量乘以并发用户最大数量，它不仅使server价格昂贵，并且垃圾收集的时间间隔也可能延长到难以忍受的程度。
一些人把购物篮/文件夹功能转移到数据库层，在一定程度上提高了可伸缩性。
然而，把这部分功能放到数据库层也存在问题。且问题的根源与大多数关系数据库系统的体系结构有关。对于关系数据库来说，运行时的重要原则之中的一个是确保全部的写入操作稳定、可靠。因而。全部的性能问题都与物理上把数据写入磁盘的能力有关。
关系数据库力图降低I/O操作，特别是对于读操作，但实现该目标的主要途径仅仅是运行一套实现缓冲机制的复杂算法，而这正是数据库层第一号性能瓶颈通常总是CPU的主要原因。
一种替代传统关系数据库的方案是，使用在内存中运行的数据库（In-memory Database），比如TimesTen。
内存数据库的出发点是同意数据暂时地写入，但这些数据不必永久地保存到磁盘上。全部的操作都在内存中进行。这样。内存数据库不须要复杂的算法来降低I/O操作。并且能够採用比較简单的加锁机制，因而速度非常快。
三、GUI篇
这一部分介绍的内容适合于图形用户界面的应用（Applet和普通应用）。要用到AWT或Swing。
3.1 用JAR压缩类文件
Java档案文件（JAR文件）是依据JavaBean标准压缩的文件。是公布JavaBean组件的主要方式和推荐方式。
JAR档案有助于降低文件体积，缩短下载时间。
比如。它有助于Applet提高启动速度。一个JAR文件能够包括一个或者多个相关的Bean以及支持文件，比方图形、声音、HTML和其它资源。
要在HTML/JSP文件里指定JAR文件，仅仅需在Applet标记中增加ARCHIVE = "name.jar"声明。
请參见《使用档案文件提高 applet 的载入速度》。
3.2 提示Applet装入进程
你是否看到过使用Applet的站点，注意到在应该运行Applet的地方出现了一个占位符？当Applet的下载时间较长时，会发生什么事情？最大的可能就是用户掉头离去。在这样的情况下，显示一个Applet正在下载的信息无疑有助于鼓舞用户继续等待。
以下我们来看看一种详细的实现方法。
首先创建一个非常小的Applet，该Applet负责在后台下载正式的Applet：
| import java.applet.Applet; import java.applet.AppletStub; import java.awt.Label; import java.awt.Graphics; import java.awt.GridLayout; public class PreLoader extends Applet implements Runnable, AppletStub { String largeAppletName; Label label; public void init() { // 要求装载的正式Applet largeAppletName = getParameter("applet"); // “请稍等”提示信息 label = new Label("请稍等..." + largeAppletName); add(label); } public void run(){ try { // 获得待装载Applet的类 Class largeAppletClass = Class.forName(largeAppletName); // 创建待装载Applet的实例 Applet largeApplet = (Applet)largeAppletClass.newInstance(); // 设置该Applet的Stub程序 largeApplet.setStub(this); // 取消“请稍等”信息 remove(label); // 设置布局 setLayout(new GridLayout(1, 0)); add(largeApplet); // 显示正式的Applet largeApplet.init(); largeApplet.start(); } catch (Exception ex) { // 显示错误信息 label.setText("不能装入指定的Applet"); } // 刷新屏幕 validate(); } public void appletResize(int width, int height) { // 把appletResize调用从stub程序传递到Applet resize(width, height); } } |
编译后的代码小于2K。下载速度非常快。
代码中有几个地方值得注意。首先，PreLoader实现了AppletStub接口。
一般地，Applet从调用者推断自己的codebase。
在本例中，我们必须调用setStub()告诉Applet到哪里提取这个信息。
还有一个值得注意的地方是，AppletStub接口包括很多和Applet类一样的方法，但appletResize()方法除外。这里我们把对appletResize()方法的调用传递给了resize()方法。
3.3 在画出图形之前预先装入它
ImageObserver接口可用来接收图形装入的提示信息。ImageObserver接口仅仅有一个方法imageUpdate()，能够用一次repaint()操作在屏幕上画出图形。
以下提供了一个样例。
| public boolean imageUpdate(Image img, int flags, int x, int y, int w, int h) { if ((flags & ALLBITS) !=0 { repaint(); } else if (flags & (ERROR |ABORT )) != 0) { error = true; // 文件没有找到，考虑显示一个占位符 repaint(); } return (flags & (ALLBITS | ERROR| ABORT)) == 0; } |
当图形信息可用时，imageUpdate()方法被调用。假设须要进一步更新，该方法返回true；假设所需信息已经得到，该方法返回false。
3.4 覆盖update方法
update()方法的默认动作是清除屏幕，然后调用paint()方法。假设使用默认的update()方法，频繁使用图形的应用可能出现显示闪烁现象。
要避免在paint()调用之前的屏幕清除操作，仅仅需依照例如以下方式覆盖update()方法：
| public void update(Graphics g) { paint(g); } |
更理想的方案是：覆盖update()，仅仅重画屏幕上发生变化的区域，例如以下所看到的：
| public void update(Graphics g) { g.clipRect(x, y, w, h); paint(g); } |
3.5 延迟重画操作
对于图形用户界面的应用来说，性能低下的主要原因往往能够归结为重画屏幕的效率低下。当用户改变窗体大小或者滚动一个窗体时。这一点通常能够非常明显地观察到。改变窗体大小或者滚动屏幕之类的操作导致重画屏幕事件大量地、高速地生成，甚至超过了相关代码的运行速度。
对付这个问题最好的办法是忽略全部“迟到”的事件。
建议在这里引入一个数毫秒的时差，即假设我们马上接收到了还有一个重画事件，能够停止处理当前事件转而处理最后一个收到的重画事件。否则。我们继续进行当前的重画过程。
假设事件要启动一项耗时的工作，分离出一个工作线程是一种较好的处理方式。否则。一些部件可能被“冻结”，由于每次仅仅能处理一个事件。以下提供了一个事件处理的简单样例，但经过扩展后它能够用来控制工作线程。
| public static void runOnce(String id, final long milliseconds) { synchronized(e_queue) { // e_queue: 全部事件的集合 if (!e_queue.containsKey(id)) { e_queue.put(token, new LastOne()); } } final LastOne lastOne = (LastOne) e_queue.get(token); final long time = System.currentTimeMillis(); // 获得当前时间 lastOne.time = time; (new Thread() {public void run() { if (milliseconds > 0) { try {Thread.sleep(milliseconds);} // 暂停线程 catch (Exception ex) {} } synchronized(lastOne.running) { // 等待上一事件结束 if (lastOne.time != time) // 仅仅处理最后一个事件 return; } }}).start(); } private static Hashtable e_queue = new Hashtable(); private static class LastOne { public long time=0; public Object running = new Object(); } |
3.6 使用双缓冲区
在屏幕之外的缓冲区绘图，完毕后马上把整个图形显示出来。由于有两个缓冲区，所以程序能够来回切换。这样。我们能够用一个低优先级的线程负责绘图，使得程序能够利用空暇的CPU时间运行其它任务。
以下的伪代码片断示范了这样的技术。
| Graphics myGraphics; Image myOffscreenImage = createImage(size().width, size().height); Graphics offscreenGraphics = myOffscreenImage.getGraphics(); offscreenGraphics.drawImage(img, 50, 50, this); myGraphics.drawImage(myOffscreenImage, 0, 0, this); |
3.7 使用BufferedImage
Java JDK 1.2使用了一个软显示设备，使得文本在不同的平台上看起来类似。
为实现这个功能。Java必须直接处理构成文字的像素。由于这样的技术要在内存中大量地进行位复制操作，早期的JDK在使用这样的技术时性能不佳。为解决问题而提出的Java标准实现了一种新的图形类型，即BufferedImage。
BufferedImage子类描写叙述的图形带有一个可訪问的图形数据缓冲区。一个BufferedImage包括一个ColorModel和一组光栅图形数据。这个类一般使用RGB（红、绿、蓝）颜色模型。但也能够处理灰度级图形。
它的构造函数非常easy，例如以下所看到的：
| public BufferedImage (int width, int height, int imageType) |
ImageType同意我们指定要缓冲的是什么类型的图形，比方5-位RGB、8-位RGB、灰度级等。
3.8 使用VolatileImage
很多硬件平台和它们的操作系统都提供主要的硬件加速支持。比如，硬件加速一般提供矩形填充功能，和利用CPU完毕同一任务相比，硬件加速的效率更高。由于硬件加速分离了一部分工作。同意多个工作流并发进行。从而缓解了对CPU和系统总线的压力，使得应用能够运行得更快。利用VolatileImage能够创建硬件加速的图形以及管理图形的内容。由于它直接利用低层平台的能力，性能的改善程度主要取决于系统使用的图形适配器。
VolatileImage的内容随时可能丢失，也即它是“不稳定的（volatile）”。
因此，在使用图形之前，最好检查一下它的内容是否丢失。VolatileImage有两个能够检查内容是否丢失的方法：
| public abstract int validate(GraphicsConfiguration gc); public abstract Boolean contentsLost(); |
每次从VolatileImage对象复制内容或者写入VolatileImage时，应该调用validate()方法。contentsLost()方法告诉我们，自从最后一次validate()调用之后。图形的内容是否丢失。
尽管VolatileImage是一个抽象类，但不要从它这里派生子类。VolatileImage应该通过Component.createVolatileImage()或者GraphicsConfiguration.createCompatibleVolatileImage()方法创建。
3.9 使用Window Blitting
进行滚动操作时，全部可见的内容一般都要重画。从而导致大量不必要的重画工作。很多操作系统的图形子系统，包括WIN32 GDI、MacOS和X/Windows。都支持Window Blitting技术。Window Blitting技术直接在屏幕缓冲区中把图形移到新的位置，仅仅重画新出现的区域。要在Swing应用中使用Window Blitting技术。设置方法例如以下：
| setScrollMode(int mode); |
在大多数应用中。使用这样的技术能够提高滚动速度。
仅仅有在一种情形下，Window Blitting会导致性能降低，即应用在后台进行滚动操作。假设是用户在滚动一个应用，那么它总是在前台。无需操心不论什么负面影响