正在阅读：Java I/O API之性能分析 (下)Java I/O API之性能分析 (下)

　　prepareForResponse()方法构造出缓冲区responseLine以及（如果必要的话）应答头或错误信息，并把这些数据写入responseLineBuffer。这个ByteBuffer是一个byte数组的简单的封装器。生成待输出的数据之后，我们还要通知ConnectionSelector：从现在开始不再读取数据，而是要写入数据了。这个通知通过调用选择键的interestedOps(SelectionKey.OP_WRITE)方法完成。为了保证选择器能够迅速认识到连接操作状态的变化，接着还要调用wakeup()方法。接下来ConnectionSelector调用连接的writeResponse()方法。首先，responseLineBuffer被写入到Socket管道。如果缓冲区的内容全部被写入，而且还有被请求的文件需要发送，接着调用前面打开的FileChannel的transferTo()方法。transferTo()方法通常能够高效地把数据从文件传输到管道，但实际的传输效率依赖于底层的操作系统。任何时候，被传输的数据量至多相当于在无阻塞的情况下可写入目标管道的数据量。为安全和确保各个连接之间的公平起见，这里把上限设置成64 KB。

　　如果所有数据都已经传输完毕，close()执行清理工作。取消Connection的注册是这里的主要任务，具体通过调用键的cancel()方法完成。

　　这个新的方案性能如何呢？答案是肯定的。从原理上看，一个Acceptor和一个ConnectionSelector足以支持任意数量的打开的连接。因此，新的实现方案在可伸缩性方面占有优势。但是，由于两个线程必须通过同步的queue()方法通信，它们可能互相阻塞对方。解决这个问题有两种途径：

　　·改进实现队列的方法
　　·采用多个Acceptor/ConnectionSelector对

　　与Httpd相比，NIOHttpd的一个缺点是，对于每一个请求，就有一个新的带缓冲的Connection对象被创建。这就导致了垃圾收集器产生的额外的CPU占用，这部分附加代价的具体程度又与VM的类型有关。然而，Sun不厌其烦地强调说，有了Hotspot，短期生存的对象不再成为问题。

　　五、可伸缩性的定量分析和比较

　　在可伸缩性方面，NIOHttpd到底比Httpd好多少？下面我们来看看具体的数字。首先要声明的是，这里的数字具有大量的推测成分，一些重要的环境因素，例如线程同步、上下文切换、换页、硬盘速度和缓冲等，都没有考虑到。首先评估处理r个并发的请求需要多少时间，假设被请求的文件大小是s字节，客户端的带宽是b字节/秒。对于Httpd，这个时间显然直接依赖于线程的数量t，因为同一时刻只能处理t个请求。所以Httpd的处理时间可以从公式一得到，其中c是执行请求分析之类操作的开销常量，这个值对于每一个请求来说都是一样的。另外，这里假定从磁盘读取数据的速度总是快于写入Socket的速度，服务器带宽总是大于客户机带宽之和，且CPU未满载。因此，服务器端的带宽、缓冲和硬盘速度等因素都不必在该公式中考虑。

　　图一：公式一