java NIO中，为什么没有文件的Channel类继承类AbstractSelectableChannel

最近看java.NIO的api，nio包是为了处理数据传输的速度和cpu执行的速度而引入的，DatagramChannel, Pipe.SinkChannel, Pipe.SourceChannel, ServerSocketChannel, SocketChannel
都继承了类AbstractSelectableChannel，为什么没有一个File的Channel或者File的工具类继承这个类,在网络数据传输的情况下我们可以通过nio轮询来增大吞吐量，为什么不能在多个大文件复制时使用这样一个工具类来处理硬盘读取速度和cpu处理速度上的差别？
jdk原先的设计中，InputStream的read()方法每次只读取一个字节，请问这是设计上的原因还是底层如此？
另外还有个问题，操作系统接收到的数据报如何传递给其对应的应用程序，在读取硬盘上的数据时每次读取多少，为什么要设计成返回一个字节？

java.nio.channels.FileChannel, FileOutputStream早就优化过了

java.nio.channels.FileChannel, FileOutputStream都是针对单个文件来说的，如果在处理多个文件的情况下呢

去读文件，最好是不要直接用InputStream的read方法，用BufferedInputStream相关的类。其次，read方法可以指定每次读取的块的大小，read(byte[] allocate).如果不指定，是一个一个字节从磁盘拷贝。效率极低。其次，还可以通过FileChannel去处理。

然后你前面的那些话，没看明白。。。。

按我的理解，你应该是想如何提高大文件的传输速度。你可以去看看mina.针对大文件，你可以通过读取文件后，分块上传。创建多个socket connector连接到同一个socket server.当然这个稍微复杂，你需要自己定义协议。包括服务器端断点续传啥的。

我知道最好用BufferedInputStream相关的类，但是看jdk的源码，BufferedInputStream相关的类的实现也是在InputStream的read方法的基础上，把数据一个字节一个字节的读到缓冲数组中，然后再返回；
我现在的疑问不是大文件复制，而是多个文件复制问题，为什么jdk nio中没有提供一个类似于niosocket那样的niofile类，在多个文件复制的情况下这个类应该很有用的

FileChannel.transferTo(long position, long count, WritableByteChannel target)
不需要你一个字节一个字节的读，而是从一个通道传入另一个通道，复制的话，用这个速度很快，

貌似以前的io复制的画，rt.jar下面有个DownloadManager.send(in,out)也是可以的，不过我看了看源码，也是一个字节一个字节的读的

我说的话就那么难以理解吗，OMG