Netty（一）

1、咱们先来看BIO的问题：

1  没有数据缓冲区，I/O性能存在问题；

2  没有C或C++中的Channel概念，只有输入和输出流；

3  一般会致使通讯线程被长时间阻塞；

4  支持的字符集有限，硬件可移植性很差。

阻塞I/O模型：系统调用到数据包到达且被复制到应用进程的缓冲区中或者发生错误时才返回，在此期间一直会等待。

非阻塞I/O模型：轮询检查缓冲区有无数据的状态。

I/O复用模型：Linux提供select/poll，侦测多个fd是否处于就绪状态。同时还提供了一个epoll系统调用，一个基于事件驱动方式代替顺序扫描，所以性能更高。

信号驱动模型：经过信号回调通知应用程序调用recvfrom来读取数据

异步I/O：和信号驱动I/O区别在于异步I/O模型由内核通知咱们I/O操做什么时候已经完成。

2、I/O多路复用

优点：系统开销小，不须要建立新的额外进程或者线程，不须要维护进程和线程的运行，下降了系统维护工做量，节省系统资源。

应用场景：server同时处理多个处于监听状态或者多个链接状态的套接字；

server须要同时处理多种网络协议的套接字。

3、传统BIO编程

下面先看下BIO通讯模型图

首先有个Acceptor，负责监听多个客户端的链接，接收到链接请求后为每一个客户端建立一个新的线程进行链路处理，处理完成后，经过输出流给客户端发送响应，这就是经典的请求-应答模型。

该模型最大的问题就是缺少弹性伸缩能力，当客户端并发访问量增长后，服务端的线程个数和客户端并发访问数呈1:1的正比关系，因为线程是Java虚拟机宝贵的系统资源，当线程数膨胀后，系统性能将急剧降低，随着并发量持续增大，系统会发生线程堆栈溢出、建立新线程失败等问题，并最终致使进程宕机或者僵死，不能对外提供服务。

为了改进一线程一链接模型，后来又演进了一种经过线程池或者消息队列实现1个或者多个线程处理N个客户端的模型，因为它的底层通讯机制依然使用同步阻塞I/O，因此被称为“伪异步”。

4、伪异步I/O编程

伪异步I/O通讯模型图

伪异步I/O弊端分析

首先，当对Socket的输入流进行读取操做的时候，它会一直阻塞下去，直到发生以下三种事件：

有数据可读；

可用数据已经读取完毕；

发生空指针或者I/O异常。

这就意味着若是发送请求或者应答消息比较慢，或者网络传输较慢时，读取输入流一方通讯线程就将长时间阻塞，在此期间，其余接入消息只能在消息队列中排队。

所以，伪异步I/O实际上仅仅是对以前I/O线程模型的一个简单优化，它没法从根本上解决同步I/O致使的通讯线程阻塞问题。

OK，到这里，阻塞I/O的相关知识就讲解完毕，下节开始讲NIO编程的相关知识和原理。