再说异步调用和NIO

    之前的一篇博客阐述了在IO密集型事务中，使用异步调用的好处：http://my.oschina.net/zhenglingfei/blog/397514，本篇文章要说说使用异步调用和单纯使用NIO作为服务端的场景。

    目前大多是的java异步调用都是基于NIO来实现的 ，使用系统底层的select或epoll这样的模式，不过我要说的并不是这个，而是这里对于NIO的使用是用于客户端的，也就是调用者，才有了所谓的异步调用。这样的好处在于，调用者A对于服务端B有着大量的IO调用，而用异步的方式可以只用少量的线程去服务于大量的IO操作，而不同于传统的socket调用，一次调用发起便会阻塞调用线程，当调用量一大，自然cpu利用率下降。正如我第一篇文章所说。这边是用异步的好处，好处在于客户端，因此，这种形式一般适合于服务端间的调用，而非web端，移动端这样的调用，因为这种客户端本身的调用量就不大，异步更适合于SOA，微服务这样的服务化模式，有大量的服务间调用。

    异步是针对客户端调用的好处，那么，nio用在服务端有什么好处呢，可以参见tomcat 6以后nio模式，个人认为，作为服务端，不存在调用阻塞的情况（如果有调用其他服务，这有属于作为客户端的范畴，这里不做考虑），此时采用nio模型的好处在于服务端可以同时监听多个连接，相比于传统的web服务器采用socket的模式，一次处理一个连接，然后交给一个线程处理，这类似一种生产消费者模式，生产者是对网络连接的处理，而消费者是对解码后的请求内容的业务处理，如果消费者速度恒定，那么整体吞吐能力在一定范围内会随着生产速度的提升而，因此对于业务处理简单的情况，消费者速度相对较快，因此，如果生产者较慢就会影响吞吐量。而且，对于并发量很大的服务，如日志服务，业务处理简单，但是量特别大，网卡很有可能被堵塞，并且整体吞吐也不高。

讲了这么多，是为了说明nio在服务端和客户端的区别，以便能更好的使用nio技术，后续会补上基于各种类型的业务的测试数据。