客户端 nio bio 的比较

   换完工作有三四个月了，发现一直都在忙，也好久不来这里，写下点什么了。今天就来分析下java Nio 和 Bio 应用于客户端的情况。

   Nio 是 new IO 的缩写，这个新是相对于Bio 而言。对于IO，大体上有两种分类，同步，异步；阻塞，非阻塞之分。Bio 自然是阻塞io，但Nio 不一定就是非阻塞，也可以是阻塞的。所以Nio 体现在新上。 还有阻塞和非阻塞与同步，异步没有太大的对照性。不要以为同步就是用了阻塞IO的，异步就是非阻塞。同步，异步是和你用的线程有关。阻塞的也可用与异步情况，怎不用呢，业务内使用future模式，通信使用线程，也可有异步效果。仔细想想Nio 没出来之前，岂不是java就不能异步通信了，这当然是不可能了的嘛。非阻塞用于同步的就不说了。

   这里看出来同步，异步要看线程。

   这里比较Nio 和Bio 当然是把Nio 用于非阻塞的情况，阻塞的情况又有什么可比的呢？

   我们可以可以看看mina和async http client 的Nio异步的实现方式。大部分是一个acceptor 或connector 线程专门管理建立链接相关的io事务，多个（cpu 核数加一）processor 线程处理数据传输。这里不得不吐槽下这个核数加一的设定，系统的并非处理能力和cpu核数当然是正相关的，但是认为设定个核数加一就算调到最优了，不能不说太傻太天真了。不知道一个进程里可能还有很多其它线程吗，其它进程还有线程吗？怎么能保证在一个分片时间里，处理掉所有的请求事件，尤其是大并发下。所以processor的个数核数加一是个下限而已。

  在比较下，客户端通信与服务器通信之间的不同，一般总压力表现为，并发量＊频率＊单次压力，前两个不用废话，后一个对于io和计算就有点不同，业务越复杂，这个对于一次的计算压力越大，数据量越大，io压力越大。当然大部分都是一项或一两项高。

  如果是小数据，并发，频率高，用mina 类的处理方式是非常不错的，保证每一个processor在自己的时间分片里处理完所以请求事件即可，如果处理不完呢？那只有加线程了，不行就加机器，就像公司里一样，活多人少，那可是不行的。而且服务端好处是io 可以和业务分离，io 有io 线程，业务有业务线程。这个对于客户端就不是太好了，这个在后面分析。所以如果是小数据量，io线程能保证快速处理io事件即可，对于业务，业务少，tps 达标，当然可以在io 线程里把业务也做了，如果太多，那加个线程池来处理也是可以的，如果还不够，妹的，esb，服务化加消息走起，先给你个简单回复，例如“容哥三思”，做完了，通过消息中间件发连接通知服务器，再发通知，如“哥想过了，这个可以有”云云。可谓玩法多多。

  但是对于客户端，要发请求等响应，这就比较麻烦，因为请求和响应要对的起来，就像你同时像A和B要钱（非阻塞请求），那么A给你的钱，你得记在A上，B给你的要记在B上。现实情况可能比较简单，但对于同一个服务器，请求和响应要能绑定，那么顺序就要保证，这就不能简单的处理事件了。（对于服务器是不需要的，从哪来的请求，我给谁响应就行）。除非在协议上有规定，那么请求和响应就要有原子性。一个链路上就是一个请求一个响应的顺序。这个和Bio 区别就不大了。

   所以很多客户端还是Bio的形式，如mongo，redis，c3p0等链接池还是bio 的形式