java nio
Java中nio有3个核心概念：channel，buffer，selector，在网络nio中，把channel的事件注册到selector，当网络就绪后进行读写操作，channel之间通过buffer传递数据。
Channel
一共有4种通道：
- FileChannel
- SocketChannel 基于TCP协议
- ServerSocketChannel 基于TCP协议
- DatagramChannel 基于UDP协议
Socket nio适用于类型http服务器等大并发，小数据量的场景，当数据量大，并发数小时传统io就可以
File nio中的map内存映射技术只适合于大文件，对于数k大小的文件，传统的read、write性能更好
Nio的主要改进：
- 网络io，非阻塞，消耗更少的cpu，支持更大的并发处理
- 文件io，提供文件映射，对大文件处理更加高效，并提供了FileChannel.transferTo()的零copy的高效io，关于零copy可以参看该文章：http://www.ibm.com/developerworks/cn/java/j-zerocopy/
- 提供buffer缓冲区，把之前的一个一个字节的流式读写改为面向缓冲区的数据块状处理，更加贴近操作系统的处理方式，效率更高，而且可以分配直接的缓冲区，该缓冲区可以直接操作操作系统的缓存区（关于直接缓存区可参看后面的内容），在传统io中有一些比如BufferInputStream类，但是这些类的buffer方法根源上也是一个字节一个字节的处理。
在Java中当我们要对数据进行更底层的操作时，通常是操作数据的字节（byte）形式，这时常常会用到ByteBuffer这样一个类。ByteBuffer提供了两种静态实例方式：
- public static ByteBuffer allocate(int capacity)
- public static ByteBuffer allocateDirect(int capacity)
为什么要提供两种方式呢？这与Java的内存使用机制有关。第一种分配方式产生的内存开销是在JVM中的，而第二种的分配方式产生的开销在JVM之外，以就是系统级的内存分配。当Java程序接收到外部传来的数据时，首先是被系统内存所获取，然后在由系统内存复制拷贝到JVM内存中供Java程序使用。所以在第二种分配方式中，可以省去复制这一步操作，效率上会有所提高。但是系统级内存的分配比起JVM内存的分配要耗时得多，所以并不是任何时候allocateDirect的操作效率都是最高的。下面是一个不同容量情况下两种分配方式的操作时间对比：
由图可以看出，当操作数据量很小时，两种分配方式操作使用时间基本是相同的，第一种方式有时可能会更快，但是当数据量很大时，第二种方式会远远大于第一种的分配方式。