Java高效NIO之IO模型基础

乘着风

概述

目前常见的面向IO操作编程模型有以下几种:

  • Blocking IO:阻塞IO
  • Non-Blocking IO:非阻塞IO
  • IO Multiplexing:IO多路复用
  • Asynchronous IO:异步IO

IO多路复用技术(又称:事件驱动IO),是为了解决传统同步阻塞IO模式下,服务端的每个线程(进程)只能给一个Client提供服务的问题,避免服务器创建大量线程(占用大量内存、线程切换开销)的问题而设计的。本文对各种网络IO编程模型进行简要的介绍。

本文主要讨论的场景是Linux下的网络IO,主要参考了Richard Stevens的《UNIX® Network Programming Volume 1, Third Edition: The Sockets Networking API》和网络上的相关文章。

IO模型分类

先来了解下IO过程相关的同步、异步,阻塞、非阻塞等概念。在IO操作过程中涉及的对象包括:

  1. 调用IO的用户程序(线程或进程)
  2. 处理IO的内核程序(Kernel)

IO操作过程中包括两个阶段(以Read操作为例),分别是:

  1. 数据准备阶段:Kernel等待数据就绪
  2. 数据拷贝阶段:数据就绪后把数据从Kernel空间拷贝到用户程序空间

关于同/异步,非阻塞/阻塞,就是围绕两个对象和两个阶段展开的。

同步异步
同步、异步主要是指用户程序和 内核 的交互模式。
同步:用户程序触发IO操作后,通过一直等待或轮询的方式去检查内核IO操作是否就绪,直到IO就绪。
异步:用户程序触发IO操作后,干其他事情去了,当内核IO操作就绪后,内核把数据写入用户程序指定的Buffer。

从代码实现表现来看,IO操作后,同步模式下,用户需要自己不断去轮询内核获取结果;而异步模式下内核会回写数据到用户程序Buffer并通知用户程序。同步异步的关键:IO设备状态需要自己轮询,还是内核主动通知

阻塞非阻塞
阻塞非阻塞,是程序执行IO操作的系统调用时,根据IO设备操作的就绪状态采取不同处理方式。
阻塞:当程序试图进行读写IO操作时,如果暂时没有可读数据或者不可写,程序就一直处于等待状态,直到可读或可写为止。
非阻塞:当程序试图进行读写IO操作时,如果无可读数据或不可写,程序马上返回,而不会等待。

从代码实现表现来看,IO操作后,阻塞模式下,方法挂起不返回,直到IO设备就绪操作成功,方法才返回;而非阻塞模式,调用方法不等待IO设备就绪就直接返回。阻塞非阻塞的关键:方法调用后是否立即返回

阻塞IO(Blocking IO)

Linux中默认的Socket IO都是Blocking的,读数据的流程如下:
Blocking IO.png
当用户程序调用recvfrom系统调用时,Kernel开始IO的第一个阶段:数据准备。对于网络IO,此时数据很可能还在网络上传送,因此Kernel需要等待数据传输完成。
此时,用户程序会阻塞,等待Kernel返回。当Kernel接收到数据后,需要把数据拷贝的用户内存空间。然后Kernel(recvfrom)才返回,用户程序才能继续往下执行。
所以,Blocking IO在的数据准备和数据拷贝两个阶段,用户程序都是Blocking的。Socket编程提供的listen/send/recv等接口,都是Blocking模式的。
Blocking模式的主要优点时程序结构/流程清晰;缺点时每个线程同时只能给一个客户端提供服务,只能采用多线程(多进程)的方式来提供并发服务。采用多线程的方式有以下缺点:

  1. 每个线程(进程)占用一定的内存;
  2. 线程的创建删除的资源开销;
  3. 多线程调度会带来额外CPU开销;

对于多线程的问题,可以通过线程池来避免线程重复创建回收的开销,通过维护一定数量的线程,防止服务器资源耗尽等问题,通过请求排队处理,保持适当的并发服务等。但是对于成千上万的请求时,线程池模式还是会存在瓶颈。

非阻塞IO(Non-Blocking IO)

通过给Socket设置setblocking(False)把Socket设置为非阻塞模式,非阻塞模式下,通过recvform系统调用读取数据的流程如下:
Non-Blocking IO.png
在Non-Blocking模式下,调用recvfrom时,如果Kernel还没有准备好数据,不会Block,而是直接返回Error。用户程序通过判断返回值,可以确定数据是否Ready。如果Kernel数据未准备好,用户程序可以再发起调用,或者趁这段时间做些其他操作,然后再回来调用,直到方法返回成功。
一旦用户再次调用recvfrom,并且Kernel数据已经Ready,就会把数据拷贝到用户内存空间,并返回。所以在Non-Blocking模式,用户程序需要通过不断调用Kernel(即轮询)来查询数据是否Ready,而且数据拷贝阶段还是Block的。
由于需要轮询,虽然用户程序在这段时间可以做其他操作,但是通常还是只是不断的执行轮询操作,轮询会大量占用CPU时间,而且期间去执行其他操作,会让程序执行逻辑混乱,所以被阻塞模式一般不被推荐使用,而是采用Kernel自带轮询的IO多路复用技术。

IO多路复用(IO Multiplexing)

IO多路复用,又叫事件驱动IO(Event Driver IO),底层使用了Kernel提供的select/poll/epoll(为什么有3种技术,也是从老到新一步步优化的过程)等系统调用。此技术的主要方法是在单个线程中,由select函数负责对多个Socket轮询,一旦其中有Socket数据Ready了,就会通知用户程序进行处理。
IO Multiplexing.png
当调用了select后,用户程序会Block,同时Kernel监控此select负责的所有Socket,当有一个或多个Socket数据Ready事件发生时(事件驱动IO),select就会返回。用户程序再逐个调用Ready的Socket的recvfrom函数,把数据从Kernel拷贝到用户内存。
从流程上看,IO多路复用和Blocking IO区别不大,都会Block用户程序。IO多路复用的主要优点是一个线程可以Handle多个Socket。但如果IO数据接收后的处理任务是计算密集型业务时,由一个线程处理多个任务,性能上会无法胜任,客户端出现卡顿和延迟。
select模型的另外一个问题是虽然用户程序不在需要轮询了,但是Kernel还是需要去轮询Socket,消耗大量CPU,系统设置Socket的上限是1024。许多系统提供了更高效的接口,如Linux的epoll,BSD的kqueue等,但这些接口的主要问题是不能跨平台。

select poll epoll
实现年代 1984 1997 2002
底层数据结构 数组 链表 哈希表
连接数 1024 无限制 无限制,OS支持最大FD数
事件检测方法 遍历FD(File Descriptor) 遍历FD IO就绪自动callback,检查就绪链表即可
时间复杂度 O(n) O(n) O(1)
FD处理 每次调用,需要把FD从用户内存拷贝到内核 每次调用,FD拷贝 epoll_ctl一次拷贝FD,无需重复拷贝
函数 select poll epoll_create创建句柄,epoll_ctl注册IO就绪监听事件,epoll_wait等待事件就绪

IO多路复用模式,对于单个Socket,是非阻塞的,以便在一个线程里同时处理多个Socket,但是select在处理轮询IO设备状态时,是阻塞的。

异步IO(Asynchronous I/O)

异步IO是Linux2.6内核引入的新功能,使用的不多,流程如下:
Asynchronous IO.png

用户程序发起aio_read调用后,程序立即返回。从Kernel的角度,流程如下:

  1. 当Kernel它收到aio_read之后,会立刻返回,不会对用户程序产生Block
  2. Kernel等待数据准备完成,把数据拷贝到用户内存空间
  3. Kernel给用户程序发送一个signal,告诉它read操作以完成

说实话,异步IO功能我也没用过,而且Linux底层还是使用epoll实现的,性能上并没有优势。Java著名NIO框架Netty就使用了IO多路复用,而非异步IO。

IO模型比较

直接上大神的图。
Comparison of IO models.png
从上图可见,阻塞式IO和IO多路复用,特点还行比较明细的,本质上都是同步IO,就不展开了。
Non-Blocking虽然在数据准备阶段不阻塞了,但是用户程序还是需要轮询Check数据状态;而异步IO,发完请求后,用户程序就返回了,数据准备和拷贝,都由Kernel来完成。

阅读 1.8k

五岁时,妈妈告诉我,人生的关键在于快乐。上学后,人们问我长大了要做什么,我写下“快乐”。他们告诉我...

66 声望
10 粉丝
0 条评论

五岁时,妈妈告诉我,人生的关键在于快乐。上学后,人们问我长大了要做什么,我写下“快乐”。他们告诉我...

66 声望
10 粉丝
文章目录
宣传栏