## 1\. 前言
最近在学习 Java NIO 方面的知识,为了加深理解。特地去看了 Unix/Linux I/O 方面的知识,并写了一些代码进行验证。在本文接下来的一章中,我将通过举例的方式向大家介绍五种 I/O 模型。如果大家是第一次了解 I/O 模型方面的知识,理解起来会有一定的难度。所以在看文章的同时,我更建议大家动手去实现这些 I/O 模型,感觉会不一样。好了,下面咱们一起进入正题吧。
## 2\. I/O 模型
本章将向大家介绍五种 I/O 模型,包括阻塞 I/O、非阻塞 I/O、I/O 复用、信号驱动式 I/O 、异步 I/O 等。本文的内容参考了《UNIX网络编程》,文中所用部分图片也是来自于本书。关于《UNIX网络编程》这本书,我想就不用多说了。很多写网络编程方面的文章一般都会参考该书,本文也不例外。如果大家想进深入学习网络编程,建议去读读这本书。
### [](http://www.tianxiaobo.com/2018/02/08/IO%E6%A8%A1%E5%9E%8B%E7%AE%80%E8%BF%B0/#21-阻塞-io-模型)2.1 阻塞 I/O 模型
阻塞 I/O 是最简单的 I/O 模型,一般表现为进程或线程等待某个条件,如果条件不满足,则一直等下去。条件满足,则进行下一步操作。相关示意图如下:
[![](https://blog-pictures.oss-cn-shanghai.aliyuncs.com/15180090652103.jpg)](http://www.coolblog.xyz/)
上图中,应用进程通过系统调用 recvfrom 接收数据,但由于内核还未准备好数据报,应用进程就阻塞住了。直到内核准备好数据报,recvfrom 完成数据报复制工作,应用进程才能结束阻塞状态。
这里简单解释一下应用进程和内核的关系。内核即操作系统内核,用于控制计算机硬件。同时将用户态的程序和底层硬件隔离开,以保障整个计算机系统的稳定运转(如果用户态的程序可以控制底层硬件,那么一些病毒就会针对硬件进行破坏,比如 CIH 病毒)。应用进程即用户态进程,运行于操作系统之上,通过系统调用与操作系统进行交互。上图中,内核指的是 TCP/IP 等协议及相关驱动程序。客户端发送的请求,并不是直接送达给应用程序,而是要先经过内核。内核将请求数据缓存在内核空间,应用进程通过 recvfrom 调用,将数据从内核空间拷贝到自己的进程空间内。大致示意图如下:
[![](https://blog-pictures.oss-cn-shanghai.aliyuncs.com/15180125151397.jpg)](http://www.coolblog.xyz/)
阻塞 I/O 理解起来并不难,不过这里还是举个例子类比一下。假设大家日常工作流程设这样的(其实就是我日常工作的流程😁),我们写好代码后,本地测试无误,通过邮件的方式,告知运维同学发布服务。运维同学通过发布脚本打包代码,重启服务(心疼我司的人肉运维)。一般项目比较大时,重启一次比较耗时。而运维同学又有点死脑筋,非要等这个服务重启好,再去做其他事。结果一天等待的时间比真正工作的时间还要长,然后就被开了。运维同学用这个例子告诉我们,阻塞式 I/O 效率不太好。
### [](http://www.tianxiaobo.com/2018/02/08/IO%E6%A8%A1%E5%9E%8B%E7%AE%80%E8%BF%B0/#22-非阻塞-io-模型)2.2 非阻塞 I/O 模型
与阻塞 I/O 模型相反,在非阻塞 I/O 模型下。应用进程与内核交互,目的未达到时,不再一味的等着,而是直接返回。然后通过轮询的方式,不停的去问内核数据准备好没。示意图如下:
[![](https://blog-pictures.oss-cn-shanghai.aliyuncs.com/15180140157823.jpg)](http://www.coolblog.xyz/)
上图中,应用进程通过 recvfrom 系统调用不停的去和内核交互,直到内核准备好数据报。从上面的流程中可以看出,应用进程进入轮询状态时等同于阻塞,所以非阻塞的 I/O 似乎并没有提高进程工作效率。
再用上面的例子进行类比。公司辞退了上一个怠工的运维同学后,又招了一个运维同学。这个运维同学每次重启服务,隔一分钟去看一下,然后进入发呆状态。虽然真正的工作时间增加了,但是没用啊,等待的时间还是太长了。被公司发现后,又被辞了。
### [](http://www.tianxiaobo.com/2018/02/08/IO%E6%A8%A1%E5%9E%8B%E7%AE%80%E8%BF%B0/#23-io-复用模型)2.3 I/O 复用模型
Unix/Linux 环境下的 I/O 复用模型包含三组系统调用,分别是 select、poll 和 epoll(FreeBSD 中则为 kqueue)。select 出现的时间最早,在 BSD 4.2中被引入。poll 则是在 AT&T System V UNIX 版本中被引入(详情请参考 UNIX man-page)。epoll 出现在 Linux kernel 2.5.44 版本中,与之对应的 kqueue 调用则出现在 FreeBSD 4.1,早于 epoll。select 和 poll 出现的时间比较早,在当时也是比较先进的 I/O 模型了,满足了当时的需求。不过随着因特网用户的增长,C10K 问题出现。select 和 poll 已经不能满足需求了,研发更加高效的 I/O 模型迫在眉睫。到了 2000 年,FreeBSD 率先发布了 select、poll 的改进版 kqueue。Linux 平台则在 2002 年 2.5.44 中发布了 epoll。好了,关于三者的一些历史就说到这里。本节接下来将以 select 函数为例,简述该函数的使用过程。
select 有三个文件描述符集(readfds),分别是可读文件描述符集(writefds)、可写文件描述符集和异常文件描述符集(exceptfds)。应用程序可将某个 socket (文件描述符)设置到感兴趣的文件描述符集中,并调用 select 等待所感兴趣的事件发生。比如某个 socket 处于可读状态了,此时应用进程就可调用 recvfrom 函数把数据从内核空间拷贝到进程空间内,无需再等待内核准备数据了。示意图如下:
[![](https://blog-pictures.oss-cn-shanghai.aliyuncs.com/15180556060991.jpg)](http://www.coolblog.xyz/)
一般情况下,应用进程会将多个 socket 设置到感兴趣的文件描述符集中,并调用 select 等待所关注的事件(比如可读、可写)处于就绪状态。当某些 socket 处于就绪状态后,select 返回处于就绪状态的 sockct 数量。注意这里返回的是 socket 的数量,并不是具体的 socket。应用程序需要自己去确定哪些 socket 处于就绪状态了,确定之后即可进行后续操作。
I/O 复用本身不是很好理解,所以这里还是举例说明吧。话说公司的运维部连续辞退两个运维同学后,运维部的 leader 觉得需要亲自监督一下大家工作。于是 leader 在周会上和大家说,从下周开始,所有的发布邮件都由他接收,并由他转发给相关运维同学,同时也由他重启服务。各位运维同学需要告诉 leader 各自所负责监控的项目,服务重启好后,leader 会通过内部沟通工具通知相关运维同学。至于服务重启的结果(成功或失败),leader 不关心,需要运维同学自己去看。运维同学看好后,需要把结果回复给开发同学。
上面的流程可能有点啰嗦,所以还是看图吧。
[![](https://blog-pictures.oss-cn-shanghai.aliyuncs.com/15180681282120.jpg)](http://www.coolblog.xyz/)
把上面的流程进行分步,如下:
1. 开发同学将发布邮件发送给运维 leader,并指明这个邮件应该转发给谁
2. 运维告诉 leader,如果有发给我的邮件,请发送给我
3. leader 把邮件转发给相关的运维同学,并着手重启服务
4. 运维同学看完邮件,告诉 leader 某某服务重启好后,请告诉我
5. 服务重启好,leader 通知运维同学xx服务启动好了
6. 运维同学查看服务启动情况,并返回信息给开发同学
这种方式为什么可以提高工作效率呢?原因在于运维同学一股脑把他所负责的几十个项目都告诉了 leader,由 leader 重启服务,并通知运维同学。运维同学这个时候等待 leader 的通知,只要其中一个或几个服务重启好了,运维同学就回接到通知,然后就可去干活了。而不是像以前一样,非要等某个服务重启好再进行后面的工作。
说一下上面例子的角色扮演。开发同学是客户端,leader 是内核。开发同学发的邮件相当于网络请求,leader 接收邮件,并重启服务,相当于内核准备数据。运维同学是服务端应用进程,告诉 leader 自己感兴趣的事情,并在最后将事情的处理结果返回给开发同学。
不知道大家有没有理解上面的例子,I/O 复用本身可能就不太好理解,所以看不懂也不要气馁。另外,上面的例子只是为了说明情况,现实中并不会是这样干,不然 leader 要累死了。如果大家觉得上面的例子不太好,我建议大家去看看权威资料《UNIX网络编程》。同时,如果能用 select 写个简单的 tcp 服务器,有助于加深对 I/O 复用的理解。如果不会写,也可以参考我写的代码[select\_server.c](https://github.com/coolblog-xyz/toyhttpd/blob/master/select_server.c)。
### [](http://www.tianxiaobo.com/2018/02/08/IO%E6%A8%A1%E5%9E%8B%E7%AE%80%E8%BF%B0/#24-信号驱动式-io-模型)2.4 信号驱动式 I/O 模型
信号驱动式 I/O 模型是指,应用进程告诉内核,如果某个 socket 的某个事件发生时,请向我发一个信号。在收到信号后,信号对应的处理函数会进行后续处理。示意图如下:
[![](https://blog-pictures.oss-cn-shanghai.aliyuncs.com/15180719994697.jpg)](http://www.coolblog.xyz/)
再用之前的例子进行说明。某个运维同学比较聪明,他写了一个监控系统。重启服务的过程由监控系统来做,做好后,监控系统会给他发个通知。在此之前,运维同学可以去做其他的事情,不用一直发呆等着了。运维同学收到通知后,首先去检查服务重启情况,接着再给开发同学回复邮件就行了。
相比之前的工作方式,是不是感觉这种方式更合理。从流程上来说,这种方式确实更合理。进程在信号到来之前,可以去做其他事情,而不用忙等。但现实中,这种 I/O 模型用的并不多。
### [](http://www.tianxiaobo.com/2018/02/08/IO%E6%A8%A1%E5%9E%8B%E7%AE%80%E8%BF%B0/#25-异步-io-模型)2.5 异步 I/O 模型
异步 I/O 是指应用进程把文件描述符传给内核后,啥都不管了,完全由内核去操作这个文件描述符。内核完成相关操作后,会发信号告诉应用进程,某某 I/O 操作我完成了,你现在可以进行后续操作了。示意图如下:
[![](https://blog-pictures.oss-cn-shanghai.aliyuncs.com/15180089800822.jpg)](http://www.coolblog.xyz/)
上图通过 aio\_read 把文件描述符、数据缓存空间,以及信号告诉内核,当文件描述符处于可读状态时,内核会亲自将数据从内核空间拷贝到应用进程指定的缓存空间呢。拷贝完在告诉进程 I/O 操作结束,你可以直接使用数据了。
接着上一节的例子进行类比,运维小哥升级了他的监控系统。此时,监控系统不光可以监控服务重启状态,还能把重启结果整理好,发送给开发小哥。而运维小哥要做的事情就更简单了,收收邮件,点点监控系统上的发布按钮。然后就可以悠哉悠哉的继续睡觉了,一天一天的就这么过去了。
### [](http://www.tianxiaobo.com/2018/02/08/IO%E6%A8%A1%E5%9E%8B%E7%AE%80%E8%BF%B0/#26-总结)2.6 总结
上面介绍了5种 I/O 模型,也通过举例的形式对每种模型进行了补充说明,不知道大家看懂没。抛开上面的 I/O 模型不谈,如果某种 I/O 模型能让进程的工作的时间大于等待的时间,那么这种模型就是高效的模型。在服务端请求量变大时,通过 I/O 复用模型可以让进程进入繁忙的工作状态中,减少忙等,进而提高了效率。
I/O 复用模型结果数次改进,目前性能已经很好了,也得到了广泛应用。像 Nginx,lighttd 等服务器软件都选用该模型。好了,关于 I/O 模型就说到这里。
最后附一张几种 I/O 模型的对比图:
[![](https://blog-pictures.oss-cn-shanghai.aliyuncs.com/15180794109268.jpg)](http://www.coolblog.xyz/)
- 一.JVM
- 1.1 java代码是怎么运行的
- 1.2 JVM的内存区域
- 1.3 JVM运行时内存
- 1.4 JVM内存分配策略
- 1.5 JVM类加载机制与对象的生命周期
- 1.6 常用的垃圾回收算法
- 1.7 JVM垃圾收集器
- 1.8 CMS垃圾收集器
- 1.9 G1垃圾收集器
- 2.面试相关文章
- 2.1 可能是把Java内存区域讲得最清楚的一篇文章
- 2.0 GC调优参数
- 2.1GC排查系列
- 2.2 内存泄漏和内存溢出
- 2.2.3 深入理解JVM-hotspot虚拟机对象探秘
- 1.10 并发的可达性分析相关问题
- 二.Java集合架构
- 1.ArrayList深入源码分析
- 2.Vector深入源码分析
- 3.LinkedList深入源码分析
- 4.HashMap深入源码分析
- 5.ConcurrentHashMap深入源码分析
- 6.HashSet,LinkedHashSet 和 LinkedHashMap
- 7.容器中的设计模式
- 8.集合架构之面试指南
- 9.TreeSet和TreeMap
- 三.Java基础
- 1.基础概念
- 1.1 Java程序初始化的顺序是怎么样的
- 1.2 Java和C++的区别
- 1.3 反射
- 1.4 注解
- 1.5 泛型
- 1.6 字节与字符的区别以及访问修饰符
- 1.7 深拷贝与浅拷贝
- 1.8 字符串常量池
- 2.面向对象
- 3.关键字
- 4.基本数据类型与运算
- 5.字符串与数组
- 6.异常处理
- 7.Object 通用方法
- 8.Java8
- 8.1 Java 8 Tutorial
- 8.2 Java 8 数据流(Stream)
- 8.3 Java 8 并发教程:线程和执行器
- 8.4 Java 8 并发教程:同步和锁
- 8.5 Java 8 并发教程:原子变量和 ConcurrentMap
- 8.6 Java 8 API 示例:字符串、数值、算术和文件
- 8.7 在 Java 8 中避免 Null 检查
- 8.8 使用 Intellij IDEA 解决 Java 8 的数据流问题
- 四.Java 并发编程
- 1.线程的实现/创建
- 2.线程生命周期/状态转换
- 3.线程池
- 4.线程中的协作、中断
- 5.Java锁
- 5.1 乐观锁、悲观锁和自旋锁
- 5.2 Synchronized
- 5.3 ReentrantLock
- 5.4 公平锁和非公平锁
- 5.3.1 说说ReentrantLock的实现原理,以及ReentrantLock的核心源码是如何实现的?
- 5.5 锁优化和升级
- 6.多线程的上下文切换
- 7.死锁的产生和解决
- 8.J.U.C(java.util.concurrent)
- 0.简化版(快速复习用)
- 9.锁优化
- 10.Java 内存模型(JMM)
- 11.ThreadLocal详解
- 12 CAS
- 13.AQS
- 0.ArrayBlockingQueue和LinkedBlockingQueue的实现原理
- 1.DelayQueue的实现原理
- 14.Thread.join()实现原理
- 15.PriorityQueue 的特性和原理
- 16.CyclicBarrier的实际使用场景
- 五.Java I/O NIO
- 1.I/O模型简述
- 2.Java NIO之缓冲区
- 3.JAVA NIO之文件通道
- 4.Java NIO之套接字通道
- 5.Java NIO之选择器
- 6.基于 Java NIO 实现简单的 HTTP 服务器
- 7.BIO-NIO-AIO
- 8.netty(一)
- 9.NIO面试题
- 六.Java设计模式
- 1.单例模式
- 2.策略模式
- 3.模板方法
- 4.适配器模式
- 5.简单工厂
- 6.门面模式
- 7.代理模式
- 七.数据结构和算法
- 1.什么是红黑树
- 2.二叉树
- 2.1 二叉树的前序、中序、后序遍历
- 3.排序算法汇总
- 4.java实现链表及链表的重用操作
- 4.1算法题-链表反转
- 5.图的概述
- 6.常见的几道字符串算法题
- 7.几道常见的链表算法题
- 8.leetcode常见算法题1
- 9.LRU缓存策略
- 10.二进制及位运算
- 10.1.二进制和十进制转换
- 10.2.位运算
- 11.常见链表算法题
- 12.算法好文推荐
- 13.跳表
- 八.Spring 全家桶
- 1.Spring IOC
- 2.Spring AOP
- 3.Spring 事务管理
- 4.SpringMVC 运行流程和手动实现
- 0.Spring 核心技术
- 5.spring如何解决循环依赖问题
- 6.springboot自动装配原理
- 7.Spring中的循环依赖解决机制中,为什么要三级缓存,用二级缓存不够吗
- 8.beanFactory和factoryBean有什么区别
- 九.数据库
- 1.mybatis
- 1.1 MyBatis-# 与 $ 区别以及 sql 预编译
- Mybatis系列1-Configuration
- Mybatis系列2-SQL执行过程
- Mybatis系列3-之SqlSession
- Mybatis系列4-之Executor
- Mybatis系列5-StatementHandler
- Mybatis系列6-MappedStatement
- Mybatis系列7-参数设置揭秘(ParameterHandler)
- Mybatis系列8-缓存机制
- 2.浅谈聚簇索引和非聚簇索引的区别
- 3.mysql 证明为什么用limit时,offset很大会影响性能
- 4.MySQL中的索引
- 5.数据库索引2
- 6.面试题收集
- 7.MySQL行锁、表锁、间隙锁详解
- 8.数据库MVCC详解
- 9.一条SQL查询语句是如何执行的
- 10.MySQL 的 crash-safe 原理解析
- 11.MySQL 性能优化神器 Explain 使用分析
- 12.mysql中,一条update语句执行的过程是怎么样的?期间用到了mysql的哪些log,分别有什么作用
- 十.Redis
- 0.快速复习回顾Redis
- 1.通俗易懂的Redis数据结构基础教程
- 2.分布式锁(一)
- 3.分布式锁(二)
- 4.延时队列
- 5.位图Bitmaps
- 6.Bitmaps(位图)的使用
- 7.Scan
- 8.redis缓存雪崩、缓存击穿、缓存穿透
- 9.Redis为什么是单线程、及高并发快的3大原因详解
- 10.布隆过滤器你值得拥有的开发利器
- 11.Redis哨兵、复制、集群的设计原理与区别
- 12.redis的IO多路复用
- 13.相关redis面试题
- 14.redis集群
- 十一.中间件
- 1.RabbitMQ
- 1.1 RabbitMQ实战,hello world
- 1.2 RabbitMQ 实战,工作队列
- 1.3 RabbitMQ 实战, 发布订阅
- 1.4 RabbitMQ 实战,路由
- 1.5 RabbitMQ 实战,主题
- 1.6 Spring AMQP 的 AMQP 抽象
- 1.7 Spring AMQP 实战 – 整合 RabbitMQ 发送邮件
- 1.8 RabbitMQ 的消息持久化与 Spring AMQP 的实现剖析
- 1.9 RabbitMQ必备核心知识
- 2.RocketMQ 的几个简单问题与答案
- 2.Kafka
- 2.1 kafka 基础概念和术语
- 2.2 Kafka的重平衡(Rebalance)
- 2.3.kafka日志机制
- 2.4 kafka是pull还是push的方式传递消息的?
- 2.5 Kafka的数据处理流程
- 2.6 Kafka的脑裂预防和处理机制
- 2.7 Kafka中partition副本的Leader选举机制
- 2.8 如果Leader挂了的时候,follower没来得及同步,是否会出现数据不一致
- 2.9 kafka的partition副本是否会出现脑裂情况
- 十二.Zookeeper
- 0.什么是Zookeeper(漫画)
- 1.使用docker安装Zookeeper伪集群
- 3.ZooKeeper-Plus
- 4.zk实现分布式锁
- 5.ZooKeeper之Watcher机制
- 6.Zookeeper之选举及数据一致性
- 十三.计算机网络
- 1.进制转换:二进制、八进制、十六进制、十进制之间的转换
- 2.位运算
- 3.计算机网络面试题汇总1
- 十四.Docker
- 100.面试题收集合集
- 1.美团面试常见问题总结
- 2.b站部分面试题
- 3.比心面试题
- 4.腾讯面试题
- 5.哈罗部分面试
- 6.笔记
- 十五.Storm
- 1.Storm和流处理简介
- 2.Storm 核心概念详解
- 3.Storm 单机版本环境搭建
- 4.Storm 集群环境搭建
- 5.Storm 编程模型详解
- 6.Storm 项目三种打包方式对比分析
- 7.Storm 集成 Redis 详解
- 8.Storm 集成 HDFS 和 HBase
- 9.Storm 集成 Kafka
- 十六.Elasticsearch
- 1.初识ElasticSearch
- 2.文档基本CRUD、集群健康检查
- 3.shard&replica
- 4.document核心元数据解析及ES的并发控制
- 5.document的批量操作及数据路由原理
- 6.倒排索引
- 十七.分布式相关
- 1.分布式事务解决方案一网打尽
- 2.关于xxx怎么保证高可用的问题
- 3.一致性hash原理与实现
- 4.微服务注册中心 Nacos 比 Eureka的优势
- 5.Raft 协议算法
- 6.为什么微服务架构中需要网关
- 0.CAP与BASE理论
- 十八.Dubbo
- 1.快速掌握Dubbo常规应用
- 2.Dubbo应用进阶
- 3.Dubbo调用模块详解
- 4.Dubbo调用模块源码分析
- 6.Dubbo协议模块