IO流与NIO块的数据缓存
Java的IO是面向流设计的，通常我们通过IO流读取数据，只能指定读取数据的大小，而不能选择数据读取的起始位置。数据就像流水一样，流过我们的应用，一旦流过就无法回头。除非我们的代码对所读取的数据进行缓存，否则就再也见不到它了（针对此次流操作）。
比如，我们创建一个byte[]数组来进行数据缓存，稍后可根据需要再次读取数组内的数据。但是有一点不方便的就是，如果我们要复用一个byte[]数组，即我们只处理了其中一部分数据，但是想用这个数组的剩余空间读入新数据。那我们就要在代码中维护一个偏移量offset，来告诉read操作，读取到的数据该从哪里开始存放。
但是，如果使用NIO的ByteBuffer，就相对来说方便的多，它内部有维护几个字段，只要用户在对其进行读写后，正确地调用flip()方法，就可以复用缓冲对象。省去了维护偏移量的工作。
而Netty，进一步完善了缓冲对象，它的ByteBuf对象，内部维护两个索引（读写）。也就不用再调用flip()方法了，降低错误概率。
注意：BufferedXXStream里面的缓冲数组没有发布，也就是说，它只在其内部使用，我们外部引用不到。它只是用来减少系统调用的。
IO与NIO的读写效率
据说，在单线程场景下，IO的读写速度要高于NIO。（未考证）
NIO的主要优点是，当读写条件不满足的时候，即缓冲区内没有数据，或没有空间的时候（这里的缓冲区指的应该是内核空间）。执行IO操作的线程不会被阻塞，所谓阻塞，指的是线程是否会被挂起。那么在多线程场景下，我们就可以利用这个优点，即在当读写条件满足的时候再执行IO操作。这样就省去了一定的等待时间，这段时间内，此线程可以做其他事情，如给另一个满足读写条件的Channel进行读写。
那我们如何知晓哪些Channel满足读写条件呢？
答案就是Selector，Seletor可以筛选注册在其上的Channel。可读，或可写的Channel将被筛选出来。
那如果有多个Channel同时满足读写条件呢？
那就把满足条件的Channel，每个都执行一遍。可读的就读，可写的就写。
那这样时效性会不会比较差？
是的，会比较差。拿网络IO来讲，如果一个线程处理多个连接的操作，那么最好情况就是，这几个连接，同时读写的概率不大，或者读写的数据量很小，线程处理速度很快，这样其他读写任务就不会等太久。但是，如果，这多个线程同时读写概率大，或者读写数据量大，处理速度较慢，而又比较追求时效性的话，那么一个线程最好不要处理太多连接。
有了NIO，BIO就被放弃了吗？
BIO就是阻塞IO，那网络IO来讲，如果此线程调用read()操作，且缓冲区无数据可读的时候，此线程将一直阻塞（被挂起），直到有数据可读，才被唤醒。前面说了，NIO的使用场景是，一个线程会维护多个连接，如果多个Channel同时满足条件，那么其中最后一个Channel就要等待它前面的Channel完成读写操作后，才能开始任务。如果此连接比较追求时效性的话，即要求，自己发送数据，对方能立即响应并进行处理的话。那么就可以用BIO进行处理，即用一个专门的线程来监听一个连接，甚至一个连接的读或写操作。
个人认为，BIO就像是高速公路上的专用车道，平时用的不多，但是需要的时候，可以立即使用，且不用跟其他车辆竞争。