很简单 100个请求过来了，每个请求都会有三个事件 ，accept,read writem ,如果只有一个主线程轮训，每遍历到一个事件都得线性的去处理他，等处理完了再处理第二个时间，如果有个write的写操作要写很多数据，那也得等这个write写完了再处理下一个， 要改善这种情况，还得用一个新线程去处理，或是线程池任务队列之类的处理也好，这样就不至于非得等到上一个事件处理完，那这样又回到了之前的阻塞socket多线程处理用户请求的模式了，
非阻塞，非阻塞其实就是channel的write和read不会阻塞，读不到或是写不出去方法会马上返回，但是如果你能读有能写，但是得花时间读写呢，我想这样其实和单线程处理所有请求的情况一样了吧 。
上面第一个write多打了个m,手抖了
NIO使用要看场景的。非阻塞的方式对系统的性能提升还是有帮助的。
>>非阻塞，非阻塞其实就是channel的write和read不会阻塞，读不到或是写不出去方法会马上返回，但是如果你能读有能写，但是得花时间读写呢，我想这样其实和单线程处理所有请求的情况一样了吧 。
首先如果有读有写，还得花时间读写呢？这个是同步IO和异步IO的问题，异步IO可以不让应用程序关心怎么读写数据，只需要传递内存缓存区给内核就OK了，内核负责读取，但是目前JAVA的IO都是同步IO,NIO属于同步非阻塞IO。
至于非阻塞IO肯定是有好处，比如在使用同步阻塞IO的时候，因为线程是一种很昂贵的资源，如果每一个请求过来，都分配一个线程处理的话，就会因为某些任务的阻塞，而使得线程处于阻塞状态，而如果有一个线程专门负责轮训的话，这样所有真正实现读写操作的线程就不会阻塞，每次都是可读或者可写的时候，才会真正的将channel于线程关联，从而不会占用宝贵的系统资源而啥都不干，这样线程话的时间都是真正读取和写入数据的事件了，而取消了阻塞的时间，这样在系统资源一定的情况下，会更好的榨取CPU的性能。
另外JAVA7好像要支持异步IO，而异步非阻塞IO，更本不用应用关系如何读取数据，有内核来完成，但是这也需要操作系统从底层支持异步IO，不过我们可以通过Proactor来模拟异步IO的实现。
新的东西并不是在任何场景都比旧的好。别拿那么局限的场景来下结论。另外你举得例子里nio还是比原来的好。 如果不用nio，读写阻塞了，后面的操作都执行不下去，服务就挂起了
NIO解决的问题
线程过多时，对系统资源的过度占用比单线程循环处理的代价更高时的一种权衡
不是NIO就比IO好，存在一个临界值
1、响应时间
2、资源点用
3、变量控制
三个指标的权衡，找到临界值，选择处理方式
设想一下没有NIO之前，数千、数万个客户端来连你的服务器，你的服务器会怎么个死法。
这么简单的道理，自己多想一想。
nio不等于非阻塞IO，我觉得nio中的多路复用，使得线程的数目和并发请求数不需要一一对应，可能可以用更少的线程来处理更多的请求，可伸缩性上面还是好一些。