BIO，即所谓的面向字节的api。

基本的思路是每一个连接对应一个线程。所以accept以后，就会新建一个线程来处理这个socket。线程里面也是一个while，读取客户端请求，然后相应。这种设计思路很清晰，写起来比较顺，但是性能在高并发的时候有问题，主要是线程太吃资源，但是在低并发情况下还是不错的。

一个改进就是采用线程池，这样可以限制线程数目，只有前面的一些客户端关闭了连接，释放了线程，那么这个线程才能处理其他的连接。

 

NIO，是java的非阻塞io api。

可以采用一个线程处理多个io。这种模式可以应对高并发，但是编程难度较大，因为一次请求响应被分为了两个周期来处理，所以复杂情况下，需要一些全局的队列来缓存一些东西。事件方面主要有连接和读写两种。每一次注册都有一个key和channel关联，一旦有事件，key会被返回，key里面有发生的事件。每一次处理需要移除key。同时，可能需要修改key里所关心的事件类型。

 

20190221更新：

bio一个线程只能处理一个socket。nio一个线程可以处理多个socket。这是最基本的共识。但是这里并不是说nio就有多牛逼，因为nio仅仅是提供了单线程处理多个socket的能力，并不是说一定就优于bio。举个例子，假设就在单线程环境下，nio和bio其实没有太大区别。因为都是串行的，只要有一个socket的处理卡了，不论nio还是bio都只能等待。nio和bio处理多socket的能力的不同使得二者的工作模式其实是不同的。因为bio是以socket为单位处理的，而nio是以事件为单位处理的，粒度更细。在单线程环境下，bio必须处理完一个socket再下一个，而nio则是交替处理socekt，在某一时刻，bio可能处理完了3个socket，还剩7个，但是nio可能一个都没有处理完，但是每一个socket都处理了一半，这是二者更感官的区别。在多线程模式下比如线程池，bio就可能产生饥饿。10个线程的线程池，头10个任务，都是在写入时很费时，这时bio的线程池就被打满了，而nio则可能不会。另外，如果并发量较大，nio仍然可以接受更多的socket的连接，至于能否处理的过来另说，但是起码是可以接受的。但是bio可能需要等待，bio必须是一个socket对应一个线程，如果其他被占用的线程没有被释放就不能接受更多的连接。nio呢，当然也需要多个线程来并发处理，但是不一定每一个连接都对应一个线程，线程池数目可以灵活排，线程池的作用只是用来响应事件的，数目不固定。