也来说说JAVA NIO

为什么要NIO，因为为传统IO（即BIO）会造成线程阻塞。

传统IO是怎么阻塞的呢，在读取网络端的流或者文件流的时候，假设用readline()函数读取流中的数据，如果流中没有数据或者数据没有结束标识，那么会一直执行读取动作，流中没有数据就一直等待数，有数据就读完为止，在等待数据的时候线程也会被阻塞的【就是说程序一直会卡在readline()这里进行不下去】，那么单线程只能很好的处理一个网络IO，因为在连接一个客户端之后执行readline()，如果客户端不输入数据，那么服务器端会一直停留在readline()这里，所以当其它客户端建立连接之后，客户端不能同时去读取流中的数据。当然如果对每一个客户端开启一个新线程来处理，即每个线程都对应一个readline()，那么就可以解决同时不能处理多个客户端数据的问题，但是这样就导致了服务器性能的下降，有多少一个连接就要启动多少个线程，如果连接非常多，线程栈内存的开销，线程切换以及CPU处理能力消耗都会带来服务器的性能下降，着也是为什么要NIO的原因，NIO就是为了解决这个问题的。

Note： 初学者有一点要分清，不管是IO还是NIO，有多少个客户端请求就要建立多少个连接（所谓建立连接只不过就是客户端在内存中存储服务器端的信息比如IP端口，服务器端在内存中存储客户端的数据，这就叫建立连接，不是现实中一样用一个绳子连起来），在这方面它们是没有区别的，区别的是建立连接之后处理客户端和服务端数据传输(数据读写)的区别。

那么NIO为什么不会阻塞呢，由BIO可知，NIO就是把readline()这一步抽取出来由某个逻辑集中处理，这个逻辑会一直监听所有连接中（这就是和BIO的区别，BIO是readline()一直傻傻的在那里等，但是NIO是有一个单独的逻辑监听所有连接，这样线程就可以抽身出来了）是否用东西可以读取了，如果有就执行读取操作以及之后的逻辑，这个单独用来监听所用连接动作的逻辑就叫Selector，哪个连接把数据从客户端传过来了，服务器可以读取了Selector就会得知，然后就可以处理这些数据了。

综上所述，NIO和BIO的区别说白了就是在数据准备的时候采取不同的操作，一个客户端的连接建立之后，BIO只是在那里傻傻的等待客户端的输入，这就导致了客户端线程的阻塞，而NIO用一个专门的逻辑来探测所有客户端是否输入了数据，不用傻傻的一直等待某一个客户端的数据了，就不会导致占着茅坑不拉屎的局面，如果是BIO的话，等待的那个客户端一直不输入数据，如果另外的客户端连接要输入数据，但是因为线程被等待的那个阻塞了，导致输入的数据处理不了。