这篇文章提出了两种方法来定位java应用程序中的性能瓶颈，而且提供了一些用于改善Java性能的建议。按照这种方法，您就会在新的java.nio包中看到一些类。
　　我做咨询时，最常听到的有关java的抱怨就是"它实在太慢了"、"它实在太耗费资源了"或者"它的性能是一个问题"。实际上，这些评论常常是缺乏依据的；许多人认为java的低劣性能是特定的。
　　当然，Java 程序可能会速度很慢、消耗内存并且使用起来很痛苦。但是，程序可以使用C++、Visual Basic、Smalltalk、Pascal、Ada或者C#来编写。那并不意味着编程语言或者运行环境很糟糕；或许这恰恰意味着开发者写代码的时候并没有考虑性能的副作用。一个编写校好的Java程序与使用其他语言编写的程序在性能方面通常是相当的，而且如果使用JDK 1.3 和1.4的性能改善， 它的性能可能会更好。
　　很重要的一点：可感知的性能是很关键的标准。如果您的代码看起来不能足够快的运行或者显示，它实际有多快、有多高效或者多优秀就变得无关紧要了。同样，拙劣的代码，其速度有时候也可能会惊人的快，不过维护它可就是一件棘手的事情。实际上，我们应该努力使代码同时具备两种品质：既优秀，又有良好性能来满足我们的客户需求。
　　为了能使您更易于接近上述目标，我将和您一起浏览性能改善流程。为了更好的进行解释，我将使用java.nio包中类的代码包括进来，这会在如何更高效使用这些类方面为您提供额外的提示。
　　性能改善流程
　　假设您自己编写或者继承了一个性能很差的应用程序，同时您的老板已经给您下了最后通牒，要求最迟下周完工上交，那么您将怎么办呢？
　　我设想您不会采取逃之夭夭的态度。您肯定想确定并解决性能问题。那么您又该从何处着手呢？
　　我强烈建议您使用下列的性能改善流程:
　　1.确定什么样的性能级别是足够好的；
　　2.在您所有的目标平台上进行测试；
　　3.如果所有目标平台的性能都相当不错，请停下来；不要忽略进行；也不要集中$200 ；
　　4.剖析您的应用以找到瓶颈；
　　5.重新构建或者重新编写代码来消除瓶颈；
　　6.返回步骤2
　　为了更好的说明这个流程，我们来看一个具体的例子。这个例子主要是关于AWT (Abstract Windowing Toolkit) 图形的，这是因为图形程序的性能改善更易于察觉而且编写起来更会引人入胜。
　　应用流程
　　下面的程序读取一系列的文件并对文件中字母a到z出现频率进行统计。它以柱状图的形式显示字母的出现频率；柱状图在读取一个文件之后就会得以更新。
　　检查下面的代码并在您认为的可改善之处加以标示。然后继续来看一下您自己的直觉判断是否正确。
　　import java.awt.Color;
　　import java.awt.Component;
　　import java.awt.Dimension;
　　import java.awt.Graphics;
　　import java.awt.Frame;
　　import java.io.IOException;
　　import java.io.FileInputStream;
　　
　　public class Letters extends Component {
　　 long[] countArray = new long[26];
　　 static char[] letterArray =
　　 {'a','b','c','d','e','f','g','h','i','j','k','l','m','n','o',
　　 'p','q','r','s','t','u','v','w','x','y','z'};
　　 /**
　　 * Find the number of occurrences of each letter of the
　　 * alphabet in the named file. The result is returned
　　 * as a 26-element array of long elements.
　　 * Of course, this will only work for the English alphabet.
　　 */
　　 void countCharacters (String filename)
　　 throws IOException {
　　 System.out.println ("...reading " + filename);
　　 FileInputStream fis =
　　 new FileInputStream (filename);
　　 int tmp;
　　 while ((tmp = fis.read()) != -1) {
　　 char c = Character.toLowerCase((char)tmp);
　　 int pos = c - 'a';
　　 if ((pos >= 0) && (pos <= 25)) {
　　 ++countArray[pos];
　　 }
　　 }
　　 fis.close();
　　 }
　　
　　 /**
　　 * Draw a histogram of the letter frequency.
　　 * This method is triggered by repaint(), or by
　　 * window manager repaint events.
　　 */
　　 public void paint (Graphics g) {
　　 long maxCount = 0;
　　 for (int i=0; i maxCount) maxCount = countArray[i];
　　 }
　　Dimension d = getSize();
　　 double yScale = ((double)d.height) / ((double)maxCount);
　　 int barWidth = (int)d.width / countArray.length;
　　 int x = 0;
　　 for (int j=0; j
　　这个程序的问题究竟是什么？我们又该如何来解决？我们还是按照流程来进行吧
　　步骤1: 确定什么样的性能级别是足够好的
　　如果程序能在10秒左右的时间里完成读取和处理javax.swing 包中的HTML文档，我自己就会武断的认为性能已经足够不错了。实际中，外部和政治因素经常会决定性能目标，这一点或许仍然是武断的。
　　步骤2: 在您所有的目标平台上进行测试；
　　我手边有两个工作站而且两个上面都运行JDK 1.4 。一个快速的Pentium 运行Windows (平台 A)而另一稍慢的运行Linux (平台 B)。在这两个平台上进行的测试表明读取并处理HTML文档平台A需要大约140秒的时间，而平台B需要153秒。唉，这两个离足够好这一目标还有好大差距。
　　步骤 3: 如果性能相当不错，请停下来；
　　我们并没有能够达到性能目标，因此我们仍要继续进行优化。
　　步骤 4: 剖析应用程序
　　您可使用多种方式剖析您的应用程序。许多剖析工具具有GUI (图形用户界面)前端；价格从免费到数千美元不等。请参见 Resources 进行选择。Sun Microsystems' JDK 就包含了进行剖析的hprof 工具，我也将使用该工具来说明剖析过程。
　　Hprof剖析器允许您对应用程序中感兴趣的进行追踪，这其中包括对象创建统计和方法配置文件。这个例子中我将使用方法剖析。对象创建信息在定位内存漏洞和碎片帐集问题方面是非常有价值的。为了获得hprof 选项列表，键入java -Xrunhprof:help. 在这个例子中，我使用java -Xrunhprof:cpu=samples,depth=15 Letters. 这将保证输出一个文件(java.hprof.txt)，其中包含了线程生命周期和每一方法所需花费时间的估计值信息。默认情况下，在程序结束时生成这个估计值。您也可以通过输入（Windows平台）或者 （Unix平台）来得到一个中间的快照。
　　运行程序在java.hprof.txt生成如下的输出：
　　CPU SAMPLES BEGIN (total = 3245) Sun Jul 14 18:18:03 2002
　　rank self accum count trace method
　　1 52.30% 52.30% 1697 25 sun.awt.windows.WToolkit.eventLoop
　　 2 45.30% 97.60% 1470 41 java.io.FileInputStream.read
　　3 0.52% 98.12% 17 45 java.awt.EventQueue.postEventPrivate
　　...
　　CPU SAMPLES END
　　这个例子中是按照顺序排列，最常使用的方法位于起始之处。通常您会关注最初的5到10项。现在我们将忽略第一项。通过在剖析输出中搜索字符串TRACE我们就可以找到第二项的相关信息。
　　TRACE 41:
　　 java.io.FileInputStream.read(FileInputStream.java:Native method)
　　 Letters.countCharacters(Letters.java:27)
　　 Letters.main(Letters.java:71)
　　我们花费了大量时间来调用countCharacters()中的FileInputStream.read()。看起来这是一个应该进行修改的地方。
　　如果您使用方法剖析技术找到了一个可疑的方法，您将会有好几个选项：
　　1.优化方法-使用更好的算法；
　　2.尽量减少调用该方法
　　3.根本就不调用该方法
　　步骤5: 重新构建或者重新编写代码来消除瓶颈
　　请您仔细观察一下代码，您就会发现输入是没有缓冲的。缓冲还是很有帮助的。使用BufferedInputStream就可以很容易的添加缓冲：
　　...import java.io.BufferedInputStream;
　　...
　　 void countCharacters (String filename)
　　 throws IOException {
　　 BufferedInputStream bis =
　　 new BufferedInputStream(new FileInputStream (filename));
　　 int tmp;
　　 while ((tmp = bis.read()) != -1) {
　　 char c = Character.toLowerCase((char)tmp);
　　 int pos = c - 'a';
　　 if ((pos >= 0) && (pos <= 25)) {
　　 ++countArray[pos];
　　 }
　　 }
　　 bis.close();
　　...
　　步骤6: 返回步骤2
　　对修改后的代码进行测试，产生如下结果：
　　● 平台 A: 时间在3.3 和 5.8 秒之间
　　● 平台B: 时间在18.6 和19.2 秒之间
　　虽然还不是足够好，但是已经好多了。让我们进行最优化；
　　
　　
　　
　　
　　

查看本文来源

　　继续最优化代码
　　在上面的剖析输出中，最顶端的项起源于GUI事件循环。一旦我们使GUI对象可见（即调用setVisible(true)），事件循环就开始了。这个循环将持续应用的整个生命周期。而且可以注意到在每一文件读取之后应用就会刷新图形。这一点在文件数目较大时更为重要。假设我们并不想查看中间的图形(就是说，这并不是一个公司的需求)，通过将图形显示移动到main()的末尾，我们就可以加快应用的速度。那么，事件循环直到应用的最后一刻才会启动，paint()也将很可能只需要被调用两次。
　　关于这一点，我们可能会产生这样的疑问：图形显示是否需要？它是否需要与应用同时显示？根据所做的回答，我们或许会将图形移动到另一线程、另一应用甚至另一机器。为了便于讨论，我们假设需要即时的图形显示。
　　修改后的main()如下:
　　 public static void main (String[] argv)
　　 throws IOException {
　　 Letters letters = new Letters();
　　 long startTime = System.currentTimeMillis();
　　 ...
　　 for (int i=0; i
　　修改后进行测试，产生如下结果：
　　● 平台 A: 时间在2.4 和 5 秒之间
　　● 平台B: 时间在11.6 和12.8 秒之间
　　我们已经大大改善了性能，但仍然没有达到我们的性能目标。
　　附加的剖析显示：
　　CPU SAMPLES BEGIN (total = 149) Sun Jul 14 19:53:50 2002
　　rank self accum count trace method
　　1 28.86% 28.86% 43 12 java.io.FileInputStream.readBytes
　　2 16.78% 45.64% 25 29 sun.awt.windows.WToolkit.init
　　3 16.11% 61.74% 24 30 sun.awt.windows.WToolkit.eventLoop
　　这和我们前面所看到的明显不同。我们花费的时间主要集中在readBytes()上，对readBytes()我们该怎么办呢？
　　JDK 1.4 引入了java.nio 包中一整套新类和它用于缓冲区I/O (输入/输出)的子包。有一个类，MappedByteBuffer看起来特别有用。我们可以使用MappedByteBuffer 对象在内存中高效表征一个文件的内容。这个类对缓冲区和内存管理的详细信息进行操作。
　　为了把MappedByteBuffer对象连接到文件，我们将使用FileChannel对象。 FileChannel 表征缓冲区与可进行读、写、映射和处理文件的文件之间一个可靠的线程连接。FileChannel对象保留文件当前位置信息并提供低级特定操作系统的最优化。JDK 1.4 文档包含了如何使用FileChannel和MappedByteBuffer的例子。
　　使用 FileChannel 和 MappedByteBuffer修改代码：
　　
　　...import java.nio.MappedByteBuffer;
　　import java.nio.channels.FileChannel;
　　...
　　 void countCharacters (String filename)
　　 throws IOException {
　　 FileInputStream fis = new FileInputStream(filename);
　　 FileChannel fc = fis.getChannel();
　　// Get the file's size and then map it into memory
　　 int sz = (int)fc.size();
　　 MappedByteBuffer bb = fc.map(FileChannel.MapMode.READ_ONLY, 0, sz);
　　
　　 for (int i=0; i= 0) && (pos <= 25)) {
　　 ++countArray[pos];
　　 }
　　 }
　　 fc.close();
　　 }
　　...
　　修改后产生如下结果：
　　● 平台 A: 时间在2.1 和 4.7 秒之间
　　● 平台B: 时间在11 和13.8 秒之间
　　这个结果较前一例子有了一些改善。然而，从统计或者可感知角度来说，这可能并不重要。
　　好了，另一个问题：我们应该如何达到我们的性能目标呢？这些文档能不能在10秒左右的时间内处理完毕？我们已经离这一目标很近了。我们将再尝试进行另一最优化。
　　我们来看一下 FileChannel.map()文档，描述的底端附近有一引人注意的引用。
　　对多数操作系统而言，将一文件映射到内存中比通过常用的读写方法来读写好多字节数据代价更高。从性能角度来说，将相对较大的文件映射到内存中才是值得的。
　　ByteBuffer 类，是MappedByteBuffer's 超类, 提供了java.nio 包中的可缓冲输入。我们试着使用ByteBuffer而不是MappedByteBuffer 来读取数据看看会发生什么事情。
　　ByteBuffer类的两种方法可以获得ByteBuffer: 方法allocate(int)和 allocateDirect(int)。这两种方法的关键就是缓冲区的大小。 allocateDirect() 产生一个以字节为单位的直接型缓冲区，它能尽可能的执行本地文件的I/O。 allocate()产生一个以字节为单位的非直接型缓冲区，它交换少量的本地代码用于具有决定性的行为(很可能会慢一些)。Sun推荐将以字节为单位的直接型缓冲区用于与大型文件相关并具有较长生命周期的缓冲区。
　　我们修改后的代码使用以字节为单位的直接型缓冲区：
　　...import java.nio.ByteBuffer;
　　...
　　 void countCharacters (String filename)
　　 throws IOException {
　　 FileInputStream fis = new FileInputStream(filename);
　　 FileChannel fc = fis.getChannel();
　　// Get the file's size and then map it into memory
　　 int sz = (int)fc.size();
　　 int bufferSize = 1024;
　　 ByteBuffer bb = ByteBuffer.allocateDirect (bufferSize);
　　 int nbytes = -1;
　　 while ((nbytes = fc.read (bb)) != -1) {
　　 bb.rewind();
　　 for (int i=0; i= 0) && (pos <= 25)) {
　　 ++countArray[pos];
　　 }
　　 }
　　 }
　　 fc.close();
　　 }
　　...
　　这一代码运行时间结果:
　　● 平台 A: 时间在2.7 和 5.2 秒之间
　　● 平台B: 时间在13.1 和13.9 秒之间
　　 使用 allocateDirect()替换allocate()将以20%的比例降低性能。性能比前一例子会少慢一些。代码也不是很容易阅读。可是，很有意思的一点，我在一个具有大约20个Java源文件的目录上使用相同的代码进行试验，结果得到了相反的结果。使用直接ByteBuffer编写的代码其速度要比使用MappedByteBuffer编写的代码快将近20%。这很可能与缓冲区和同步本地文件I/O操作所产生的附加花费有关。
　　所以…那一种最优化策略最好呢？这取决于应用是如何加以使用的。根据本文开始列出的需求，我将选择MappedByteBuffer版本。在我们的测试用例中它是最快的一个而且可以很好进行平衡。
　　重要的问题是：在我们进行最后一轮最优化测试之前，性能是否足够好了？如果已经足够好了，我们只是在花费额外时间进行并无直接好处的优化。如果性能仍然不令人满意，接下来的优化尝试很可能会更困难而且也十分耗时。
　　剖析如此重要的原因就是它告诉您要解决问题的信息，而且同时告诉您是否已经做到了这一点。有时候，花时间修改代码对性能并没有显著的影响。实际上或许仅仅使您的代码更难于阅读和维护。而且，您可能会对HotSpot VM 的优化策略感到意外-您不知道如何使Java程序运行的更快。
　　相同的改善流程对内存相关和I/O相关的性能问题一样有效。内存相关-内存漏洞和碎片帐集通常是最难追踪的。这是因为它们难于复制e而且观测程序或许会改变内存相关的行为。
　　改善性能的其他方法
　　一旦剖析确定了性能问题的位置，决定做什么仍然是需要小心处理的。这里的一些建议可用于解决特定的性能问题：
　　● 方法调用:优化方法,或者尽量少调用；
　　● 类读取：预先读取类，使用懒散的（命令触发）实例。注意：多线程程序中，避免使用两次检查的锁定（请参见Brian Goetz's "Double-Checked Locking: Clever, but Broken" (JavaWorld, February 2001)查明原因）；
　　● 在内存外运行: 共享对象而不是创建对象，可以使用对象工厂或者对象池；
　　● 字符串处理: 使用 StringBuffer 或者 char[]而不是String；
　　● 递归:消除递归方法调用并将其转换成迭代体
　　● I/O 和序列: 确保I/O是使用缓冲方法的。考虑使用非同步方法编写您自己的I/O子类；
　　● Collection类：使用满足应用的collection类,有时数组的访问和修改比collection更快。
　　性能改善的另一方法：使用字节型代码优化器。这些程序检查类文件字节代码，删除未被使用的代码，清空方法调用堆栈等。优化器最好的一点就是您不必修改任何代码-您只需测试一下看看优化器是否正常工作。令人不是很满意的地方就是优化器产生不可移植的代码或代码并未按照您所期望的方式工作。
　　调整程序
　　可感知性能比实际性能更重要。在您开始调整之前，决定如何判定什么时候性能就是足够好了。需要调整时，测试并剖析。如果它们还是有区别的，新的1.4 I/O 类可提供性能改善功能。剖析、剖析、再剖析。高效使用您的时间。不要更改代码而且在获得满意的性能之后就不必再调整。
　　
　　
　　
　　
　　
　　
　　

查看本文来源