Java NIO和IO的主要区别
| IO | NIO |
| 面向Stream | 面向Buffer |
| 阻塞IO | 非阻塞IO |
| Selectors |
面向Stream和面向Buffer
Java NIO和IO之间最大的区别是IO是面向流（Stream）的，NIO是面向块（buffer）的，所以，这意味着什么？
面向流意味着从流中一次可以读取一个或多个字节，拿到读取的这些做什么你说了算，这里没有任何缓存（这里指的是使用流没有任何缓存，接收或者发送的数据是缓存到操作系统中的，流就像一根水管从操作系统的缓存中读取数据）而且只能顺序从流中读取数据，如果需要跳过一些字节或者再读取已经读过的字节，你必须将从流中读取的数据先缓存起来。
面向块的处理方式有些不同，数据是先被 读/写到buffer中的，根据需要你可以控制读取什么位置的数据。这在处理的过程中给用户多了一些灵活性，然而，你需要额外做的工作是检查你需要的数据是否已经全部到了buffer中，你还需要保证当有更多的数据进入buffer中时，buffer中未处理的数据不会被覆盖
阻塞IO和非阻塞IO
所有的Java IO流都是阻塞的，这意味着，当一条线程执行read()或者write()方法时，这条线程会一直阻塞知道读取到了一些数据或者要写出去的数据已经全部写出，在这期间这条线程不能做任何其他的事情
java NIO的非阻塞模式(Java NIO有阻塞模式和非阻塞模式，阻塞模式的NIO除了使用Buffer存储数据外和IO基本没有区别)允许一条线程从channel中读取数据，通过返回值来判断buffer中是否有数据，如果没有数据，NIO不会阻塞，因为不阻塞这条线程就可以去做其他的事情，过一段时间再回来判断一下有没有数据
NIO的写也是一样的，一条线程将buffer中的数据写入channel，它不会等待数据全部写完才会返回，而是调用完write()方法就会继续向下执行
具体的原理实现:
整个IO过程的流程如下：
1）程序员写代码创建一个缓冲区（这个缓冲区是用户缓冲区）：哈哈。然后在一个while循环里面调用read()方法读数据(触发"syscall read"系统调用)
byte[] b = new byte[1024]; while((read = inputStream.read(b))>=0) { total = total + read; // other code.... }
2)当执行到read()方法时，其实底层是发生了很多操作的：
①内核给磁盘控制器发命令说：我要读磁盘上的某某块磁盘块上的数据。--kernel issuing a command to the disk controller hardware to fetch the data from disk.
②在DMA的控制下，把磁盘上的数据读入到内核缓冲区。--The disk controller writes the data directly into a kernel memory buffer by DMA
③内核把数据从内核缓冲区复制到用户缓冲区。--kernel copies the data from the temporary buffer in kernel space
这里的用户缓冲区应该就是我们写的代码中 new 的 byte[] 数组。
从上面的步骤中可以分析出什么？
ⓐ对于操作系统而言，JVM只是一个用户进程，处于用户态空间中。而处于用户态空间的进程是不能直接操作底层的硬件的。而IO操作就需要操作底层的硬件，比如磁盘。因此，IO操作必须得借助内核的帮助才能完成(中断，trap)，即：会有用户态到内核态的切换。
ⓑ我们写代码 new byte[] 数组时，一般是都是“随意” 创建一个“任意大小”的数组。比如，new byte[128]、new byte[1024]、new byte[4096]....
但是，对于磁盘块的读取而言，每次访问磁盘读数据时，并不是读任意大小的数据的，而是：每次读一个磁盘块或者若干个磁盘块(这是因为访问磁盘操作代价是很大的，而且我们也相信局部性原理) 因此，就需要有一个“中间缓冲区”--即内核缓冲区。先把数据从磁盘读到内核缓冲区中，然后再把数据从内核缓冲区搬到用户缓冲区。
这也是为什么我们总感觉到第一次read操作很慢，而后续的read操作却很快的原因吧。因为，对于后续的read操作而言，它所需要读的数据很可能已经在内核缓冲区了，此时只需将内核缓冲区中的数据拷贝到用户缓冲区即可，并未涉及到底层的读取磁盘操作，当然就快了。
The kernel tries to cache and/or prefetch data, so the data being requested by the process may already be available in kernel space.
If so, the data requested by the process is copied out.
If the data isn't available, the process is suspended while the kernel goes about bringing the data into memory.
如果数据不可用，process将会被挂起，并需要等待内核从磁盘上把数据取到内核缓冲区中。
那我们可能会说：DMA为什么不直接将磁盘上的数据读入到用户缓冲区呢？一方面是 ⓑ中提到的内核缓冲区作为一个中间缓冲区。用来“适配”用户缓冲区的“任意大小”和每次读磁盘块的固定大小。另一方面则是，用户缓冲区位于用户态空间，而DMA读取数据这种操作涉及到底层的硬件，硬件一般是不能直接访问用户态空间的（OS的原因吧）
综上，由于DMA不能直接访问用户空间(用户缓冲区)，普通IO操作需要将数据来回地在 用户缓冲区 和 内核缓冲区移动，这在一定程序上影响了IO的速度。那有没有相应的解决方案呢？
那就是直接内存映射IO，也即JAVA NIO中提到的内存映射文件，或者说 直接内存....总之，它们表达的意思都差不多。示例图如下：
从上图可以看出：内核空间的 buffer 与 用户空间的 buffer 都映射到同一块 物理内存区域。
它的主要特点如下：
①对文件的操作不需要再发read 或者 write 系统调用了---The user process sees the file data asmemory, so there is no need to issue read() or write() system calls.
②当用户进程访问“内存映射文件”地址时，自动产生缺页错误，然后由底层的OS负责将磁盘上的数据送到内存。关于页式存储管理，可参考：内存分配与内存管理的一些理解
As the user process touches the mapped memory space, page faults will be generated automatically to bring in the file data from disk.
If the user modifies the mapped memory space, the affected page is automatically marked as dirty and will be subsequently
flushed to disk to update the file.
这就是是JAVA NIO中提到的内存映射缓冲区（Memory-Mapped-Buffer）它类似于JAVA NIO中的直接缓冲区(Directed Buffer)。MemoryMappedBuffer可以通过java.nio.channels.FileChannel.java(通道)的 map方法创建。
使用内存映射缓冲区来操作文件，它比普通的IO操作读文件要快得多。甚至比使用文件通道(FileChannel)操作文件 还要快。因为，使用内存映射缓冲区操作文件时，没有显示的系统调用(read,write)，而且OS还会自动缓存一些文件页(memory page)
追加的只是:
缓冲区的出现是为了减少频繁的系统调用，由于系统调用需要保存之前的进程数据和状态等信息，而结束调用之后回来还需要回复之前的信息，为了减少这种耗时耗性能的调用于是出现了缓冲区。在linux系统中，每个进程有自己独立的缓冲区，叫做进程缓冲区，而系统内核也有个缓冲区叫做内核缓冲区。
当进程需要指定的磁盘数据的时候，进程先到内核缓冲区去看看数据是否在内核缓冲区，如果没有，内核把读取磁盘中此数据的请求添加到内核的请求队列，然后挂起此进程，等解决了别的进程的问题之后，磁盘中的数据也读取到了内核缓冲区，然后复制数据到进程缓冲区，接着唤醒这个被挂起的进程，进程从自己的进程缓冲区中拿到数据，然后继续工作。
但是一般的操作系统在存储数据的时候也并不是立即存储的，这个是磁盘文件系统设计的问题，有些UNIX操作系统除外，相对数据安全，但是IO不可避免的会降低。操作系统使用read函数把数据从内核缓冲区复制到进程缓冲区，write把数据从进程缓冲区 复制到内核缓冲区中。至于什么时候读取和存储则由内核来决定，内核缓冲区满则存储到磁盘，读取的时候内核缓冲区空则从磁盘读取到内核缓冲区中，当然，在写入的时候如果系统突然关闭则会造成内核缓冲区的数据无法存储到磁盘的事情发生。