前些日了，对AIO与NIO的并发性能进行了比较，在低并发的情况下，NIO性能表现比AIO好一些，主要原因是，NIO中可以使用FileChannel.transferTo(long position, long count, WritableByteChannel target)，这个方法可以对传输文件数据有很大的性能提升。

在AIO中，没办法使用FileChannel.transferTo(...),只能使用ByteBuffer来做中转，我一开始使用的ByteBuffer.allocate(16 * 1024),也就是16KB的缓存区。

由于上面的原因，所以NIO在不是很高的并发情况下，性能比AIO表现的好一些。

昨天，我还写了一篇文章：AsynchronousFileChannel 使用的默认线程池的疑问

今天早上，我试着将ByteBuffer由原来固定的16KB,更改为一个与传输的文件大小有关的字节缓存区。

相关代码如下：

//如果文件大小<1M,直接返回一个 fileSize + headerSize
 //如果文件大小>=1M,直接返回一个(fileSize + headerSize) / 2, 也就是最多保证分两次传输完数据
 private ByteBuffer allocateByteBuffer(int fileSize, int headerSize)
 {
  if(fileSize < 1024 * 1024)
  {
   return ByteBuffer.allocate(fileSize + headerSize);
  }
  else
  {
   return ByteBuffer.allocate((fileSize + headerSize) / 2 + 1); //这所以 +1, 因为 11 / 2 = 5,为了保证两次传完, + 1 可保证这一点
  }
 }

然后经过测试发现，在低并发情况下，性能上升了很多，终于赶上了NIO的性能，同时观察“任务管理器”中的进程使用的线程数也下降了很多，真是一举两得，这让我兴奋了好一会儿，

经过冷静的分析，我得出的结论：

之所以将ByteBuffer的大小设置为与传输的文件大小有关的缓存区后性能得到了很大的提升，主要与AIO的“写操作”有关。

举个例子：

在AIO的“写操作”中，如果我们设置ByteBuffer为一个固定的16KB的缓存区，当我们传输一个160KB的文件时，AIO的“写操作”需要执行10次“回调”。每1次的回调都是在系统默认的一个线程池中运行的，回调的次数与线程池中的线程数是成正比的。

如是我们将ByteBuffer设置为160KB，在进行AIO的“写操作”时，系统只执行了一次“回调”，回调的次数减少了，线程池的容量也不再需要那么多了，性能同时也上升了。

不过，经过测试也发现，ByteBuffer的容量也不能无限制的根据文件大小一设置，如果一个文件超过1M，还是最好设置为最大不超过1M的缓存区比较好，因为测试发现，如果设置一个很大的缓存区，比如5M，在高并发的时候，系统内存会很快用完，直接抛出： OutOfMemoryError

-------------------------------------------------------------------------------------------------

AIO进程占用的线程数与文件IO和网络IO有非常大的关系，当高并发的时候，网络IO达到瓶颈，这个时候很多任务都没有完成（正在完成中），占用的线程自然就会不断的上升。

2012-07-10