两种方法定位Java应用程序瓶颈(2)

核心提示：继续最优化代码在上面的剖析输出中，最顶端的项起源于GUI事件循环，两种方法定位Java应用程序瓶颈(2)，一旦我们使GUI对象可见（即调用setVisible(true)），事件循环就开始了，这两种方法的要害就是缓冲区的大小， allocateDirect() 产生一个以字节为单位的直接型缓冲区，这个循环将持续应用的整

　　继续最优化代码
　　在上面的剖析输出中，最顶端的项起源于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。