可能这是关于BIO-NIO-AIO-Netty处理模型最好理解的文章了

无意中看到别人总结BIO-NIO-AIO-Netty的前世今生,也在往上翻阅了一些帖子,总感觉讲的太过于繁杂,往往一个简单的概念层层拓展,盖过了文章的主题,所以我想图文并茂的,层层递进,简单点、再简单点的讲出来。所以本文中不会出现代码。讲的不好的,或者错误的请指正!!

BIO(Blocking Input/Output)

处理步骤: 启动服务端,并循环监听客户端连接,每监听到一个请求,创建一个新线程处理数据。在未接收到连接时,会一直阻塞。每个客户端发送请求,处理完成后,再通过输出流返回客户端,然后销毁线程(bio的读写是半双工)。

缺陷:一个客户端请求,就对应一个线程,当请求过多的时候,线程越来越多,jvm内存被大量占用,线程是Java虚拟机宝贵资源,线程数膨胀后,系统性能下降,线程并发访问量继续增大,会导致进程宕机或僵死。

NIO(Non-blocking Input/Output)

这里需要阐述几个概念:

Buffer:当一个链接建立完成后,IO的数据未必会马上到达,为了当数据到达时能够正确完成IO操作,在BIO(阻塞IO)中,等待IO的线程必须被阻塞,以全天候地执行IO操作。为了解决这种IO方式低效的问题,引入了缓冲区的概念,当数据到达时,可以预先被写入缓冲区,再由缓冲区交给线程,因此线程无需阻塞地等待IO。

Channel: 是 I/O 传输发生时通过的入口,而缓冲区是这些数据传输的来源或目标。对于离开缓冲区的传输,您想传递出去的数据被置于一个缓冲区,被传送到通道。对于传回缓冲区的传输,一个通道将数据放置在您所提供的缓冲区中。

Selector: 通道和缓冲区的机制,使得线程无需阻塞地等待IO事件的就绪,但是总是要有人来监管这些IO事件。这个工作就交给了selector来完成,这就是所谓的同步。Selector允许单线程处理多个 Channel。要使用Selector,得向Selector注册Channel,然后调用它的select()方法。这个方法会一直阻塞到某个注册的通道有事件就绪,这就是所说的轮询。一旦这个方法返回,线程就可以处理这些事件。

处理步骤: 看图最直观和BIO的区别就是多了一个Selector,就是说一个可以把多个客户端连接分配给一个Selector,他来负责与客户端的连接,那具体数据怎么处理呢,Selector会把具体处理的给到图中它的工人们(就是一线程池)。

缺点:Selector在不停的轮询,那有没有办法,让Selector就等着,有客户端连接的时候 通知我呗!这就是AIO。

AIO(Asynchronous Input/Output)

 NIO 2.0引入了新的异步通道的概念,并提供了异步文件通道和异步套接字通道的实现。

异步的套接字通道时真正的异步非阻塞I/O,对应于UNIX网络编程中的事件驱动I/O(AIO)。他不需要过多的Selector对注册的通道进行轮询即可实现异步读写,从而简化了NIO的编程模型。API比NIO的使用起来真的简单多了,主要就是监听、读、写等各种CompletionHandler。此处本应有一个WriteHandler的,确实,我们在ReadHandler中,以一个匿名内部类实现了它。

AIO流程其实是在NIO的基础上,是真正的异步非阻塞的,核心就是观察者模式的实现(可以理解为C语言的钩子,js的回调函数),从轮询变为了事件回调(比如:什么时候有客户端连上来了,你帮我调用某段代码,我该干嘛干嘛去)。

Netty

Netty封装了JDK的NIO,让你用得更爽,你不用再写一大堆复杂的代码了。Netty是一个异步事件驱动的网络应用框架,用于快速开发可维护的高性能服务器和客户端。

jdk自带的nio的api需要了解太多的概念,以及处理细节,学习成本太高了,而且各种异常处理,稍微不小心就手写了一个bug,而且代码的可读性很差!比如nio的粘包拆包,想想就恶心到不行。

那为什么netty封装的是nio而不是aio呢?

官网上是这么说的:大多数服务端都部署在linux系统上,但是linxu系统还没有AIO的实现,还是以epoll轮询来处理,所以封装AIO的话就显得多此一举了,但是windows系统是实现了aio的!

关于 nio和aio的概念的解释,请查看:https://blog.csdn.net/luzhensmart/article/details/82230076

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页