关于NIO一些优化

1. 使用NIO开发web服务,传输文件内容，可以使用FileChannel.transferTo(position,count,socketChannel)来提升性能：

经过测试，确实能提升10% - 30%的处理性能。

相关提示链接：(mina) http://414149609.iteye.com/blog/1186036

API文档介绍：

public abstract long transferTo(long position, long count,  target) throws

将字节从此通道的文件传输到给定的可写入字节通道。

试图读取从此通道的文件中给定 position 处开始的 count 个字节，并将其写入目标通道。此方法的调用不一定传输所有请求的字节；是否传输取决于通道的性质和状态。如果此通道的文件从给定的 position 处开始所包含的字节数小于 count 个字节，或者如果目标通道是非阻塞的并且其输出缓冲区中的自由空间少于 count 个字节，则所传输的字节数要小于请求的字节数。

此方法不修改此通道的位置。如果给定的位置大于该文件的当前大小，则不传输任何字节。如果目标通道中有该位置，则从该位置开始写入各字节，然后将该位置增加写入的字节数。

与从此通道读取并将内容写入目标通道的简单循环语句相比，此方法可能高效得多。很多操作系统可将字节直接从文件系统缓存传输到目标通道，而无需实际复制各字节。

参数：

position - 文件中的位置，从此位置开始传输；必须为非负数

count - 要传输的最大字节数；必须为非负数

target - 目标通道

返回：实际已传输的字节数，可能为零抛出：- 如果关于参数的前提不成立- 如果不允许从此通道进行读取操作- 如果目标通道不允许进行写入操作- 如果此通道或目标通道已关闭- 如果正在进行传输时另一个线程关闭了任一通道- 如果正在进行传输时另一个线程中断了当前线程，因此关闭了两个通道并将当前线程设置为中断- 如果发生其他 I/O 错误

2. NIO的输出缓存区可以设置的大一些：

.allocate(int capacity)

以前我们常用8192(8K),现在使用NIO，可以使用 16384(16K)，经过测试也能提高一些性能。

相关文章：NIO trick and trap NIO的技巧与陷阱http://www.blogjava.net/cooperzh/archive/2011/12/20/366884.html

分析完mina2.0和grizzly2.0对Selector的管理后(http://www.blogjava.net/killme2008/default.html?page=17)我们可以得到几个启示：

1、在处理大量连接的情况下，多个Selector比单个Selector好
2、多个Selector的情况下，处理OP_READ和OP_WRITE的Selector要与处理OP_ACCEPT的Selector分离，也就是说处理接入应该要一个单独的Selector对象来处理，避免IO读写事件影响接入速度。
3、Selector的数目问题，mina默认是cpu+2，而grizzly总共就2个，我更倾向于mina的策略，但是我认为应该对cpu个数做一个判断，如果CPU个数超过8个，那么更多的Selector线程可能带来比较大的线程切换的开销，mina默认的策略并非合适，幸好可以设置这个数值。

2012-06-18